Opportunity Solution Tree

Build an Opportunity Solution Tree from outcomes to opportunities, solutions, and tests. Use when a stakeholder request needs problem framing

Category: design Source: deanpeters/Product-Manager-Skills

What Is This?

The Opportunity Solution Tree (OST) is a structured visual framework used by product managers to connect a desired business outcome to the opportunities, solutions, and experiments needed to achieve it. Originally developed by Teresa Torres, the tree helps teams avoid jumping straight to building features before they have properly understood the underlying problem space.

In practice, the OST is a hierarchical diagram. At the root sits a single outcome, the measurable result you want to achieve. Below that, you map out opportunities, which are customer needs, pain points, or desires that, if addressed, would move you toward that outcome. Under each opportunity, you list potential solutions. And beneath each solution, you define the assumption tests or experiments that would validate whether the solution is worth building.

This skill guides product managers through the process of constructing that tree, starting from a stakeholder request and working downward through each layer before any decisions about what to build are made.

Why Use It?

Most product teams receive requests in the form of solutions. A stakeholder says "we need a dashboard" or "can we add a notification feature?" The instinct is to start designing or writing tickets immediately. This is where teams go wrong.

When you skip problem framing, you risk building the right thing for the wrong reason, or worse, the wrong thing entirely. The Opportunity Solution Tree forces a pause. It asks you to work backward from the desired outcome and forward from real customer evidence before committing to any solution.

The framework also helps teams manage multiple ideas at once without losing focus. Because the tree is visual and hierarchical, you can hold several potential solutions in view simultaneously and compare them against the same opportunity. This makes prioritization conversations more grounded and less political.

Finally, the OST creates a shared language between product, design, and engineering. When everyone can see the same tree, alignment becomes easier and debates about what to build become debates about evidence rather than opinion.

How to Use It?

Start by identifying the outcome. This should be a specific, measurable result tied to a business or product goal. For example: "Increase trial-to-paid conversion rate by 15% in Q3."

Next, conduct or review customer research to surface opportunities. An opportunity is not a feature request. It is a customer need or friction point. For example: "Users do not understand the value of the paid tier during their trial period."

Once you have a set of opportunities, map them as branches beneath the outcome. Then, for each opportunity, brainstorm solutions. A solution is a concrete product change or intervention. For example: "Add an in-app comparison screen showing free vs. paid features."

Finally, beneath each solution, define the smallest experiment that would test your riskiest assumption. This is your assumption test. For example: "Show a static mockup of the comparison screen to 10 trial users and measure whether they can articulate the value difference."

A simple text representation of the structure looks like this:

Outcome: Increase trial-to-paid conversion by 15%
  Opportunity: Users don't understand paid tier value
    Solution: In-app feature comparison screen
      Test: Usability test with static mockup (n=10)
    Solution: Personalized upgrade prompt based on usage
      Test: A/B test prompt copy with 5% of trial users
  Opportunity: Onboarding flow doesn't highlight key features
    Solution: Redesign day-3 onboarding email
      Test: Send revised email to 20% of new trials, measure click-through

Work through this structure iteratively. The tree is not a one-time artifact. It should be updated as you learn from experiments and gather new customer evidence.

When to Use It?

Use the Opportunity Solution Tree when a stakeholder brings you a feature request and you need to reframe it as a problem before deciding what to build. It is also useful at the start of a new product initiative, when kicking off a discovery cycle, or when your team is debating between multiple competing ideas without a clear framework for comparison.

It is less useful when you already have strong validated evidence pointing to a specific solution, or when you are in execution mode and the discovery work is complete.

Important Notes

The outcome at the root of your tree must be something your team can actually influence. Avoid vanity metrics or outcomes that depend entirely on factors outside your control.

Opportunities must come from customer evidence, not internal assumptions. If you cannot point to a customer interview, support ticket, or behavioral data point to support an opportunity, treat it as a hypothesis that still needs validation.

Keep the tree visible and accessible to the whole team. A tree that lives only in one person's head or document provides none of the alignment benefits the framework is designed to create.