handbooksThe product trio
Why a product manager, a designer, and an engineer make discovery decisions together, what each one catches that the others miss, and how to run this when your team is not a tidy group of three.
- The trio is a product manager, a designer, and an engineer who make discovery decisions together rather than in sequence.
- The point is coverage. Each role notices a different class of risk, and the risks the others cannot see are the ones that sink features.
- The guiding question is simple: how many discovery decisions can I get all three disciplines into?
- No designer? No dedicated engineer? The trio is a target, not a gate. Two people beat one.
Three views of the same idea
decisions
Any product idea can fail in ways that a single role is poorly placed to notice. A product manager reading a business case will not usually spot that the flow requires four taps where users expect one. A designer will not usually spot that the data needed to personalize the screen does not exist in a queryable form. An engineer will not usually spot that the segment being designed for is worth very little revenue.
| Role | What they see first | The question they ask that nobody else does |
|---|---|---|
| Product manager | Business value, market context, priority | Should we build this at all? |
| Designer | The customer's experience of it | Will anyone understand how to use it? |
| Engineer | Cost, constraints, what is possible now | What could we try this week instead of this quarter? |
The engineer's question is the one teams underuse. Engineers routinely know a cheaper way to test the same idea, and they only say so if they are in the room while the idea is still soft.
Together, not in sequence
The common arrangement is a relay: the product manager decides, the designer makes it usable, the engineer builds it. Each handoff carries a decision the next person cannot reopen without looking obstructive.
Discovery works the other way. The three of them sit in the same interview, look at the same tree, and argue about the same set of ideas before any of it is settled. It costs more calendar time up front and saves the far larger cost of building the wrong thing carefully.
How can I include all three disciplines in as many discovery decisions as I can? That is the whole rule. Everything else about trio structure is detail.
Interview together, act together
When the trio attends interviews as a group, three things happen that reading a research summary does not produce.
- Each person hears the thing relevant to their own risk. The designer hears hesitation. The engineer hears a workaround the customer built. The product manager hears what they pay for today.
- Nobody has to be convinced afterwards. A team that heard the same customer say the same sentence does not spend a meeting debating whether the finding is real.
- The follow-up questions get better, because the person who cares most about a given risk is present to ask.
One person interviews and the others take notes and ask at the end. Rotate who leads.
The most common failure is delegating interviews to whoever has time, then distributing notes. Notes carry findings. They do not carry the doubt, the tone, or the pause before an answer, which is usually where the real insight is.
When you do not have a trio
Most teams reading this do not have three named people with time. The trio is a target to move toward, not a prerequisite.
| Your situation | What to do |
|---|---|
| No designer | Invite the engineer anyway. Two perspectives beat one, and you can borrow design review later |
| Engineers are "too busy" | Ask for one 30-minute interview a month, not a standing commitment. Almost nobody says no to that |
| You share a designer across teams | Get them to the interviews that touch their surface, and the idea sessions for those |
| You are a team of one | Find any second person who will listen to a recording with you and disagree |
| Large team, everyone wants in | Keep the decision-making group at three. Others can watch interviews without joining the decision |
The last row matters more than it looks. Adding people past three slows decisions without adding much coverage, and a slow trio quietly stops meeting.
Balancing speed against inclusion
Define who the trio is, explicitly, and let everyone else know they are welcome to observe. An unstated trio becomes either a bottleneck of one person deciding alone, or a committee where nothing is decided.
Look at the last five product decisions your team made. Count how many had a designer and an engineer in the room while the decision was still open. That number, not your org chart, is your real trio.