Product trios model

Why the model exists

Most product orgs default to a sequential pipeline. PMs frame the problem and write the brief. UX is brought in once the problem is defined. Engineering is brought in once the solution is mostly decided. Each function does its work well in isolation; the system as a whole hands off, defends, and reacts.

The trios model is built on a different bet: that the shape of the team should match the shape of a good product decision. Good decisions weigh customer need, technical feasibility, and business value at the same time. Sequencing the functions means most decisions are made before all three perspectives are in the room. The trios model puts them in the room from the start.

It is not about hierarchy and not about adding process. It is about embedding the right perspectives into every decision that matters, from discovery through delivery.

The trio

A product trio is three people who lead the work together, each with clear ownership and shared accountability:

• Product Manager owns the why. What is the customer problem? What is the business goal? Where does this fit in the product vision?
• UX Designer owns the what. What is the right experience? What is the best solution for the user? What validates that the solution works?
• Engineering Manager owns the how. How will we build this? What is feasible? What is sustainable in the system?

Accountability is clear, but the work is not sequential. The trio succeeds together or fails together. No one can say “that is not my area” if the team is stuck.

Shared accountability, in practice

The model expects a specific set of behaviours. They are simple to name and harder to sustain:

• A weekly or bi-weekly trio sync.
• Backlog grooming run together, not handed off.
• Joint customer interviews and user testing where possible.
• Design sprints or problem-framing sessions co-led, not chaired by one function.
• Regular check-ins on delivery health and risk.
• Shared responsibility to unblock the team.
• Visibility and clarity for stakeholders, not gatekeeping by any one role.

Healthy trios feel different to work in. There is less waiting, less guessing, fewer surprises. Less herding cats and more shared leadership.

What changes for each role

The model asks something different of each function. The role names do not change; the operating mode does.

For Product Managers, the shift is from decider to co-leader. The PM is still accountable for product market fit, business goals, and the answer to “why now?” They are no longer expected to have all the answers alone. Discovery becomes a shared activity. Backlog grooming, planning, and roadmap conversations happen in the trio. The PM moves up the value chain to outcomes, strategy, and long-term vision, because they are no longer managing every detail solo.

For UX, the model is a promotion of perspective, not just craft. Designers are now in the room where the problem is shaped, not downstream of it. They lead discovery, set experience-quality standards, and influence trade-offs as equal stakeholders in outcomes. The expectation rises with the seat: more depth on framing and synthesis, more responsibility for steering, less time defending decisions already made.

For Engineering Managers, the role widens from delivery coordination to product co-ownership. The EM brings the engineering voice early, partners with Tech Leads to surface feasibility and architecture before solutions are locked, and connects engineers to the customer’s reality rather than filtering it through PM. They still own delivery health, but in a shared-responsibility model.

Resolving disagreement

Trios disagree. The model assumes this and gives the trio a sequence for working through it before escalating:

1. Recentre on the outcome. Ask what success looks like. Use the agreed metrics, JTBD insight, or goal as the compass. Most disagreements are about competing outputs and dissolve when the conversation returns to outcomes.
2. Surface the trade-offs. Articulate the pros and cons of each path: user impact, engineering cost and timeline, alignment with business goals. A shared decision matrix (value against effort, risk against reward) helps make the trade-off visible.
3. Test instead of debate. If two viable paths emerge, prototype both. Use feedback, technical spikes, or small experiments to break the tie with evidence rather than opinion.
4. Bring in a neutral facilitator. If the trio is still stuck, pull in a fourth voice: a Design Manager, Engineering Director, or Group PM. Their job is not to choose, but to clarify priorities and uncover assumptions.

The PM is the tie-breaker if alignment cannot be reached. This is not a power play; it is about accountability. The PM is ultimately answerable for delivering the business outcome, so when consensus fails, the PM decides and owns the risk. The best PMs make final calls rarely, because they have built a culture of trust where the earlier steps usually resolve the disagreement.

Disagreements that escalate to the tie-breaker should be surfaced upward to the trio’s coaching layer. Patterns matter more than individual calls.

Lifecycle ownership

The model is paired with a RACI that walks through the product lifecycle, so trios share a vocabulary for who does what at each stage:

Stage	Owner	What happens
Opportunity	Trio	Spot the problem worth solving. PM frames the why, UX brings the user signal, EM brings the system view.
Strategy	PM with trio	Set the goal, the success measure, and the bet. The trio shapes it together.
Discovery	UX with trio	Lead research, problem framing, JTBD work. The trio attends customer conversations together.
Definition	Trio	Decide scope and approach. Trade-offs surfaced; decisions logged.
Design	UX	Produce the experience. PM and EM consulted continuously; not signed off in isolation.
Delivery	EM with trio	Build, ship, monitor. Trio tracks delivery health and risk together.

The RACI is a tool, not a rulebook. It exists to help trios converge on shared expectations, not to police every decision.

The coaching layer

Trios cannot scale on autonomy alone. Autonomy without alignment fragments. The model pairs each cluster of two to five trios with a Group Leadership Trio (GLT): a senior PM, a Design Manager or Lead, and an Engineering Director, jointly responsible for the cluster’s success.

The GLT is responsible for:

• Strategic alignment. Ensuring trios are working on the right problems, with shared objectives.
• Trio coaching. Developing cross-functional collaboration skills in PMs, designers, and engineers.
• Portfolio oversight. Tracking delivery, discovery maturity, and outcome metrics across the cluster.
• Escalation support. Resolving conflicts and unblocking trios constructively, without taking over.
• Craft leadership. Cultivating domain expertise and growth through 1:1s, reviews, and mentorship.

The GLT is a structured cadence, not a meeting culture. A bi-weekly sync for proactive alignment, a monthly portfolio review for strategic oversight, a quarterly trio health review for team development, and an as-needed escalation channel.

The point of the coaching layer is to model the cross-functional dynamic the trios themselves are expected to run. A senior PM, design lead, and engineering director leading a cluster together is what teaches trios how to do the same.

When the model works and when it does not

The model expects three things that not every org has:

• Senior PMs willing to lead through influence rather than control. If the PM treats the trio as a delegation pattern, the model fails.
• Designers and engineers willing to take strategic responsibility. If either function treats the trio as an upgrade in title without an upgrade in ownership, the model fails.
• A coaching layer that genuinely coaches. If the GLT becomes a status meeting, the model fails.

When those three are present, the model is straightforward to communicate and slow to install. The decks pitch the change well; the day-to-day muscle (who facilitates, when to test instead of debate, how to escalate without undermining trio autonomy) takes practice. That muscle is the work the GLTs do.

What this is not

It is not a meeting structure. It is not a delegation model. It is not a way to share blame. It is a deliberate redesign of where decisions get made, so that customer need, business value, and technical feasibility are weighed at the same time, by the people closest to the work, every time.