What is a Product Trio - and why our company is named after it
A Product Trio is the product manager, the product designer and the lead engineer, working as one team to decide what to build. They talk to customers, choose the problem and test solutions together, and share one outcome, instead of passing work down a line.
Most product teams are structured around handoffs: the PM writes specs, the designer designs, the engineer builds. That's not collaboration - it's a relay race. And you keep dropping the baton.
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 (I go through each one, and how to test it, in the 4 product risks that sink launches):
- 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.
How a trio works inside a bigger organization
In a startup, the trio is often the whole product team. In a bigger organization it is one unit among many, sitting between a strategy it didn't write and customers it has to learn from every week. Four things decide whether it works there, and I've seen each of them up close.
The trio gets an outcome, not a feature list. Leadership owns the strategy and gives each trio one number that shows progress toward it. The trio decides how to move it. When we started at Deviniti Apps, the product side of Deviniti, its teams worked from technical roadmaps, and success was counted in features delivered and development velocity. Everyone was busy. Nobody could say which of last quarter's releases had moved anything.
A trio on the org chart isn't a trio in practice. Before the pilot, we measured one Deviniti team, Luna. Every question about the trio came back at the top of the scale: who does what, which ceremonies they share, how value and viability are split. Focus came back lowest, because planning ran on story points. And asked who owns the outcome, two of the four said each role owns its own deliverables, and two said the team owns success together. The structure was there. The shared outcome wasn't.
Start with one trio, then copy what works. We didn't change every team at once. Deviniti's leadership and I put the method to work on Luna first, against one business number, trial-to-paid conversion. Over three months it went from 26% to 59%, and what the pilot proved became the template for the rest of the organization. The whole story is in the Deviniti case study.
Every trio guards the numbers it could hurt. In a bigger organization, one team's win can be another team's loss. At Taxfix I joined the Activation team as a fractional Senior PM, reporting to its Product Director, to merge the onboarding of two products into one. We defined the guardrail metrics before the first test: activation conversion, booking conversion, and product regret, people choosing the expert service and then backing out. Every readout ended in keep, iterate or kill against those guardrails. One concept lifted expert bookings and quietly dragged everything else down, and the guardrails are what turned it into a clear no.
Put together, it looks like this: outcomes flow down, evidence flows back up, and customers sit under every trio, every week.
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:
- Name the trio - identify the PM, designer, and lead engineer who are responsible for the next significant product bet together.
- 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.
- 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.
The first argument the trio will have is how much of the week belongs to discovery versus delivery. Settle it on risk rather than on the calendar: how to balance discovery and delivery.
One caveat if your organization is already part-way through a transformation. Naming a trio inside an org that still asks for features by name and date does not fix much on its own, and pushing the change org-wide usually backfires. That situation has its own playbook: getting unstuck from the messy middle.
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. If your team is currently arguing about who owns what because everyone can now produce everyone else's output, that standoff is worth reading about separately.
Standing up real trios across more than one team is exactly what Product Operating Model Transformation is for - and this piece on why delivery teams keep shipping the wrong things shows what's at stake when the trio isn't in place.
