Product trio: what it is and how to set one up

Three people. Same product. The PM wrote a spec. The designer made mockups. The engineer scoped the work and said it would take twice as long as expected. Business cut scope. Cutting scope meant redesign. Redesign revealed new technical constraints. The timeline slipped again.

Six months passed. The feature shipped. Usage: near zero.

Nobody failed at execution. They succeeded at building the wrong thing — because three perspectives that should have collided early had each worked alone. By the time the engineer saw the spec, the assumptions baked into it had already calcified. By the time the designer finished, the problem had been pre-framed by someone else.

That's the handoff model. A product trio is the structural fix: a product manager, a designer, and an engineer who own discovery together — sharing the same customer evidence from the first interview to the final assumption test, accountable for the same outcome.

What is a product trio

A product trio is a product manager, a designer, and an engineer working together from the start of discovery through delivery — not a handoff chain, but shared ownership of the same outcome.

Teresa Torres defined the framework in Continuous Discovery Habits (2021). The logic is straightforward: building a digital product requires holding three risks at once.

• Business viability — Does this connect to our outcome? Is there a market for it?
• User desirability — Do customers actually struggle with this? Will this design solve the real problem?
• Technical feasibility — Can we build this in the time we have? What constraints are we working with?

In the handoff model, these risks are evaluated sequentially — weeks apart, after too much has been invested to back out. In a product trio, all three perspectives are in the room when decisions are made.

The trio is not a committee. It's the smallest group that can hold all three risks at the same time. The goal is to keep it to three people, or as close to that as possible. The bigger the decision-making group, the slower everything moves.

Some contexts call for a fourth — a user researcher when the product relies on heavy qualitative work, or a data scientist when the core questions are quantitative. That's a reasonable adaptation. The principle still holds: the smaller the core decision unit, the faster you can move and the clearer the accountability.

Why the handoff model produces features nobody uses

The waterfall model plays out the same way every time. PM gathers requirements from stakeholders, writes a document, hands it to the designer. Designer finds gaps and goes back to the PM. PM iterates. Designer finishes, hands to the engineer. Engineer scopes — estimate comes in at twice the expected cost. Business negotiates scope. Scope cuts require design changes. Design changes surface new technical constraints. The project slips.

Everyone did their job. Nobody checked whether the feature was worth building.

Most shipped features turn out to be barely used. "No market need" consistently ranks as the top reason startups fail — not bad engineering, not poor design, not slow delivery. The problem is deciding to build the wrong thing in the first place, usually because the three people closest to that decision never compared notes until the build was already underway.

How a product trio works in practice

The change is simple to describe and hard to install: all three people interview customers together.

Not: PM conducts research and shares a summary. Not: designer runs usability sessions and reports findings. All three people on the call, taking notes, debriefing afterward. When the whole trio hears the same customer describe the same frustration, they don't need to be convinced. They share the evidence.

From there, the trio maps what customers struggle with — the opportunity space. They generate solutions against real customer problems, not internally assumed ones. Before any work reaches the backlog, they pull out the riskiest assumption behind the idea and design a small test. Not all assumptions carry equal weight — some are usability risks (will people understand how this works?), some are feasibility risks (can it be built without accumulating debt?), some are viability risks (will it actually move the outcome metric?). Naming the type of risk helps the trio agree on which assumption to test first, rather than defaulting to whichever test is easiest to run.

When the test is done, the trio makes a call together: pursue, park, or kill. Recording that call — and the reasoning behind it — matters more than it seems. A killed idea without documented reasoning tends to resurface three months later when a new stakeholder asks why it was never built. The reasoning is what actually closes the loop.

Only after something survives testing does it move toward building.

This isn't just process discipline. It's what shifts the team from output ownership to outcome ownership. The engineer isn't accountable for delivery. The designer isn't accountable for the Figma file. All three are accountable for whether the feature actually moved the metric.

Each person still brings a different angle. The PM is tracking whether an idea connects to the outcome. The designer is checking whether users actually experience the problem the team is trying to solve. The engineer is looking at what the solution will cost — not just in sprint points, but in system complexity and future maintenance. The difference from the handoff model is timing: nobody waits for their turn. All three perspectives land on the same evidence at the same moment.

This is also where product management and project management diverge most clearly: the trio doesn't just track delivery — it shapes what gets built and why.

What makes most product trios fail

The most common failure mode: engineer as estimator, not discovery partner.

If the engineer's involvement starts when a Figma file arrives in their inbox, they are a delivery resource — not a trio member. Their perspective isn't shaping the solution; it's reviewing a decision already locked. That's the exact configuration the trio model is supposed to replace.

Four patterns that break the model in practice:

PM still owns discovery. If the designer and engineer are waiting to hear what the team is working on, it's not a trio — it's a PM with two direct reports. Shared discovery means all three generate ideas, not one person announces them.

Research as a kickoff activity. Discovery shouldn't be a two-week phase at the start of a quarter. The trio commits to at least one customer conversation per week, together, as a standing obligation — not as a project milestone.

No shared outcome. A trio without a specific, measurable outcome drifts back into feature mode. One outcome, owned by all three, is what makes the model coherent. Five outcomes or a vague goal produces the same silos the trio was meant to remove.

Trio expands into a committee. Bring in a data analyst, a customer success rep, and a marketer for every discovery decision and decision-making slows to a crawl. Consult others for their expertise; keep the core decision unit small. When roles genuinely overlap and clarity is needed, a RACI matrix can define who owns what without turning the trio into a working group.

Teresa Torres's CDH Benchmark Survey found that people working in product trios report being more satisfied with both their team and their company — one of the strongest signals across the entire study. The structure isn't just more efficient; it's better for the people inside it.

How to run a product trio in Vaiz

The product trio template in Vaiz is built around one idea: nothing reaches the build queue until it has survived testing. The board moves from customer interviews to opportunities to solutions to assumption tests — and only validated work gets promoted to development.

What makes it practical for the trio specifically: every card has fields for all three names, so shared ownership is on the surface rather than implied. There's a confidence level and an evidence counter on each item, so the team can see at a glance which ideas have customer backing and which are still internal guesses. A dedicated interview task type with dates means the weekly research cadence is trackable — not something the team assumes is happening, but something they can actually check.

The starting point

The trio model works best when discovery and delivery stay connected. Once the trio has validated what to build, keeping the broader team aligned on the delivery cycle is a separate discipline — agile workflows covers how to link what the trio discovers to what the sprint actually ships.