What is a Product Trio — and why our company is named after it

In April 2026, I posted something on LinkedIn that hit a nerve. "People keep saying AI finally 'broke' the old linear product management model. But AI didn't fix product management. You just finally admitted you were doing waterfall."

The reason it resonated: most product teams — regardless of what their process is called — still operate the same way. The PM defines. The designer designs. The engineer builds. In sequence. With handoffs at every step.

Marty Cagan wrote about a better way in 2008. Teresa Torres made it a practical discipline in 2021. I've been running workshops on it for years, and built my entire advisory practice around the idea. We named the company ProductTrio after it.

Here's what it actually is — and why it matters more than almost any other structural decision a product team makes.

What "fake agile" actually looks like

Most teams running two-week sprints are doing what Itamar Gilad calls "Agile Waterfall." The delivery cadence is fast. The discovery process is still linear.

It goes like this: the PM gathers requirements and writes a spec. The designer creates mockups based on the spec. The mockups go to the engineers, who surface feasibility issues the designer didn't know about. Everyone goes back a step. Or worse — they push through anyway and ship something that doesn't work quite right.

Nobody means for it to happen. It's a structural problem, not a people problem. When the people responsible for building the product aren't involved in understanding the problem, you get avoidable surprises at every handoff.

What a Product Trio is

A Product Trio is three people working together — not in sequence — throughout the entire product discovery process:

• The Product Manager
• The Product Designer
• The Lead Engineer (or technical lead)

The concept was introduced by Marty Cagan in Inspired and later named and operationalized by Teresa Torres in Continuous Discovery Habits. The word "trio" matters: it's not a committee, not a working group, not a three-person sign-off chain. It's the core unit that explores problems and builds solutions together.

They do customer interviews together. They review research together. They ideate solutions together. They decide what to build, in that order, and only then does execution split into its natural streams.

The four risks — and why the trio addresses all of them

Here's the deeper reason the trio structure works. Every product idea faces four risks before it earns the right to be built. Cagan lays them out clearly:

• Value risk — will customers actually buy or use it?
• Usability risk — will users understand how to use it?
• Feasibility risk — can engineering build it with the time, skills, and technology available?
• Business viability risk — does it work for the business, not just the customer?

Now look at what each member of the trio owns:

• The Product Manager is accountable for value and business viability. They ensure the idea solves a real problem customers care about and that the solution works for the business.
• The Product Designer is accountable for usability. They ensure customers can figure out how to use what's being built.
• The Lead Engineer is accountable for feasibility. They know what's actually buildable — quickly, reliably, at scale.

When the trio works together from the beginning of discovery, all four risks are being assessed at the same time, by the people most qualified to assess them. When they work in sequence, each risk gets evaluated in isolation — and the person doing the assessment lacks the context the other two have.

What actually changes when the trio is in place

The most visible change is speed. When the designer proposes a solution, the engineer in the room immediately flags what's technically complex and what isn't. When the PM frames an opportunity, the designer sees how users might respond. When the engineer pushes back on scope, the PM can weigh that against customer value in real time.

Ideas that wouldn't have survived get killed early. Ideas that might have seemed risky turn out to be buildable in a day. The friction that normally comes from handoff points — "we need to go back to design," "engineering says this isn't feasible," "legal flagged this" — gets absorbed into the discovery process, where it's cheap to handle, instead of surfacing after the sprint has started.

You also get shared context in a way that documentation can't replicate. When three people sit in a customer interview together, they hear the same words, observe the same hesitations, react to the same surprises. They're building a shared mental model of the customer's world — and that model informs every decision they make afterward, without needing to be translated through a spec.

The most common objection

I hear this regularly in workshops: "This is fine for big companies with dedicated resources. We can't afford to pull the engineer away from building."

It's understandable, but it misreads the math. If the engineer's job is to build the right thing, then time spent understanding what the right thing is is not a distraction from their job — it is their job. The alternative is to build fast in the wrong direction and pay the cost later.

The trio doesn't require the engineer to attend every interview (though it helps). It requires that discovery is not done in isolation from engineering. At a minimum: the lead engineer should be present for customer interviews periodically, for assumption-testing sessions, and for any significant ideation work. That's not "pulling someone away." That's structuring the team so decisions are informed by the people responsible for executing them.

How to start forming trios

If your team doesn't have an explicit trio structure, the starting point is simple:

1. Name the trio — identify the PM, designer, and lead engineer who are responsible for the next significant product bet together.
2. Run one discovery session together — a customer interview, a problem-mapping session, an assumption audit. Let the trio experience what it's like to be in the room together before you build anything.
3. Debrief together — what did each person notice that the others missed? That asymmetry is exactly why the trio exists.

You don't need a new process, a new tool, or a new framework. You need three people who are all accountable for the outcome — not just their slice of execution — and the discipline to include all of them before the building starts.

Why we named the company ProductTrio

When I started running Product Discovery workshops and fractional engagements, I kept encountering the same root problem: teams structured around disciplines — not around shared outcomes. Product over here. Design over there. Engineering downstream.

The trio model is the clearest antidote to that structure I've found. It doesn't require reorganizing your company or overhauling your process. It requires that three people — the PM, the designer, the engineer — agree to be accountable for the same thing, and to discover it together.

That's the practice I've built this work around. And it's why the company is called ProductTrio.

AI is making each role individually more capable. That's accelerating the trio model — not replacing it. The best product teams figured this out before the tools caught up. Now the tools are there. There's no excuse left for the relay race.