Product Trio Shared-Decision Model
Let product, design, and engineering decide from one shared customer context.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 94%
The Product Trio Shared-Decision Model makes a product manager, product designer, and software engineer jointly responsible for discovery and solution decisions. Rather than assigning each function a protected territory or naming one person the product CEO, the trio works from the same customer stories, opportunity map, tests, and outcome. That common context removes many disagreements caused by unequal information. When a meaningful disagreement remains, the trio treats it as evidence that it has not found the best option and keeps searching for an alternative everyone can support. The model asks teams to relearn the natural collaboration that functional silos suppress. Its base unit can operate in a three-person company or a very large organization; at scale, the trio also shares discovery and coordinates dependencies with adjacent teams so the wider product remains coherent.
Origin
Torres promotes the trio after working on and coaching teams where product, design, and engineering genuinely decide together, despite widespread skepticism that shared decisions are practical.
Core principles
- 01Product decisions improve when functional perspectives collaborate instead of defending territory.
- 02The product manager, designer, and software engineer share responsibility for discovery.
- 03Shared customer understanding reduces disagreement before a decision is required.
- 04Persistent disagreement signals that the trio needs a better option.
- 05A common base unit can survive as the organization grows.
How to run it
- 1
Form the trio
Bring a product manager, designer, and software engineer into one decision-making unit. Make each discipline a participant in discovery rather than a downstream recipient.
Pro tip Choose people who can stay involved across repeated discovery and delivery cycles.
Watch out A trio in name only will preserve silos if evidence is still handed from one function to another.
- 2
Share an outcome
Give the trio one outcome to influence and the authority to explore how to reach it. This replaces competing functional objectives with a common result.
Pro tip Use the outcome to judge options without granting one discipline automatic authority.
Watch out A prescribed solution makes shared decision-making mostly ceremonial.
- 3
Discover together
Include all three members in customer interviews, opportunity framing, solution generation, and assumption testing. Build one shared body of evidence.
Pro tip Discuss observations immediately while the context is fresh for everyone.
Watch out Summaries cannot fully replace hearing customer context and trade-offs together.
- 4
Generate joint options
Create solutions that incorporate product, design, and engineering perspectives. Compare options against the shared outcome and customer understanding.
Pro tip Make disagreement concrete by identifying which evidence or assumption each person interprets differently.
Watch out Do not turn the discussion into a contest over which function owns the decision.
- 5
Treat disagreement as evidence
If the trio cannot support an option, assume the current option set is insufficient. Seek a better alternative or gather the evidence needed to reconcile the disagreement.
Pro tip Ask what new option would resolve the underlying concerns rather than forcing a vote.
Watch out Premature escalation to a single decider restores the power dynamic the trio is meant to remove.
- 6
Coordinate laterally at scale
Share relevant discovery with adjacent teams and manage dependencies, patterns, and libraries as the organization grows. Preserve the trio as the base decision unit while protecting product coherence.
Pro tip Coordinate where experiences intersect instead of adding hierarchy inside every local decision.
Watch out Local autonomy without lateral communication can fragment a large product.
In the wild
An illustrative trio shares customer stories and an outcome but disagrees over a proposed workflow. Instead of letting the product manager decide or asking each function to defend its territory, the members identify the assumptions behind their objections. They generate another option that preserves the desired customer experience, fits the technical constraints, and still supports the outcome.
→ The disagreement produces a stronger solution rather than a political winner and two reluctant implementers.
Common mistakes
Calling the PM the product CEO
Giving one function final authority encourages territorial behavior and weakens genuine cross-functional collaboration.
Sharing conclusions instead of context
A trio cannot develop shared understanding if only one member conducts discovery and reports the answer to the others.
Forcing agreement on a weak option
Persistent disagreement may mean the trio has not found its best option. A forced vote hides that signal instead of using it.
Is it for you?
Best for
Product organizations that can give a product manager, designer, and software engineer shared access to discovery and an outcome.
Not ideal for
Organizations where one function must unilaterally prescribe solutions and the other disciplines cannot participate in discovery.
From the episode
Teresa Torres on how to interview customers, automating continuous discovery, the opportunity solution tree framework, making the case for user research, common interviewing mistakes, and much more