Product Discovery

What is an Opportunity Solution Tree?

A visual framework for connecting what you want to achieve with how you plan to get there — without losing sight of the customer along the way.

Where it comes from

The Opportunity Solution Tree was created by Teresa Torres, a product discovery coach and author of Continuous Discovery Habits. She developed it to help product teams move away from output-focused planning — building a list of features someone asked for — toward outcome-focused discovery: understanding what customers actually need and why.

The framework has been widely adopted by product teams at companies of all sizes as a practical way to visualise and communicate product strategy without the overhead of heavyweight planning tools.

What an OST actually is

An Opportunity Solution Tree is a hierarchical diagram with four layers:

Outcome

The business or product goal you are trying to achieve

This is the root of the tree. It should be measurable and time-bound — not a feature, but a change in behaviour or metric. Example: Increase weekly active users by 20% in Q3.

Opportunity

Customer needs, pain points, or desires that — if addressed — would move the outcome

Opportunities come from anywhere you learn about customers: interviews, support tickets, usage data, surveys, and session recordings. They are not solutions. Example: Users don't know how to get started after signing up.

Opportunities can nest. A broad opportunity like "Users struggle to get started" can break into sub-opportunities: "Users don't know what to do first" and "Users feel overwhelmed by the options." In Ostly, you can attach an opportunity directly to another opportunity. The solution space only opens once you've identified a specific enough opportunity to address.

Solution

Ideas for how you might address an opportunity

Solutions are hypotheses, not commitments. Generate multiple solutions per opportunity before choosing one to test. Example: An interactive onboarding checklist.

Assumption Test

The smallest test you can run to validate or invalidate a specific assumption underlying a solution

Assumption tests reduce risk before investing in full builds. Unlike a full experiment on a solution, each test targets one underlying assumption. Example: Show a static mockup of the checklist to 5 users and measure whether they would use it.

Why it works

Most product teams struggle with the gap between strategy and execution. A roadmap tells you what to build. An OST tells you why — and keeps that reasoning visible as you work.

The tree structure forces a discipline that flat lists and spreadsheets don't: every solution must trace back to a customer opportunity, and every opportunity must trace back to the outcome you're pursuing. If a feature idea doesn't have a clear place in the tree, that's a signal it shouldn't be built.

It also makes tradeoffs visible. When stakeholders ask why you "aren't building X", you can show them the tree: X doesn't address any of the opportunities linked to our current outcome. That's a much clearer answer than "it's not on the roadmap."

The OST is a living discovery artifact

Torres's approach is weekly customer interviews that continuously surface new opportunities. The tree should change as you learn — opportunities get added, solutions get parked, assumption tests inform the next round of interviews. If your tree hasn't changed in a month, you probably haven't been doing discovery.

Common mistakes

  • Putting solutions at the opportunity level. "Build a dashboard" is not an opportunity — it's a solution. Opportunities describe customer problems, not your answers to them.

  • Only having one solution per opportunity. The point is to explore multiple approaches before committing. Generate at least three solutions per opportunity.

  • Skipping assumption tests. Moving straight from solution to build is the most expensive way to be wrong. Assumption tests exist to fail fast and cheaply.

  • Treating it as a one-time exercise. An OST is a living document. As you learn from experiments and interviews, the tree should change.

  • Having more than one outcome. One tree, one outcome. If your team is pursuing multiple outcomes simultaneously, build separate trees.

How to get started

  1. 1

    Define your outcome. Pick a single, measurable goal your team owns for the next quarter.

  2. 2

    Do discovery. Talk to customers, dig into your data, review support tickets. Look for unmet needs and recurring frustrations — these become your opportunities.

  3. 3

    Build out the opportunity space. Map the opportunities you've discovered. Look for clusters and sub-opportunities. Don't jump to solutions yet.

  4. 4

    Choose your target opportunity. Which opportunity, if addressed, would most move your outcome? Start there.

  5. 5

    Generate solutions. Brainstorm multiple solutions for your target opportunity. Involve engineers and designers.

  6. 6

    Design assumption tests. For each candidate solution, identify its riskiest assumption and define the cheapest test you could run to learn whether it holds.

Ready to build your first OST?

Ostly is built specifically for Opportunity Solution Trees. No clutter, no complexity — just the framework, done simply.

Start free — 14 days, no card required