Opportunity Solution Tree

Origin & evolution

Teresa Torres introduced the Opportunity Solution Tree in Continuous Discovery Habits (2021), developed over the prior several years through her Product Talk blog and her coaching work with product teams. The tree topology has older relatives: design thinking uses problem trees, and management consulting has used issue trees for decades. Torres's contribution was to bind the topology to a continuous discovery practice, where the tree is never finished but is updated as the team learns, and to insist on the outcome at the root. Without an outcome, the tree has no anchor and solutions accumulate without discipline. Torres wrote the canonical reference page on producttalk.org, which covers the full mechanics and common failure modes.

How it works in practice

Start with one strategic outcome the team owns: a specific, measurable change in customer behaviour that the product is meant to drive. This becomes the root node of the tree.

Below the outcome, map opportunities. An opportunity is a customer need🫀NeedUserA user need, pain, desire, or constraintView reference →, pain, or desire that, if addressed, would move the outcome. Opportunities come from direct customer contact: interviews, observation👁️ObservationUser ResearchA specific behaviour or statement observedView reference →, recorded sessions. They are not invented at a whiteboard. A team building a file-management product might place "I lose time searching for the right version" and "I am not confident that my collaborators have the current file" as two distinct opportunities beneath an outcome of "users save at least 30 minutes per week with the product."

Below each prioritised opportunity, generate solutions. A solution is a specific product change, not a vague direction. Below each solution, design experiments: the smallest test that would reveal whether the solution actually addresses the opportunity.

A worked example. Outcome: "design teams complete at least three review cycles per week." Opportunity: "waiting for feedback blocks my next task☑️TaskProduct SpecificationA unit of work within a story or epicView reference →." Solution: async commenting with notification summaries. Experiment: build a lightweight prototype📱PrototypeExperience DesignAn interactive mockup for testingView reference → and test with five design teams to measure whether it reduces the average wait-for-review time.

The tree is updated after every experiment. Learning🧠LearningValidationAn insight gained from an experimentView reference → at the experiment level may change a solution, retire an opportunity, or surface a new one. The tree is a continuous artefact, not a one-time workshop output.

When to use it (and when not)

The Opportunity Solution Tree is the right tool when a team has an outcome it is responsible for and needs a structured way to connect discovery work to delivery. It is particularly valuable when the team has solutions in the backlog but no clear line of sight to customer needs, or when discovery and delivery are running as separate tracks with no continuous flow between them.

It is a harder fit when the team does not own a clear outcome. Without an outcome at the root, the tree becomes a feature list with extra steps. It is also demanding to maintain: a tree with fifty opportunities is unworkable in practice. The discipline is in pruning, not in capturing everything. Teams that mistake completeness for quality tend to stop updating the tree after the first workshop.

In the Unified Product Graph

Opportunity Solution Tree is a tree framework in the discovery category. It maps four distinct entity types across the levels of the tree.

• The Root Outcome slot holds an outcome🏆OutcomeStrategyA desired business or user outcomeView reference → entity: the specific customer behaviour change the team is pursuing.
• Opportunity slots hold opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → entities: customer needs and frictions surfaced through research.
• Solution slots hold solution🔧SolutionDiscoveryA proposed approach to address an opportunityView reference → entities: specific product changes proposed to address each opportunity.
• Experiment slots hold experiment_run▶️Experiment RunValidationAn execution instance of an experiment that records actual conditions, observations, and raw results.View reference → entities: the tests the team runs to validate each solution.

Modelling the OST this way in the Unified Product Graph means an opportunity🚪OpportunityDiscoveryA validated gap worth solvingView reference → node is not confined to the discovery view. The same node can appear in the research layer alongside the interview insights🔦InsightUser ResearchA synthesised finding from researchView reference → that surfaced it, and in the delivery layer alongside the feature it eventually informs. The chain from outcome to experiment is fully traversable, so a team can audit whether any shipped feature traces back to a validated opportunity.