Opportunity Solution Tree
Visualize the path between a business objective and solutions to test. Teresa Torres' tool for structuring continuous product discovery.
Description
The Opportunity Solution Tree (OST) is a visual tool for structuring product discovery created by Teresa Torres in 2016, which connects a measurable business objective to customer opportunities, potential solutions, and experiments to run. Its purpose: to give product teams a clear navigation map between strategy and day-to-day discovery decisions. Teresa Torres first presented the OST on ProductTalk.org, then formalized it in Continuous Discovery Habits (2021): "The Opportunity Solution Tree helps teams connect what they're learning from customers to what they should build next." The tree reads from top to bottom. At the top, a measurable outcome the team commits to achieving ("Increase M3 retention from 40% to 55%"). At the next level, opportunities: the needs, frustrations, or desires of customers that the team has identified through interviews. Then solutions: the concrete ideas to address each opportunity. Finally, experiments: the quick tests to validate each solution before investing. The OST works like an inverted family tree: each branch (solution) traces back to an ancestor (opportunity) that itself traces back to a root (outcome). If you cannot draw that link, the solution is orphaned and does not deserve your sprint. This structure solves a frequent problem in product management: teams jump directly from the business objective to the solution without exploring the opportunity space. Unlike Impact Mapping (which stays at the level of actors and business impacts), the OST goes down to concrete user problems. Unlike Story Mapping (which organizes delivery), the OST structures upstream discovery.
Objectives
- Explore opportunities
- Foster innovation
- Ensure strategic alignment
Used by
- -Amplitude (uses the Opportunity Solution Tree to structure discovery for its product teams, documented in the North Star Playbook)
- -Zapier (applies the OST in its product teams to connect business objectives to discovery experiments)
Advantages
- Makes the link between strategy and daily work visible. Each experiment can be traced back to the business outcome, eliminating the "why are we doing this again?".
- Forces exploration before decision. By requiring multiple solutions per opportunity, the OST prevents the reflex of jumping on the first idea.
- Structure adapted to the continuous discovery rhythm. The tree evolves each week, not each quarter, making it a living tool rather than a planning document.
- Common language for the product trio. PM, designer and tech lead share the same tree, aligning perspectives without additional meetings.
Limitations
- Requires regular customer interviews. Without a constant flow of customer insights (minimum 1 interview per week), the opportunity space remains theoretical and the tree freezes.
- Learning curve for properly formulating opportunities. The distinction between opportunity and solution is counter-intuitive for teams used to thinking in features.
- Can become visually complex. Beyond 3 opportunities with 5 solutions each, the tree becomes hard to read. Limit the visible scope to the current iteration.
- Does not replace a quantitative prioritization framework. The OST structures thinking but does not say which opportunity has the most impact. Combine with RICE or Opportunity Scoring to prioritize.
How to apply Opportunity Solution Tree
- 1
Define the measurable outcome at the top of the tree
Choose a business objective your team can directly influence. Formulate it as a measurable result, not as a deliverable. "Increase M3 retention from 40% to 55%" is an outcome. "Launch feature X" is an output. If you start with an output, you short-circuit the entire tree logic. Output: a single, measurable outcome validated by the product trio.
- 2
Map the opportunity space
Conduct weekly customer interviews (minimum 1 per week, ideally 2-3) to identify needs, frustrations, and desires related to your outcome. Group them into themes. Each theme is an opportunity. Do not confuse opportunity and solution: "I waste time configuring my account" is an opportunity; "Add a setup wizard" is a solution. Output: 5 to 15 opportunities classified by theme.
- 3
Prioritize the opportunities
Not all opportunities are equal. Evaluate each opportunity against three criteria: the size of the opportunity (how many customers are affected), the frequency of the problem, and the intensity of the pain. Focus on 1 to 3 opportunities at a time. Too many opportunities in parallel dilutes the discovery effort. Output: 1 to 3 priority opportunities selected.
- 4
Generate solutions for each priority opportunity
For each opportunity, brainstorm at least 3 different solutions. The temptation is to jump on the first idea. Resist. Three solutions minimum forces creativity and avoids confirmation bias. Involve the product trio (PM, designer, tech lead) to cover business, UX, and feasibility angles. Output: 3 to 5 solutions per opportunity.
- 5
Design experiments for each solution
Each solution must be tested before being built. An experiment is not a development sprint. It is a paper prototype, a smoke test, a Wizard of Oz, an A/B test on a landing page. The goal: reduce uncertainty at minimum cost. Define the success criterion before launching the test. Output: 1 to 2 experiments per solution with success criterion.
- 6
Draw the tree and make it visible
Use a visual tool (Miro, FigJam, whiteboard) to draw the complete tree: outcome at the top, opportunities below, solutions under each opportunity, experiments under each solution. The tree must be accessible to the whole team and updated continuously. Output: shared and up-to-date visual tree.
- 7
Iterate every week with experiment results
After each experiment, update the tree. An experiment that invalidates a solution is not a failure, it is information. Cross out the solution, test the next one. An experiment that validates a solution deserves greater investment (functional prototype, MVP). The tree evolves every week, not every quarter. Output: tree updated with the week's learnings.
- 8
Trace back to the outcome to verify alignment
Regularly (every 2 to 4 weeks), step back and verify that your validated solutions actually contribute to the outcome. If your M3 retention is not moving despite successful experiments, perhaps the opportunity was poorly identified or the solution does not solve the right problem. Adjust the tree accordingly. Output: documented outcome-opportunities-solutions alignment review.