Working with Engineering and Design

Product management is fundamentally collaborative — the PM works closely with engineering and design to actually build the product. This post covers the product-engineering-design collaboration (the “trio”), how they divide and share work, how PMs communicate what to build, and how to make the collaboration work. It’s the “how product gets built together” post, especially relevant for engineers (the PM-engineer relationship). Good collaboration here is what turns product decisions into shipped products.

The product trio

Modern product development centers on a collaboration among three roles — product, engineering, and design — often called the “product trio”:

• Three roles, three concerns. Product (PM) owns what and why (the problem, value, priorities — the PM posts); engineering owns how (building it — feasibility, implementation); design owns the experience (usability, how it looks and feels — the user’s experience). Three complementary concerns — value, feasibility, usability — covering what a good product needs. Each role owns a distinct dimension. Value, buildability, usability.
• They collaborate, not hand off. The trio collaborates continuously — not a handoff (PM writes a spec → design mocks it → engineering builds it, in sequence) but a partnership where all three work together (discovering, deciding, and building collaboratively). Handoffs lose context and quality; collaboration produces better products. The trio works together, not in a relay. Partnership, not relay.
• No one is the boss. The three are peers — none commands the others (the PM isn’t the boss of engineering or design, from the first post). They collaborate as equals with different expertise, deciding together (the PM facilitating and deciding on what/why, but respecting engineering’s and design’s domains). It’s a collaboration of peers, not a hierarchy. Peers, not a chain of command. Equals with different expertise.

Modern product development centers on the product trio — product (what/why), engineering (how), and design (experience) — three peers with complementary concerns (value, feasibility, usability) who collaborate continuously rather than hand off in sequence, with no one commanding the others. This collaboration is how good products get built. It works best when the roles both own their domains and share the work.

Dividing and sharing the work

The trio both divides work (each owns their domain) and shares it (collaborating across domains) — understanding this balance is key:

• Each owns their domain. Respecting each role’s ownership matters: the PM decides what/why (don’t dictate the how to engineering or the design to designers); engineering decides how (the PM shouldn’t design the architecture); design decides the experience. Each owns their expertise and decisions. Respecting these boundaries reduces friction and lets each do their best work. Own your domain, respect others’. Stay in your lane, but collaborate across it.
• But they share and cross-pollinate. While each owns a domain, they share input across domains: engineers contribute product ideas and feasibility insight; designers contribute problem understanding; the PM contributes context — everyone’s input improves the whole. Ideas and input flow across the roles (not siloed). Ownership of decisions in your domain, but shared input across all. Own decisions, share ideas. Cross-pollinate freely.
• Feasibility is a shared conversation. A key cross-domain interaction: feasibility — engineering informs the PM about what’s feasible, the cost of options, and technical tradeoffs, so the PM’s what/why decisions are grounded in engineering reality. This feasibility conversation (PM’s what meets engineering’s how) is central and collaborative — the PM shouldn’t decide what to build ignorant of feasibility, nor engineering build without understanding the why. Feasibility is a shared, ongoing conversation. What meets how, collaboratively.
• The best solutions emerge from collaboration. Because the roles have different expertise (value, feasibility, usability), the best product solutions emerge from their collaboration — combining perspectives — not from any one role dictating. Collaborative problem-solving across the trio beats siloed decisions. Best products come from combined expertise. Together beats alone.

The trio divides work (each owns their domain’s decisions — PM the what/why, engineering the how, design the experience) and shares it (input flows across domains, especially the feasibility conversation), with the best solutions emerging from collaboration. Owning your domain while sharing input across is the healthy balance. Communicating what to build is a key part of this.

Communicating what to build

The PM must communicate what to build to engineering and design — and how this is done well (and the anti-patterns) matters a lot, especially to engineers:

• Communicate the problem and the why, not just specs. The most important thing a PM communicates is the problem and the why (what we’re solving and why it matters) — not just a detailed spec of what to build. When engineering and design understand the problem, they can contribute better solutions (and build with judgment). Communicating why (not just what) empowers the team. Share the problem, not just the solution. Context over commands.
• Avoid over-specifying the “how.” A PM anti-pattern is over-specifying — dictating detailed implementation (the “how”), which is engineering’s domain, and detailed design, which is design’s. Good PMs communicate what and why clearly and leave the how (and design details) to the experts, who’ll often find better solutions. Over-specifying disrespects the team’s expertise and produces worse results. Don’t over-specify the how. Trust the experts with their domain.
• Requirements as problems/outcomes, not just feature lists. Better “requirements” describe the problem to solve and desired outcome (giving the team room to find the best solution) rather than a rigid feature spec (dictating the exact solution). Outcome/problem-oriented requirements (like outcome-oriented roadmaps) empower better solutions than prescriptive ones. Requirements of problems, not just features. Specify the goal, not every detail.
• User stories and shared understanding. A common format is user stories (describing a need from the user’s perspective — “as a [user], I want [goal] so that [reason]”) which keep focus on the user’s problem/goal. But formats matter less than shared understanding — the goal is the team genuinely understanding the problem and what to build, however that’s communicated. Shared understanding over rigid documents. Understanding is the point.

Communicating what to build means conveying the problem and why (not just specs), avoiding over-specifying the how (engineering’s domain), framing requirements as problems/outcomes (not rigid feature lists), and above all building shared understanding (user stories are one tool). This empowers engineering and design to contribute their best. Making the whole collaboration work has some keys.

Making the collaboration work

Bringing it together, what makes the product-engineering-design collaboration work well — and why it matters especially to engineers:

• Mutual respect for expertise. The collaboration works when each role respects the others’ expertise — the PM respects engineering’s and design’s domains, and vice versa. Mutual respect (each is expert in their area) enables genuine collaboration rather than friction or hierarchy. Respect each other’s expertise. Value what each brings.
• Shared understanding of the problem. The team collaborates best when everyone understands the problem (not just the PM) — shared problem-understanding lets everyone contribute solutions and build with judgment. Investing in shared understanding (the PM communicating the why, the team engaging) is foundational. Everyone understands the problem. Shared context, shared ownership.
• Trust and good relationships. Like any collaboration, it runs on trust and good working relationships (the EQ series) — trust that each does their part well, and relationships that make working together smooth. Building trust across the trio (through reliability, respect, communication) makes the collaboration effective. Trust makes collaboration work. Relationships underpin it.
• For engineers: engage with the why. For engineers specifically, working well with product/design means engaging with the why (understanding the problem, contributing product/feasibility input) rather than just receiving specs to implement. Product-minded engineers who engage in the collaboration (not just execute) build better products and grow. Engage with the product, don’t just execute. Be a partner, not an order-taker.

Working with engineering and design is the collaborative heart of product management — the product trio (product, engineering, design) as peers who divide and share work, communicate via shared problem-understanding (not just specs), and run on mutual respect, trust, and everyone engaging with the why. For engineers, engaging as a partner (not an order-taker) is how to work well with PMs and build better products. Next: metrics and data — measuring whether the product is working.

Key takeaways

• Modern product development centers on the “product trio” — product (owns what/why — value/priorities), engineering (owns how — feasibility/building), and design (owns the experience — usability) — three peers with complementary concerns who collaborate continuously rather than hand off in sequence, with no one commanding the others.
• The trio both divides work (each owns their domain’s decisions — respect the boundaries: the PM doesn’t dictate the how or the design) and shares it (input flows across domains — engineers contribute product ideas, the feasibility conversation is shared) — the best solutions emerge from combining the three perspectives.
• Communicating what to build means conveying the problem and why (not just detailed specs — so the team can contribute better solutions), avoiding over-specifying the how (engineering’s domain), and framing requirements as problems/outcomes (giving room for the best solution) rather than rigid feature lists — with shared understanding the real goal (user stories are one tool).
• The collaboration works on mutual respect for each other’s expertise, shared understanding of the problem (everyone, not just the PM), and trust/good working relationships (the EQ skills) — respect, shared context, and trust enable genuine collaboration over friction or hierarchy.
• For engineers specifically, working well with product/design means engaging with the why (understanding the problem, contributing product and feasibility input) as a partner rather than just receiving and executing specs — product-minded engineers who engage build better products and grow.

Further reading

• Agile software development — collaborative product development (Wikipedia)
• User story (Wikipedia)
• Product strategy and vision (previous post)