“The strength of the team is each individual member. The strength of each member is the team.” — Phil Jackson
The Mutual Mirror: When Engineering and Product Are Each Other’s Customers
In the ever-evolving world of product development, one of the most misunderstood—and yet most powerful—concepts is the reciprocal relationship between engineering and product management. Too often, these roles are viewed in tension: Product writes the “what,” Engineering builds the “how.” But that simplification breaks down under the weight of complex software ecosystems, agile cross-functional teams, and the ever-present demand for delivering real value to customers.
At its best, the relationship between Product and Engineering is not adversarial or hierarchical. It’s transactional, service-oriented, and based on mutual trust—because both are, at various times, customers of each other. Understanding when and how that switch happens is the key to unlocking high-functioning collaboration.
Historical Context: Silos, Specs, and Waterfalls
In the early days of software development—especially under the Waterfall model—Product (or business analysis) would produce long, detailed requirement documents, hand them off to Engineering, and then wait. This baton-passing model created silos. Product was the customer; Engineering was the vendor. The success metric? “Did you build what I asked for?”
But as software moved from static deliverables to dynamic, iterative experiences—especially with the rise of Agile, DevOps, and cross-functional product teams—the lines blurred. Teams were co-located, timelines compressed, and user feedback loops shortened. Product stopped being the sole customer. Engineering’s role evolved, not just as builders, but as collaborators—sometimes even stakeholders in defining what should be built.
Thought Leaders Who Shaped This Mindset
People like Marty Cagan, Teresa Torres, and Jez Humble have helped reframe this dynamic:
- Marty Cagan, in Inspired, emphasizes empowered product teams where engineers are involved early in discovery, not just delivery.
- Teresa Torres, through Continuous Discovery Habits, makes it clear that engineers bring critical feasibility perspectives that shape good outcomes.
- Jez Humble, co-author of Accelerate, focuses on how engineering excellence (like continuous delivery and testing infrastructure) serves the business—and must be prioritized like any customer request.
Their core message? Collaboration between Product and Engineering isn’t a linear handoff; it’s a feedback loop.
Engineering as a Customer of Product
There are clear moments when Product is the provider and Engineering the customer:
- Product Vision and Roadmapping: Engineering needs clarity and context. Vague goals like “increase engagement” don’t help. When Product teams define clear outcomes, KPIs, and priorities, they serve Engineering by aligning work with business value.
- Backlog Grooming and Acceptance Criteria: A well-articulated user story—with context, personas, acceptance criteria, and tradeoff considerations—is a service to engineers. It gives them the confidence to deliver quality without spinning on ambiguity.
- Customer Research and Context Sharing: Engineering often doesn’t get direct access to end users. Product can serve Engineering by surfacing qualitative feedback, customer pain points, and competitive insights, which in turn spark innovation.
What Good Looks Like:
At Stripe and Shopify, engineers frequently participate in product design discussions. They aren’t just coders—they’re informed collaborators. Product managers, in turn, act as translators of market demand into strategic focus.
Product as a Customer of Engineering
The reverse is also true. There are times when Product is the customer, and Engineering must act as a service provider:
- Platform Work and Infrastructure Investments: When engineers advocate for re-platforming, test automation, or observability upgrades, they are requesting resources and time. Product, in this case, must listen with curiosity, not skepticism. These are foundational bets that enable velocity and quality downstream.
- Feasibility and Risk Assessments: Product often dreams big. Engineering grounds that vision with tradeoffs, performance constraints, or security implications. It’s not blocking—it’s protecting the roadmap. Product must receive that input as a customer would: with respect and accountability.
- Operational Needs (e.g., DevEx): Tools, environments, CI/CD pipelines—these affect engineering morale and output. Product can support engineering by allocating time for internal improvements, even when customers don’t “see” them directly.
What Good Looks Like:
Google’s famed 20% time and Amazon’s internal “two-pizza teams” both prioritize engineering autonomy and platform investment. PMs in these orgs don’t push back on technical debt—they prioritize it when it improves team efficiency or scalability.
Where It Goes Wrong
- Overstepping Without Clarity: A PM dictates the solution (“use Firebase”) rather than articulating the need. An engineer rejects a roadmap without offering alternative solutions. This is not partnership—it’s control.
- No Clear Owner: Product wants to “leave it to Engineering” on prioritizing tech debt. Engineering assumes “Product owns the roadmap” and doesn’t advocate for fixes. In the absence of clear boundaries, nothing gets done.
- Metrics Without Shared Ownership: Product measures business KPIs; Engineering measures velocity or uptime. But without shared accountability (e.g., performance, latency, engagement), the teams drift.
Establishing Boundaries—and When to Step Over Them
Clear boundaries help. But so does informed empathy.
- Product owns the “why” and “what”: Business goals, customer insights, competitive landscape.
- Engineering owns the “how” and “when”: Feasibility, architecture, scalability.
Yet great teams know when to step in thoughtfully:
- Engineers should challenge the “what” if the “how” reveals better alternatives.
- PMs should ask about the “how” to understand costs and tradeoffs—not to micromanage, but to lead collaboratively.
Think of it like a dance: the roles are defined, but each partner adapts to the rhythm and needs of the other.
Working Together: A Mutual SLA Mindset
Treat each other like internal customers. Consider:
- Service-Level Expectations: Response times, story readiness, communication cadences.
- Feedback Loops: Retrospectives, incident reviews, product discovery cycles.
- Respect and Transparency: No surprises, no silos. Let Product into sprint planning; let Engineering into roadmap tradeoff conversations.
Wrapping up…
The most effective product organizations aren’t rigid about roles—they’re clear about responsibilities and generous in collaboration. When Product and Engineering recognize each other as mutual customers, the relationship shifts from transactional to transformative.
It’s no longer about who owns what. It’s about who helps whom win—and how you build a culture where serving each other is the default, not the exception.As author and consultant Esther Derby once said, “People don’t resist change. They resist being changed.” The best way to prevent that resistance is to show up not as a gatekeeper, but as a partner—and sometimes, as a grateful customer.
