What is it?
The Opportunity Solution Tree is a visual map that connects a single desired outcome to the customer opportunities (needs and pain points) that could move it, the solutions that could address those opportunities, and the experiments that test whether those solutions actually work.
What problem does it fix?
It fixes the leap teams make from "we have a goal to hit" straight to "let's build this feature." That leap produces three failures: falling in love with the first idea, shipping outputs that don't move the metric, and doing scattered, ad-hoc discovery that doesn't ladder up to anything. The tree forces you to explore the problem space before you commit to a solution - and to choose between options rather than rubber-stamp one.
The one big idea
Make your thinking visible so you can compare options. Map the opportunity space before you pick a solution; test your assumptions before you commit.
Or in the framework's own language: outcomes over outputs, and "compare and contrast" beats "whether or not." A "whether-or-not" decision evaluates one idea in isolation; a "compare-and-contrast" decision weighs several - and consistently leads to better choices.
The structure
A tree has four layers, top to bottom:
Layer 1 - Outcome (the root). One measurable product outcome that ladders up to a business outcome. A product outcome is a change in customer behaviour you can influence (e.g., "more users create a playlist"), not a feature and not a far-off revenue number you can't move directly. One outcome per tree.
Layer 2 - Opportunities (the branches). Customer needs, pains, and desires, phrased from the customer's point of view and kept solution-free. Organise them into a hierarchy, broad to specific.
Layer 3 - Solutions (the twigs). Several candidate ways to address one chosen opportunity. Diverge here; don't grab the first idea.
Layer 4 - Experiments (the leaves). Small assumption tests that check the riskiest beliefs behind a solution before you build it. Cheap, fast, and aimed squarely at the belief that, if wrong, sinks the idea.
The steps - how to build and use it
- Set one clear outcome - a product outcome tied to a business outcome.
- Interview customers continuously - capture their needs, pains, and desires on a regular cadence (weekly is the ideal).
- Map them as opportunities - structure them into a hierarchy, kept strictly solution-free.
- Assess the opportunity space - pick the target opportunity that best moves the outcome (consider sizing, frequency, and fit).
- Ideate several solutions for that opportunity - diverge before you converge.
- Compare and shortlist the solutions.
- Surface the riskiest assumptions behind the shortlist and run small assumption tests.
- Feed learnings back in - the tree is a living artefact, not a one-off deck.
What you get out of it
- A visible line from everyday discovery to a measurable outcome.
- A structured opportunity space, so you solve the right problem before solutioning.
- Better decisions (compare-and-contrast) and far less risk of betting the roadmap on one untested idea.
- Alignment for the product trio (PM, designer, engineer) and stakeholders.
- A living artefact that grows with your discovery.
When to use it - and when not to
Use it when:
- You run ongoing discovery.
- Your team is measured on outcomes.
- You have regular access to customers.
- You're deciding what to build to move a metric.
Don't lean on it when:
- You're in a feature-factory with a fixed mandate and no discovery latitude (the outcome layer becomes fiction).
- You're deep in a pure delivery phase.
Note: it organises decisions - it doesn't make them or score them for you. You still bring judgment, and can layer a scoring method (RICE, opportunity scoring) on top.
Common mistakes
- Solutions hiding in the opportunity space. Opportunities must be customer needs, not features in disguise.
- More than one outcome per tree - it dilutes focus.
- A vague or unmeasurable outcome, or a business outcome you can't directly influence. Use a product outcome.
- Jumping to solutions before structuring the opportunities.
- Treating the tree as a static slide instead of something fed by weekly interviews.
- Skipping assumption tests and building straight away.
Its limits, honestly: it only works with real customer access and a genuine discovery cadence; large trees can sprawl and need pruning; and output quality is only as good as your interviews.
How it fits with other frameworks
- Jobs To Be Done - jobs and unmet needs populate the opportunity space.
- Continuous Discovery Habits - the OST is the centrepiece of this method (product trio + weekly customer touchpoints).
- Dual-Track Agile - the tree organises the discovery track that feeds delivery.
- Design Thinking / Double Diamond - diverge/converge, first on opportunities, then on solutions.
- Assumption Testing / Lean Startup - supplies the experiment layer.
- OKRs / North Star - the outcome at the root ladders down from these.
A full example - a music app
Outcome (root): Increase the share of new users who create or save a playlist in their first week (a leading indicator of retention).
Opportunity (target): "I don't know what to play when I open the app."
- Solution: Auto-generated starter playlist. → Experiment: a fake-door test measuring tap-through and save rate before building it.
- Solution: One-tap "mood" picker on open. → Experiment: a clickable prototype tested in five interviews.
- Solution: Editorial "Made for You" shelf.
- Solution: Import playlists from another app.
Other opportunities: "Building a playlist feels like effort." · "I can't find a song I only half-remember."
The team picked one opportunity, generated four solutions instead of one, then named the riskiest assumption - "new users will engage with a playlist we made for them" - and tested it cheaply before committing engineering time.
Illustrative outcomes
Good product outcomes (the root of a tree) for products you know - shown to illustrate the outcome concept, not these companies' actual internal trees:
- Netflix - More new members watch a second title within their first week.
- Duolingo - More new learners return to complete a lesson on day two.
- Spotify - More free users create their first playlist in week one.
- Slack - More new workspaces cross the activation threshold (Slack publicly tied long-term retention to teams exchanging ~2,000 messages).
- Airbnb (host side) - More new hosts publish a complete listing within a week of signing up.
- A budgeting app - More users connect a bank account within 24 hours of sign-up.
Notice each is a measurable change in behaviour the team can influence - never a feature.
What to read next
- Continuous Discovery Habits - Teresa Torres (2021). The primary source.
- Product Talk (producttalk.org) - Teresa Torres. Torres' blog, where the tree originated.
- Inspired and Empowered - Marty Cagan. Outcome-driven, empowered teams.
- Testing Business Ideas - Bland & Osterwalder. The assumption-testing layer in depth.
- The Lean Startup - Eric Ries. Experiments and validated learning.
Who made it?
The Opportunity Solution Tree was created by Teresa Torres, a product discovery coach. She first shared it on her Product Talk blog (around 2016) and detailed it in her 2021 book Continuous Discovery Habits.
It pulls together several older ideas: design thinking (diverge then converge), needs-based thinking like Jobs To Be Done, dual-track agile, assumption testing (Lean Startup; Bland & Osterwalder), and the outcomes-over-outputs philosophy associated with Marty Cagan and OKRs.