Customer & product
Opportunity Solution Tree
A visual tree connecting a desired outcome to the customer opportunities that could drive it, the candidate solutions for each opportunity, and the assumption tests that decide which solutions survive, so discovery work stays traceable from experiment back to outcome.
Also known as OST, Opportunity tree. First set out by Teresa Torres in 2016; the primary source is cited in full below.
Where this is contested
Attribution to Torres is clean, but the canonical form has evolved in her own hands: the root was originally framed as a desired or business outcome and later tightened to a product outcome, and the 2021 book's version differs in detail from the 2016 blog original.
- Format
- Mapping
- Level
- Product · Team
- Best for
- Understand customers · Prioritise · Evaluate options
- Decision stage
- Diagnose · Explore options · Decide
- Difficulty
- Intermediate
- Time to apply
- A few hours to draft a first tree from existing research; the method only pays for itself sustained over weeks of interviewing and testing.
Plate · The model
The components
Desired outcome
The root of the tree: a measurable product outcome, a change in customer behaviour that the team believes drives business value. It defines the scope of the whole tree; branches that do not plausibly move it do not belong.
Signals of strength
Expressed as a metric the team can influence · Negotiated with leadership, not assigned as output · One outcome per tree
Opportunity space
The middle of the tree: customer needs, pains and desires drawn from interviews, structured as parent and child branches. Framing matters; opportunities are phrased in the customer's world, never as missing features.
Signals of strength
Each opportunity traceable to interview evidence · Phrased in the customer's voice · Siblings distinct, children genuine subsets of parents
Solutions
Candidate products, features or changes attached to a specific target opportunity, held several at a time so they can be compared. A solution with no parent opportunity is a stakeholder wish, and the tree makes that visible.
Signals of strength
Three or more in play for the target opportunity · Each linked to exactly one opportunity · Generated after the opportunity was chosen, not before
Assumption tests
The leaves: small, fast experiments against the riskiest assumptions underneath a solution, across desirability, viability, feasibility, usability and ethics. Their verdicts prune the solution layer and occasionally reshape the opportunity space above it.
Signals of strength
Tests target named assumptions rather than whole ideas · Days to run, not sprints · Results recorded against the tree and acted on
When it earns its keep
- Your team is measured on an outcome, such as a retention or engagement metric, and needs a structured route from that number to concrete product work.
- Stakeholders keep handing the team solutions, and you need an artefact that shows which customer need each idea serves, or that it serves none.
- You run regular customer interviews and want somewhere for the accumulating needs, pains and desires to live, compare and compete.
- The team habitually falls in love with its first idea, and you want compare-and-contrast pressure built into the process.
And when it doesn't
- There is no meaningful discovery to do: the work is a regulatory requirement, a contractual commitment or a straightforward fix. A tree adds ceremony without information.
- The team has no access to customers. The opportunity space is built from interview evidence, and a tree grown from internal opinion is an org chart of guesses.
- No outcome has been agreed. Without a root, the tree cannot arbitrate between branches; secure the outcome first, from OKRs or equivalent.
- You need a delivery plan with dates. The tree structures learning and option selection; it is deliberately not a roadmap and resists being read as one.
How to run it
Before starting, gather the inputs the analysis depends on:
- A negotiated product outcome: a measurable change in customer behaviour the team can influence, distinct from a business outcome like revenue.
- A steady stream of customer interview data, ideally weekly, from which opportunities are harvested in the customers' own words.
- A cross-functional trio (product, design, engineering) who share the discovery work rather than receiving its conclusions.
- Willingness to hold multiple solutions per opportunity in play at once, and to kill some of them cheaply.
- 1
Set the root outcome
Agree the product outcome the tree serves: a measurable change in customer behaviour, such as the share of new users reaching a key action, rather than a business result like revenue that the team cannot directly move. Torres treats negotiating this outcome with leadership as part of the method.
- 2
Map the opportunity space
From interview evidence, capture needs, pains and desires as opportunities, phrased in the customer's voice, and structure them into parent and child branches. The structure is the thinking: sibling opportunities should be distinct, and a child should genuinely be a case of its parent.
- 3
Prioritise a target opportunity
Compare sibling branches on opportunity sizing, market and company factors, and pick one target at a time. This is a two-step decision, made branch by branch down the tree, and it is revisited as evidence accumulates rather than fixed for a quarter.
- 4
Generate competing solutions
Ideate several solutions for the target opportunity, and keep at least three in play. Torres's compare-and-contrast rule exists because a single solution gets evaluated against nothing and therefore always wins.
- 5
Break solutions into assumptions and test them
Decompose each candidate into desirability, viability, feasibility, usability and ethical assumptions, identify the riskiest, and run small, fast tests: prototypes, fake doors, data probes. Test assumptions rather than whole ideas, because assumptions are cheaper and faster to settle.
- 6
Keep the tree alive
Update it weekly as interviews add opportunities and tests kill solutions. The tree is a living map of the team's current beliefs, and its value decays quickly once it stops reflecting them.
Reading the result
A living, shared map from outcome to opportunities to solutions to tests, giving the team a defensible answer to 'why are you building this' at every level. The canonical form is a vertical tree branching downwards from the outcome; this entry lists the four layers as a sequence, and the branching rendering should be kept in mind when drawing one.
- Read top down for rationale: every test should trace to a solution, an opportunity and the outcome. A leaf that cannot make that walk is discovery theatre.
- Read the opportunity layer for balance. One enormous branch and several twigs usually means the framing needs splitting, or the interviews are only reaching one kind of customer.
- Read the solution layer for monogamy. Opportunities with a single attached solution signal a team evaluating an idea against nothing.
A worked example
A fitness wearable's companion app team attacks twelve-week retention
The companion-app team at a UK fitness wearable maker is set a product outcome: raise the share of new buyers still syncing workouts at twelve weeks from 34 to 45 per cent. Weekly interviews with lapsed and active users feed an opportunity solution tree that the trio updates every Friday.
- Desired outcome
- Root: 'Increase the percentage of new device owners still syncing at least one workout a week at week twelve.' Negotiated down from the commercial ask, subscription revenue, to a behaviour the app team can actually move.
- Opportunity space
- Interviews yield three parent branches, in customers' words: 'The novelty wears off and nothing pulls me back', 'I don't understand what my numbers mean for me', and 'Logging my gym sessions is a faff'. Under the third sit children: rest-timer fiddliness, unrecognised strength exercises, manual set entry.
- Opportunity space
- Sizing against interview frequency and drop-off data makes 'Logging my gym sessions is a faff' the target: it appears in 60 per cent of lapsed-user interviews, and gym-goers churn fastest despite being the highest-value segment.
- Solutions
- Three candidates attached to the target: automatic set detection from wrist motion, one-tap workout templates built from a user's history, and voice logging between sets. A stakeholder pet idea, a social feed, is parked visibly on the tree with no parent opportunity.
- Assumption tests
- Riskiest assumptions tested in one week each: a feasibility spike on set-detection accuracy (fails at 71 per cent, below the 90 per cent bar), a fake-door test on templates (31 per cent tap-through from the workout screen), and concierge voice logging with nine users (transcription stumbles over gym noise).
The read. The tests prune the tree honestly: set detection is shelved until the sensor improves, voice logging is killed, and templates advance to a build with a follow-up usability test. The team can show leadership a straight line from the twelve-week retention target to the faff of logging to the template feature, and the social feed's absence from any branch settles that argument without a meeting.
Pitfalls
- Framing opportunities as missing features ('needs dark mode') rather than as needs, pains and desires in the customer's world. Feature-framed trees collapse into disguised backlogs.
- Growing the tree in a workshop from team opinion instead of interview evidence. The structure survives; the truth does not.
- Attaching one solution per opportunity. Without compare-and-contrast the tree becomes a justification device for the first idea.
- Treating the tree as a deliverable for stakeholders rather than a working map. If it is updated the night before a review, it is a slide, and it will behave like one.
- Skipping assumption decomposition and testing whole solutions. Whole-idea tests are slow and confounded; assumption tests are the mechanism that makes the tree cheap to prune.
What the critics say
The method is practitioner-recent and the academic literature on it is thin to non-existent: there are no peer-reviewed studies testing whether teams using opportunity solution trees achieve better outcomes, so the evidence base is testimonial and consultant-adjacent. That is an honest limit rather than a disqualification, and it should temper strong claims.
Practitioners note the tree assumes an outcome-first organisation. Where leadership hands teams solutions, the method has no purchase, and some have proposed working the tree in reverse to excavate the 'why' behind mandated solutions before the canonical form can be used at all.
Mind the Product, 'Reversing Teresa Torres' Opportunity Solution Tree to find the "why" behind solutions'.
The tree's usefulness is highly sensitive to opportunity framing, and catalogues of anti-patterns show most failures occur in that layer: vague or overlapping branches, solutions dressed as opportunities, and trees that quietly turn into feature backlogs. The method concentrates difficulty in its least teachable step.
'Opportunity solution trees: A list of anti-patterns to avoid', LogRocket Product Management blog.
Sources and further reading
- Torres, T. (2021) Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.
- Torres, T. 'Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes', Product Talk. ↗
- 'Opportunity solution trees: Definition, examples, and how-to', LogRocket Product Management blog. ↗
- Mind the Product, 'Reversing Teresa Torres' Opportunity Solution Tree to find the "why" behind solutions'. ↗