Opportunity Solution Tree

What is an Opportunity Solution Tree?

The Opportunity Solution Tree (OST) is a visual decision-making framework that connects organizational outcomes to specific customer opportunities and corresponding solutions. Developed by Teresa Torres, it inverts the typical product roadmap from solution-first to opportunity-first. The tree structure flows: desired outcome at the root, customer opportunities as branches, and solution experiments as leaves, creating a shared language between discovery teams and stakeholders.

The framework forces explicit trade-offs early. Rather than debating which feature to build, teams debate which customer problem is worth solving first. This distinction matters because it shifts conversations from technical feasibility to business value. The OST creates a permanent record of what was learned, not just what was shipped.

Core Structure: Outcome → Opportunity → Solution

The root of the tree is your outcome—the business goal or strategic result you’re pursuing. This might be “increase user retention by 25%” or “expand market share in enterprise accounts.” From that outcome branch multiple customer opportunities, which are specific problems or desires your customers face that relate to your outcome.

Each opportunity then branches into multiple potential solutions—different ways you might address that opportunity. Some solutions will be full features; others might be small experiments or changes to existing workflows. The visual structure prevents solutions from being siloed; instead, all team members see how each potential solution relates back to the specific opportunity and the ultimate business outcome.

Why Teams Often Skip This

Product teams often jump directly to solutions because it feels efficient. A stakeholder says “we need dark mode” or “we need mobile support,” and engineering starts building. The OST forces a moment of friction: before you build, you must articulate which customer opportunity this solution actually addresses. This friction is deliberate. It surfaces disagreement early, when changing direction is still possible.

Discovery vs. Delivery Structure

The top half of the tree (outcome and opportunities) is discovery territory. This is where you spend 70% of your research effort—understanding what customers actually need and which opportunities are worth pursuing. The bottom half (solutions and experiments) is delivery territory, where you test hypotheses and measure results.

Many teams collapse these layers. They treat the OST as a simple feature list with a different shape. In practice, a well-maintained tree has dozens of customer opportunities under each outcome, but only a few solutions being actively tested at any time. The unselected opportunities represent optionality, not neglect.

Continuous Learning, Not Static Planning

The OST is not a roadmap artifact to be updated quarterly. It’s a living decision log. Each experiment you run teaches you whether a solution addressed the right opportunity or whether the opportunity itself was misunderstood. When an experiment fails, you update the tree—marking that solution as disproven, not moving to the next feature.

This practice converts failed experiments into institutional knowledge. You can point to the tree and show leadership: “We tested three solutions for that opportunity, and here’s what we learned from each failure. That’s why we’re now pursuing this different opportunity.”

Why It Matters for Product People

For enterprise leaders and transformation officers, the OST is valuable because it makes product strategy legible. Instead of abstract roadmap arguments, you can see the logic: “We’re pursuing this outcome because of our Q2 strategic goal. We identified this opportunity because our customer research in vertical X showed this problem. We’re testing this solution first because it’s the smallest bet that validates the opportunity.”

It also creates a forcing function for data literacy. Every branch of the tree should eventually connect to customer evidence or business metrics. If an opportunity lacks evidence, it stands out visually.

The framework also constrains scope naturally. When you have 30 opportunities but can only test 3 solutions per quarter, the prioritization becomes explicit and defensible.

Related Concepts

The OST works well alongside Jobs to Be Done research (which helps articulate opportunities) and Hypothesis Testing frameworks (which govern how you validate solutions). It’s also compatible with OKRs, where the tree’s outcome maps to your strategic goal, and key results measure whether your experiments are moving the needle on that outcome.