Opportunity solution tree: the PM's structured approach to product discovery

The opportunity solution tree is not a template you fill in once. It is a living map of your evidence about what customers need and which solutions are worth building. Teresa Torres introduced it in 2016 and codified it in Continuous Discovery Habits (2021). Most teams who “use the OST” have drawn the tree but are not running it. That distinction is what a strong interviewer is checking.

The four layers (exactly four, no substitutes)

The tree has four layers. Getting these right matters in an interview because conflating any two is the most common tell of surface-level familiarity.

Outcome (root). A business metric the team owns and can move. Not “improve the product.” Something like “increase 30-day retention from 42% to 52%.” One outcome anchors the whole tree. When the outcome changes, the tree resets.
Opportunity space. Customer needs, pains, and desires, each stated in the customer’s own words. An opportunity is not a solution in disguise. “Users need a faster checkout” is a solution. “I abandon my cart when I can’t remember my payment details at the last step” is an opportunity. The distinction is the entire point.
Solutions. Your team’s responses to a target opportunity. You generate multiple solutions per opportunity before selecting one. Compare-and-contrast is how you make a better decision; picking the first solution that sounds reasonable is how you ship the wrong thing.
Assumption tests. The fourth layer, not experiments in the generic sense. You name the specific assumption your solution rests on, then design the cheapest test that could falsify it. “We assume users will trust an auto-saved payment method” is an assumption. An A/B test of the full checkout flow is not an assumption test; it conflates too many variables.

Drawing the tree vs. running the tree

Most pages on the OST describe what it looks like. The gap is how you operate it.

Torres recommends story-based customer interviews as the engine. Story-based means you ask customers to walk you through a specific recent experience, not to rate features or describe preferences. You conduct roughly three to four interviews before updating the opportunity space. Each cluster either surfaces new opportunities, reinforces existing ones, or lets you close a branch as resolved.

The operating rhythm that separates high-velocity teams:

After each interview cluster: review what you heard, update opportunity nodes, note new language verbatim.
Regularly: re-rank the opportunity space and confirm which branch your team is actively betting on.
As evidence accumulates: prune solved branches and opportunities that have collapsed under scrutiny.
When the outcome shifts: revisit the root. If the business metric has changed, rebuild from there.

A 2026 survey of 300 product teams found that continuous customer contact and explicit opportunity mapping, not better roadmapping tools, were the practices that most separated high-velocity from average teams.

Torres is explicit that the full product trio (PM, designer, engineer) co-owns the tree. A PM who runs discovery alone and briefs the team afterward is not using the OST. They are gatekeeping insight.

A worked example: B2B contract management tool

A team owns this outcome: reduce contract signature time from seven days to three days, which has a direct effect on revenue close rates.

They run five story-based interviews with sales ops leads and legal reviewers. The raw customer language surfaces these opportunities:

“I have to chase three different people just to find out where the contract is stuck.”
“Legal redlines the same clauses every single time. I don’t know why we keep sending the same starting version.”
“I never know if the counterparty has actually opened the document.”

Three distinct opportunity nodes, each in customer words. The team now picks one branch. Using Torres’s compare-and-contrast approach: which opportunity, if addressed, would most directly move signature time? They rank “chasing people to find the bottleneck” as highest because it affects every deal regardless of complexity.

Against that target opportunity, they generate four candidate solutions before evaluating any: a Slack-integrated status summary, an automatic daily digest email, a dashboard visible to all deal stakeholders, and an in-app milestone notification triggered by document events.

Then they name assumptions. The digest email solution rests on this: “Sales ops leads check email during the workday and act on status summaries.” That is falsifiable. A one-week prototype test with five users who agree to share open rates and follow-up actions is an assumption test. It is not a full feature rollout.

What an interviewer is actually checking

When a PM interviewer asks “walk me through your discovery process,” they are checking three things:

Do you separate opportunities from solutions? Candidates who conflate these are managing a feature backlog, not doing discovery.
Is your evidence current? Evidence starvation is the dominant failure mode in 2026. Most teams refresh customer data quarterly at best, leaving the tree 90 days stale while executing on conclusions that may no longer hold.
Do you run the full product trio? The PM, designer, and engineer co-own the tree. A PM who runs discovery solo is not using the OST.

strong

"My team runs story-based interviews in clusters of three or four. We update the opportunity space after each cluster using the customer's actual words, not paraphrases. I treat opportunities strictly: if it sounds like a solution in disguise, I rewrite it. Once we've confirmed a target opportunity with enough evidence to make a bet, we generate multiple solutions before we pick one. We use compare-and-contrast to choose, not the loudest opinion in the room. Before we build anything, we write down the single assumption the solution depends on and design the smallest test that could break it. My designer and engineers are in the interviews, not briefed afterward."

weak

"We use the opportunity solution tree to map out customer needs before deciding what to build. I organize it into opportunities, solutions, and experiments. We do user research quarterly and then prioritize using the output." This conflates weekly operation with quarterly batch research, skips assumption tests as a named discipline, and treats the PM as the sole owner of discovery. Interviewers at companies with mature discovery cultures will probe immediately.

The 2026 reframe: OST as a viability filter

In an environment where feasibility is effectively free, the opportunity layer of the OST becomes the most important work a PM does. If almost any solution can be shipped at low cost, the question is no longer “can we build this?” The question is whether this is a problem people will actually pay to have solved, at a market size that covers the cost of labor and generates a return. That is the viability test, and it lives in the opportunity layer.

AI-moderated continuous interviews (Perspective AI, Sprig, User Interviews AI features) now run hundreds of simultaneous conversations and return synthesized themes in days rather than weeks. This collapses the 90-day evidence staleness problem that Torres identified as the biggest barrier to actual continuous discovery. Teams with these tools have no excuse for stale opportunity spaces. The cadence shrinks from quarterly to weekly without adding headcount.

Torres published a 2025 post warning that AI-generated opportunity trees populated from model assumptions rather than real interviews reproduce the exact failure mode the OST was designed to prevent. The tree must be grounded in customer language. AI can accelerate synthesis; it cannot replace the source material.

The lovable dimension lives in solution selection and assumption testing: which of your candidate solutions actually meets people where they work, anticipates the moment of friction, and earns the behavior you need? That is not a prioritization formula. It is what the weekly cadence is designed to surface.

Common failure modes to self-audit

Solution-shaped opportunities. “Users need a checklist” is a solution. Rewrite in the customer’s words until it is a need.
PM-only tree. If your designer and engineer do not know what the current target opportunity is, you are maintaining a diagram, not running a discovery system.
Stale evidence. If your most recent interview data is more than four weeks old, your opportunity space is inference, not discovery.
Skipping assumption tests. Shipping a full feature to test a risky assumption is the most expensive form of discovery.
One solution per opportunity. Compare-and-contrast between candidates is not optional. Single-solution trees produce first-idea bias.

Where OST fits relative to adjacent frameworks

JTBD and OST are complementary, not competing. JTBD gives you the language for writing strong opportunity nodes: the need the customer is trying to address, in their own words, anchored to a situation. Use JTBD to write the nodes; use the OST to organize, rank, and act on them.

The North Star metric defines the root outcome. You cannot run an OST without one. The North Star tells you whether an opportunity is in bounds; the OST tells you which in-bounds opportunity to bet on.

RICE scores solutions. The OST structures the evidence that should inform those scores. Teams that RICE without an opportunity layer are scoring solutions to problems they have not confirmed are real.

Use it, do not recite it

The failure mode is naming the OST and then listing features. “I identified opportunities and mapped solutions to them” tells an interviewer nothing. What they need to hear: that you wrote opportunities in customer language, generated multiple solutions before choosing, named an assumption and tested it before building, and had your team in the room during research.

The OST is not a discovery convenience. It is the mechanism for proving, before you commit engineering, that you are solving a problem the market will pay to have solved.