Opportunity Solution Tree: The Complete Guide to Continuous Product Discovery

Bottom line: The Opportunity Solution Tree (OST) is a visual discovery framework created by product coach Teresa Torres that maps the path from a single desired business outcome through customer opportunities to concrete solutions and experiments. Teams that use the OST avoid building features nobody wants — because every solution traces back to a real customer need. This guide explains how to build one, fill it with real interview data, and use AI-powered tools like Koji to do it at scale.

What Is an Opportunity Solution Tree?

The Opportunity Solution Tree is a four-layer visual framework that helps product teams stay customer-centric during discovery:

1. Outcome — The single measurable business or customer result you are trying to improve
2. Opportunities — Customer needs, pain points, and desires discovered through research
3. Solutions — Specific features or approaches that might address an opportunity
4. Experiments — Tests to validate whether a solution actually works

Teresa Torres introduced the OST in her 2016 blog post on producttalk.org and formalized it in her 2021 book Continuous Discovery Habits. Since then, it has become one of the most widely adopted frameworks in product management — used by teams at companies ranging from early-stage startups to Fortune 500 enterprises.

The power of the OST is not in the visualization itself. It is in the discipline it creates: every solution you consider must connect to a real opportunity, and every opportunity must come from real customer evidence.

Why Most Product Teams Build the Wrong Things

The default mode of most product teams is a feature backlog: a ranked list of things to build. Backlogs are solution-space documents — they tell you what to build, but not why customers need it or whether anyone will use it after launch.

Research consistently shows this creates waste:

• A study by Pragmatic Institute found that 60% of product features are rarely or never used by the customers they were built for
• According to CB Insights analysis, 35% of startup failures cite "no market need" as the primary cause — meaning teams built solutions to problems customers do not have
• Teams using outcome-driven discovery frameworks are significantly more likely to ship features that drive measurable business results, according to research discussed in Continuous Discovery Habits

As Teresa Torres writes: "Most teams are not outcome-focused. They are output-focused. They ship features, and they hope for the best. The opportunity solution tree is the antidote — it keeps you tethered to outcomes and to the customer voice at every step."

The Four Layers of the Opportunity Solution Tree

Layer 1: The Outcome

The root of the tree is a single, measurable desired outcome — a change in the world you are trying to create, not a feature or a project milestone.

Good outcomes are:

• Measurable: "Increase weekly active users from 40% to 60%"
• Within the team's influence: a metric the team can directly affect
• Reflecting both customer and business value: a signal that customers are succeeding, not just a revenue number

Bad outcomes: "Launch feature X" (an output), "Grow the company" (too broad), "Improve NPS" (too indirect if the team has no clear lever on it).

One common mistake is selecting multiple outcomes. The OST requires a single outcome because focus is the entire point. With multiple outcomes, the opportunity space becomes too broad to navigate.

Layer 2: The Opportunity Space

Opportunities are the customer needs, pain points, and desires that, if addressed, would help you reach your outcome. They come from customer research — specifically, from interviews.

Teresa Torres distinguishes opportunities from solutions: an opportunity is something a customer already experiences ("I have to export data manually every week — it takes two hours"), while a solution is something you build to address it ("automated weekly exports").

The opportunity space is hierarchical. Large parent opportunities break into smaller, more specific child opportunities:

• Parent opportunity: Users struggle to get value quickly after signing up
  • Child: Users do not know which feature to try first
  • Child: The onboarding email arrives too late
  • Child: Setup requires technical knowledge they lack

Smaller, more specific opportunities lead to smaller, more targeted solutions — which are faster and cheaper to test.

Layer 3: The Solution Space

Solutions are hypotheses about how you might address a specific opportunity. For each opportunity you prioritize, generate multiple potential solutions — at least three. This prevents the team from anchoring on the first idea and forces creative thinking.

Each solution must trace back to a specific opportunity, which traces back to the desired outcome. If a solution cannot be connected to the tree, it should not be built.

Layer 4: Experiments

Experiments test the riskiest assumption behind each solution. Before committing engineering resources, you identify what must be true for the solution to work — and design the cheapest possible test to evaluate it.

Experiments might include:

• A fake-door test (a landing page for a feature that does not exist yet)
• A manual concierge test (doing the thing manually before automating it)
• A prototype walkthrough with 5 target users
• A short AI-moderated interview to validate whether the core assumption holds

The goal is to kill bad ideas fast and cheap, reserving development investment for solutions with validated evidence.

How to Build Your First Opportunity Solution Tree

Step 1: Agree on one outcome. Bring the product trio together and select the single outcome you are targeting this quarter. Tie it to an OKR or specific metric.

Step 2: Conduct customer interviews. Run 5–10 interviews with users relevant to your outcome. Listen for stories, struggles, and workarounds — these are your raw opportunities.

Step 3: Map the opportunity space. After each interview, capture opportunities you heard. Cluster them, identify parent-child relationships, and add them to your tree.

Step 4: Prioritize one opportunity. Which has the most customer evidence? Which is most aligned with your outcome? Which is most actionable given your team's capabilities?

Step 5: Generate multiple solutions. Brainstorm at least three solutions for the prioritized opportunity. Volume first — evaluate later.

Step 6: Identify the riskiest assumption. For each solution, ask: what must be true for this to work? Which assumption are you least confident about?

Step 7: Design and run experiments. Build the smallest possible test for your riskiest assumption. Validate, learn, iterate.

Step 8: Return to interviews. Continuous discovery means you never stop talking to customers. Weekly customer conversations keep your OST current and evidence-based.

How Customer Interviews Power the OST

The OST is only as good as the interview data feeding it. Without regular customer conversations, your opportunity space is based on assumptions — and your solutions will reflect that.

Teresa Torres recommends a minimum of one customer interview per week per product trio (PM + designer + engineer). This cadence ensures:

• Opportunities reflect current customer reality, not last quarter's research
• The opportunity space evolves as customer needs change
• Teams develop pattern recognition and intuition over time

The most valuable interview format for OST purposes is the experience interview: asking customers to walk you through a recent relevant experience ("Tell me about the last time you tried to accomplish X") rather than asking hypothetical questions. This surfaces concrete opportunities — real friction, real workarounds, real unmet needs.

How Koji Automates OST Evidence Collection

The biggest bottleneck in continuous discovery is not the OST itself — it is the interviews. Scheduling, running, transcribing, and synthesizing weekly customer conversations is a significant time commitment for busy product trios.

Koji changes this fundamentally.

Koji as your continuous discovery engine:

1. Set up a standing interview study — Create a Koji study with experience-interview questions designed to surface opportunities for your specific outcome (e.g., "Walk me through the last time you tried to accomplish [relevant task]...")
2. Send it to your customer panel — Koji's AI-moderated interviews run 24/7. Customers complete voice or text interviews at their convenience, with no scheduling required.
3. Let Koji surface the opportunities — After each interview, Koji generates individual insights and cross-interview themes automatically. These become your OST opportunities, pre-clustered and summarized.
4. Use structured questions for quantitative validation — Koji supports 6 structured question types: add scale questions to measure opportunity severity, yes/no questions to confirm problem prevalence, or ranking questions to prioritize between opportunities.
5. Refresh your report weekly — Koji's auto-generated reports synthesize findings across all interviews, keeping your OST evidence-based without manual synthesis work.

Teams using AI-assisted research tools report up to 60% faster time-to-insight compared to manual methods — meaning you can run a complete discovery cycle in the time it used to take just to schedule five interviews.

Common OST Mistakes and How to Avoid Them

Mistake 1: Filling the opportunity layer with solutions. If your opportunity reads "users need a dashboard," that is a solution. Reframe: "Users cannot see what is happening across their projects at a glance." Test: can a customer experience this problem without your product? If yes, it is an opportunity.

Mistake 2: Only interviewing one customer type. Your OST should reflect the range of customers who affect your outcome. If you only talk to power users, you will miss the problems blocking casual users from getting value.

Mistake 3: Treating the OST as a static document. Update it after every interview batch. Stale OSTs lead to solutions disconnected from current customer reality — the opposite of what the framework is designed to prevent.

Mistake 4: Pursuing too many opportunities simultaneously. Focus is the whole point. Pick one opportunity, validate it through experiments, ship a solution, then move to the next.

Mistake 5: Confusing experiments with features. An experiment tests one assumption — it does not ship a polished product. Build the minimum thing needed to learn, not the thing you would ship to customers.

OST vs. Traditional Product Roadmap

The OST does not replace your roadmap — it feeds it. Once you have validated solutions through experiments, they enter the roadmap with confidence that they will deliver the intended outcome.

Frequently Asked Questions

What is an Opportunity Solution Tree used for? The OST maps the path from a business outcome to validated solutions using customer opportunities discovered through research. It prevents product teams from jumping to solutions before deeply understanding customer needs.

Who created the Opportunity Solution Tree? Teresa Torres, a product discovery coach and author of Continuous Discovery Habits, created the Opportunity Solution Tree in 2016. It was formalized and widely popularized through her 2021 book.

How many opportunities should be in an OST? There is no fixed number. A typical OST might have 10–30 opportunities across multiple levels. You focus on one at a time for solution development — not all at once.

How often should I update my Opportunity Solution Tree? Teresa Torres recommends continuous discovery: at minimum, one customer interview per week per product trio. In practice, update the OST after every batch of interviews or at least monthly.

What is the difference between an opportunity and a solution in an OST? An opportunity is something a customer experiences (a need, pain, or desire). A solution is something you build to address it. If a customer can have the problem without your product, it is an opportunity. If it only exists because of something you build, it is a solution.

Can the Opportunity Solution Tree be used for B2B products? Yes — the OST is particularly powerful for B2B products with complex, multi-stakeholder customer needs. Be sure to interview both end users and economic buyers, as their opportunities often differ significantly.

Related Resources

• Structured Questions in AI Interviews
• Customer Discovery Interviews: The Complete Guide
• Continuous Discovery: How to Run Weekly Customer Interviews Without Burning Out
• Jobs to Be Done Framework: The Complete Guide
• How to Validate Product-Market Fit Through Qualitative Interviews
• Product Discovery Research: How to Validate Ideas Before Building