The discovery framework that keeps product teams from jumping to solutions before they understand the problem

The Opportunity Solution Tree (OST) was developed by Teresa Torres, a product discovery coach, and detailed in her 2021 book Continuous Discovery Habits. Torres built it in response to a failure mode she observed constantly in product teams: jumping from a stated outcome to a specific solution without systematically mapping the problem space in between.

The framework visualises the relationship between outcomes, opportunities, solutions, and experiments in a literal tree structure — giving teams a shared artifact that makes discovery work visible and challengeable rather than implicit and individual.

The tree has four levels:

• Outcome (root) — The business or product goal the team is working toward. Usually a metric: improve activation, reduce first-30-day churn, increase feature adoption.
• Opportunities (first branches) — Unmet needs, pain points, or desires discovered through customer research. These are customer problems, not solutions.
• Solutions (second branches) — Specific ideas for addressing an opportunity. Multiple solutions can branch from each opportunity.
• Experiments (leaves) — The smallest test that can validate or invalidate a solution assumption.

The key constraint: solutions only appear under the opportunity they address. This forces teams to stay connected to a real customer problem before committing to a solution direction — which sounds obvious but is surprisingly difficult to maintain in practice.

Without a structure like this, product discovery tends to collapse into a list of features or a backlog full of solutions with no clear lineage to a validated problem. The tree makes the gaps visible: if a proposed solution can't be placed under a clear customer opportunity, that's a signal the upstream work hasn't been done.

It also changes how teams handle disagreement. When someone wants to prioritise a feature, the conversation shifts from 'is this a good idea?' to 'which opportunity does this address, and how much evidence do we have for that opportunity?' That's a more useful argument.

Teams that use OST well tend to run Usability Testing and Contextual Inquiry not to validate solutions, but to discover and size opportunities before solutions exist. Research stops being a step in the design process and becomes a continuous input to prioritisation.

Treating it as a backlog tool. The OST is a discovery artifact — it lives in the messy, pre-roadmap phase of product work. Teams that try to manage execution through it usually end up frustrated.

Making it too tidy. A real OST should be a living, imperfect document. Opportunities get invalidated and pruned. Solutions move. Experiments reveal things that rewrite the opportunity layer. If your tree is always clean, it's probably not being updated honestly.

Skipping the outcome level. Some teams build OSTs that start at the opportunity level. Without a clear outcome anchoring the whole tree, you lose the mechanism that allows you to say no to any given opportunity — which is most of the framework's value.

Most teams maintain their OST in a whiteboard tool — Miro, FigJam, or similar. The tree gets reviewed in regular discovery rituals: weekly or bi-weekly sessions where new customer evidence is mapped in, invalidated branches get pruned, and the team agrees on which opportunities to explore next.

Torres recommends interviewing at least one customer per week as the heartbeat of a continuous discovery practice. The OST is where that interview evidence gets organised and connected to product decisions.

If your team struggles to connect UX Research outputs to actual product prioritisation, introducing an OST-based process is often one of the most direct ways to close that gap.