Working With Product Managers: The Product Trio and Healthy Tension
How to work with a product manager without handoffs or opinion wars: Teresa Torres's product trio, the problem-solution split, and how to handle disagreements.
What is the product trio?
Torres popularized it in Continuous Discovery Habits (2021). Most trios have a product manager, a designer, and an engineer, but the model can expand or contract: a machine learning team might add a data scientist. What stays constant is the central idea: the trio leads discovery for the work the rest of the team builds, and it is not separate from the delivery team (Product Talk: Product trios).
In practice, the trio interviews customers, maps opportunities, chooses which outcomes to pursue, generates solutions, and tests them together. Torres recommends that the whole trio take part in research, even when the team has a researcher, so that everyone gets firsthand contact with customers and the learning does not stay in one head.
How are responsibilities shared?
A common split says the product manager defines the problem and the designer defines the solution. Torres warns that this division sounds a lot like waterfall with handoffs: defining the problem and generating solutions form a back-and-forth loop, and separating them cuts the feedback. Her advice is to focus more on who does what and less on who owns what, because the line between roles is hazy at best (Product Talk: Product managers don’t own the problem).
In another text, Torres proposes that everyone is responsible for every risk: desirability, viability, feasibility, usability, and ethics. Engineers contribute more on feasibility and PMs on viability, but no one owns a risk alone. Torres rejects labels such as “feasibility lead” (Product Talk: Responsibility in a product trio).
For a designer, this means usability is not exclusively theirs, and viability is not only the PM’s task. What changes is the kind of conversation: instead of “that is not my area,” the question becomes “which risk are we leaving unchecked?”
How are disagreements resolved?
A reasonable practice is not to settle disputes by rank. First, explore the different perspectives: each person explains which risk they see and why. If the team is still stuck, turn the argument into an assumption you can test with a cheap test, such as a prototype and five people. To find a third option, the “how might we” format helps you move beyond a debate between two alternatives.
A practical suggestion is to write down in the team charter how decisions get made. It does not need to be a long document: one page that says who proposes, who decides, and how a doubt gets tested is enough to keep disagreement from turning into a war of opinions.
If the disagreement is about what to research, a shared research plan, with questions written by the trio, reduces the argument to one question to resolve.
What tension is healthy?
Being accountable for a risk outside your specialty creates a discomfort that drives collaboration: according to Torres, it pushes the designer to work through feasibility trade-offs with the engineer. But watch the tension: if roles are rigid, the discomfort disappears. Torres warns that assigned responsibilities become ingrained, and teams forget to break out of them.
A healthy sign is that the designer and the PM discuss a flow without asking a manager for permission. A worrying sign is that one of them says “that’s the other person’s call” every time there is a conflict. None of this means everything is decided by consensus: someone still has to close the decision. What changes is that the decision is reached on evidence visible to everyone.
Illustrative example
Illustrative example: a product manager wants to launch a four-step payment flow in two weeks. The designer believes the address step confuses half of users. Instead of arguing about who is right, the trio proposes an assumption test: five people complete the flow in a prototype with a written task. Three stop at the address step. The PM narrows the scope: the flow becomes three steps and the address uses autocomplete. The engineer checks the feasibility of autocomplete in an afternoon. The decision is made on evidence, and nobody had to win the argument.
To see how discovery and delivery are divided, read dual-track agile. And if the conversation that gets stuck is about strategy, product strategy vs. UX strategy clarifies who decides what.
Common mistakes
- Letting the PM write the requirements while the designer only makes screens.
- Settling a disagreement because one person has more seniority.
- Assigning fixed risks, such as “the engineer always validates feasibility.”
- Waiting until you have all the information before talking to the PM.
- Treating friction as a sign that something is wrong, when it may mean the process is working.
- Taking a disagreement to a large meeting instead of resolving it within the trio.
What you can do tomorrow
- Write on one page which decisions the PM makes, which ones you make, and which are made together.
- For the next disagreement, ask: what cheap test would tell us which option works?
- Propose a fifteen-minute session to review a risk that nobody is looking at.