Opportunity Solution Tree (OST) — A Product Discovery Skill from Stakeholder Needs to POC Selection

Skill Overview

The Opportunity Solution Tree (OST) skill guides product managers through product discovery in two interactive stages: extracting measurable desired outcomes from stakeholder requests, brainstorming three customer-problem opportunities and mapping three solutions to each opportunity, then scoring them across feasibility, impact, and product–market fit to select the best POC and design a corresponding validation experiment—ensuring that the team solves the right problem before building a solution.

Applicable Scenarios

1. A stakeholder has specified a particular feature, but you want to step back and examine the underlying problem — For example, sales says, “Our competitors have a mobile app, so we need one too.” This skill reframes the feature request as a customer problem, then determines which solution can truly drive the desired business outcome.
2. You need to explain the rationale behind solution trade-offs to leadership — When selecting one of three alternative solutions, the output includes a scoring table and recommendation rationale, explaining why it was chosen, when the alternatives should be initiated, and which option is not recommended for now.
3. You are beginning exploration in a new product area — When the goal is still vague, such as “increase conversion,” this skill starts from the desired outcome and quickly builds an opportunity map and solution tree as a starting point for exploration.

Core Capabilities

1. Extract the Desired Outcome — Distill a specific, measurable business or product metric from a vague stakeholder request, such as “increase the trial-to-paid conversion rate from 15% to 25%.” It provides four directions for quick selection: revenue growth, retention, acquisition, and efficiency, and confirms why the goal matters.
2. Generate an opportunity map and solution tree — Brainstorm three opportunities centered on the desired outcome. These must be customer problems rather than solutions disguised as problems. Then expand each opportunity into three hypothesis-based solutions, producing nine solution nodes in total. Throughout the process, follow a “diverge first, converge later” approach and explicitly avoid “feature factory” thinking that prioritizes solutions prematurely.
3. Select a POC and define the experiment — Score each solution on feasibility (1–5), impact (1–5), and product–market fit (1–5), then recommend the best starting point for validation along with alternative paths. For the selected POC, design a supporting experiment—an A/B test, prototype usability test, or concierge-style manual test—and produce a complete experiment plan including the hypothesis statement, target participants, duration, and success criteria.

Frequently Asked Questions

What is an Opportunity Solution Tree (OST)?

The OST is a visual framework introduced by Teresa Torres in Continuous Discovery Habits. It connects four layers into a tree: the desired outcome at the top, customer-problem opportunities in the middle, solutions below them, and validation experiments at the bottom. Its value lies in forcing the team to start from a business objective, explore problems before developing solutions, and require every solution to have a corresponding experiment—instead of building something simply because it “seems right.”

Can this skill still be used when a stakeholder has already specified the exact feature to build?

Yes—and this is one of its most typical use cases. The skill does not reject the stakeholder’s request; instead, it uses the request as a starting point and works backward: first asking, “What metric is this feature intended to influence?” Then it explores whether other opportunities and solutions could achieve the same goal more effectively. One important caveat: if the stakeholder strongly insists on a specific solution and is unwilling to discuss alternatives, the alignment issue should be addressed first; otherwise, discovery will not be meaningful.

What are the boundaries of this skill, and when is it not appropriate?

It is not a roadmap generator. Its output is a discovery plan with experiments, not a delivery schedule. It is not suitable in three situations: when the problem has already been validated, in which case you should move directly to solution testing; for purely technical debt or bug fixes, which do not require exploration; and when you need to strictly limit the scope to three opportunities × three solutions to prevent endless divergence. An OST is a living document that continuously evolves as you learn from experiments, not a one-time exercise.