Opportunity-Solution Tree

Status: Documented, not shipped · Evidence: P · Family: Strategy and opportunity · Verdict: reject (2026-06-03)

What it is

The Opportunity-Solution Tree (OST) is a product-discovery map. You fix one desired business outcome at the root, branch underneath it into the customer opportunities (needs, pain points, and desires) that, if addressed, would move that outcome, then branch each opportunity into candidate solutions, and finally branch each solution into the experiments and assumption tests that would tell you whether it works. The artifact is a single visual tree, read top to bottom: outcome -> opportunities -> solutions -> experiments. Its claimed payoff is alignment and discipline - the whole team can see the same map, the outcome at the top keeps discovery scoped, and the opportunity layer in the middle forces teams to justify a solution by the customer need it serves instead of jumping straight from “let us build feature X” to shipping.

The honest description has to separate two things the popular write-ups blur. The first is a generic decomposition geometry: one root, a top-down split into labeled layers, recurse to testable leaves, prune. That geometry is an issue-tree, and the catalog already ships it. The second is the specific product-discovery semantics layered onto that geometry: the rule that the layers must be exactly outcome, then customer opportunity, then solution, then experiment; the rule that an opportunity is phrased from the user’s point of view as a need rather than a feature; the practice of generating several competing solutions per opportunity (“compare and contrast”); and the assumption-testing discipline (desirability, viability, feasibility, usability, and ethical assumptions) that hangs off the experiment layer. The tree shape is not what makes it OST. The fixed product-discovery layer semantics are. That distinction is decisive for both the grade and the verdict below.

When it helps / when it misleads

OST genuinely helps a product team when discovery has collapsed into a feature backlog: the team is debating which solutions to build with no shared statement of the outcome they serve or the customer opportunity underneath them, and the tree re-imposes the missing chain (this experiment tests this solution, which addresses this opportunity, which moves this outcome). It is a good corrective to solution-first thinking, it keeps a discovery effort scoped to one outcome, and it gives a cross-functional team one picture to argue over instead of a scattered set of docs.

It misleads or wastes effort when:

• The problem is not product discovery at all. OST presumes the objects are a business outcome, customer needs, and product solutions. Point it at a question with no customer and no product - an internal process choice, a research design, an ethical call, a personal decision - and the fixed layers manufacture a customer-and-feature frame that is not there. The tree’s structure is only an asset where its four layers actually map to the situation.
• The tree is treated as the analysis. Mapping opportunities is not the same as discovering them; a tidy tree built from internal assumptions, with no customer interviews underneath the opportunity layer, looks rigorous and predicts nothing. OST’s own author is explicit that the tree rides on continuous customer contact, but the visual is easy to fill in from a conference room.
• The opportunity layer is skipped or faked. The single move that distinguishes OST from a plain solution list is the insistence that every solution justify itself by a user-framed opportunity. When teams back-fill opportunities to rationalize a solution they had already chosen (the documented failure the “reverse the tree” practitioners warn about), the discipline is gone and what remains is an org chart of features.
• It is mistaken for a prioritization or decision method. OST lays out the option space and the assumption tests; it does not score, weight, or decide between opportunities or solutions. Teams routinely reach for a separate prioritization step (and the catalog’s decision skills) once the tree exists.

What the evidence says

The honest governing grade for OST’s stated move - “map an outcome down through opportunities to solutions to experiments” - is P (practitioner). It is a famous, well-specified, widely-taught product-management framework with a clear author and real adoption, and that is the full extent of what the record cleanly supports.

What the record does NOT support. I can locate no controlled or comparative study that tests the OST itself - “do teams that build an opportunity-solution tree make better product decisions, or ship better outcomes, than teams that do not?” - against any alternative. The literature is entirely practitioner: Teresa Torres’s own book and Product Talk essays, plus a large secondary ecosystem of product-blog explainers, tool vendors (Miro, Mural, Amplitude, ProductPlan), and bootcamp tutorials that assert and illustrate the method. None of it is an effectiveness study. The supporting claims that circulate - “teams stayed more aligned,” “we made faster decisions,” “we advocated for solutions that addressed real pain” - are practitioner testimonials and uncontrolled self-report, not measured effects against a baseline. There is no S- or M-tier research on this move to borrow from, so the grade is P on its own merits, with no optimistic half to cap.

No laundered statistics. There is no widely-quoted effect size attached to OST to begin with - no “OST raises success rates by N%” figure circulates the way the JTBD vendor statistic does - and none is asserted here. The method’s credibility in practice rests on its author’s reputation and the plausibility of the chain it enforces, not on a number. If a quantified OST-improves-outcomes claim is encountered in the wild, it should be treated as unsourced unless it names a primary author, year, and method; none with a traceable primary source was found, so none is reported.

The adjacent evidence is for a different, more general thing. The one defensible empirical anchor near OST is the literature on structured problem decomposition and coverage prompts generally - that forcing an exhaustive top-down breakdown reduces omission relative to free association. But that evidence (where it exists) grades the generic issue-tree / decomposition move, not OST’s specific outcome-opportunity-solution-experiment semantics, and attaching it to OST would be laundering the parent geometry’s plausibility onto the product-discovery packaging. OST inherits the issue-tree’s modest decomposition rationale and adds product-discovery layer rules that have no separate controlled support.

Transfer caveat (required). All of the supporting material describes human product teams in software-company settings. None of it studies an OST produced by or with an AI agent. The evidence is transferred from human commercial contexts and is not validated for AI-augmented use.

Why it is / is not a skill here

Verdict: Reject; status pm (the irreducible remainder belongs to the sibling pm-skills product). The registry reasoning is “Defer to pm-skills (product discovery),” and the route is concrete rather than a re-weighting.

The Build burden is to name one distinct, durable, general cognitive move that no shipped skill (or short chain) already produces, and to show its working mechanism shares less than about a fifth with every shipped skill. OST fails that burden because it decomposes cleanly into one general operation the catalog already ships and one remainder that is out of scope:

• The general operation is issue-tree. Strip the product vocabulary and the move is: fix a root, split it top-down into labeled layers, recurse to testable leaves, prune to what matters. That is mechanically think-issue-tree, which already owns “decompose a question into a MECE tree” and explicitly lets the user choose the split axis at each level. The shared machinery - one root, top-down labeled branches, recursion to leaves, prune - is far above the roughly 20% overlap ceiling. An OST is an issue-tree whose levels are pre-set to outcome, opportunity, solution, and experiment. A preset for an axis that issue-tree already asks the user to choose is a mode of an existing skill, not a new mechanism - exactly the reasoning that folded PEST(LE)‘s six-bucket preset and Fishbone’s 6M/8P preset into issue-tree.
• The irreducible remainder is product-discovery domain content, which the library defers to pm-skills. What is uniquely “OST” about OST is precisely the layer semantics: that the levels must be outcome / customer-opportunity / solution / experiment, that opportunities are user-framed needs, that you generate competing solutions per opportunity, and that you test desirability/viability/feasibility/usability/ethical assumptions. That is not a general thinking move; it is product-discovery method. The candidate sits in the strategy-and-opportunity family, whose registry header reads “weakest cross-domain fit; many defer to pm-skills,” and every product-discovery neighbour is already routed away: jobs-to-be-done (flag, pm-domain), value-proposition-contrast (pm), moat-defensibility-lens (pm), white-space-adjacent-possible (pm), porters-five-forces (flag), swot (excluded). OST is the same kind of object: a competitive-and-product-strategy method whose distinctive value is the domain semantics, not a separable cognitive operation.

Why pm / reject rather than fold or a clean build. A clean fold into issue-tree would over-claim: issue-tree carries the decomposition geometry but not the product-discovery layer rules or the assumption-testing discipline, so something real is left unaccounted - and that something is product-discovery domain knowledge, not a thinking move. That is exactly what pm is for: route the geometry to issue-tree (run with an outcome root and an opportunity-then-solution split axis) and route the discovery semantics to the sibling library, which ships a dedicated define-opportunity-tree skill that maps desired outcomes to opportunities and potential solutions - the OST as a product artifact. A build would ship a domain-specific product-discovery method into a general thinking library that has deliberately rejected every sibling of that kind, and would duplicate the sibling library’s coverage. So the honest service is to document the framework, attribute it, point the geometry to issue-tree, and point the method to pm-skills’ define-opportunity-tree. The learning value of the NO: a famous, genuinely useful framework can fail the bar not because the idea is weak but because its distinctive content is domain method (product discovery) sitting on top of a decomposition geometry the library already ships, and the right home for the domain method is the sibling product-management library, not a general thinking catalog.

Lineage and who to read

The Opportunity-Solution Tree is Teresa Torres’s, a product-discovery coach and the author of Continuous Discovery Habits. She introduced the tree around 2016 on her Product Talk blog and gave it its fullest treatment in the 2021 book, where the OST is the central visual that organizes her continuous-discovery method (the practice of keeping a product team in regular contact with customers and structuring discovery around outcomes rather than feature requests). Torres credits an intellectual debt to Bernard (Bernie) Roth, the Stanford mechanical-engineering professor and co-founder of the d.school, whose The Achievement Habit (2015) teaches reframing a stated solution back to the underlying need and then “divergent solutioning” - generating several different solutions for the same need. Torres’s contribution was to fix that need-to-solution reframing into a persistent, shared, four-layer visual graph (outcome, opportunity, solution, experiment) for product teams, and to pair it with assumption-testing.

“Opportunity Solution Tree” / “OST” is in broad generic use across the product-management community and is treated descriptively here, attributed to Torres; it is not a trademark the library must annotate, and the registry does not flag it as branded. The product-artifact version of the method lives in the sibling pm-skills library as define-opportunity-tree; the decomposition geometry it rides on lives in this library as think-issue-tree.

Named sources

• Teresa Torres, Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value (Product Talk LLC, 2021). The book-length statement of the method; the OST is its central visual. Practitioner / foundational; assertion-and-illustration, no controlled test. (P)
• Teresa Torres, “Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes,” Product Talk (producttalk.org). The canonical online explainer of the four layers (outcome, opportunity, solution, experiment) and the credit to Bernie Roth’s need-to-solution reframing. Practitioner. (P)
• Bernard Roth, The Achievement Habit: Stop Wishing, Start Doing, and Take Command of Your Life (HarperBusiness, 2015). The reframing and divergent-solutioning idea Torres cites as the OST’s intellectual root; a Stanford d.school design-thinking source, not an OST study. Practitioner / foundational (for the lineage). (P)
• Product School, “Opportunity Solution Trees for Enhanced Product Discovery” (productschool.com). Secondary teaching explainer; documents the structure and the Roth lineage. Practitioner reference. (P)
• “Reversing Teresa Torres’ Opportunity Solution Tree to find the why behind solutions,” Mind the Product (mindtheproduct.com). Practitioner essay naming the common failure mode - building the tree by back-filling opportunities under a solution already chosen. Cited for the misleads-when-faked caveat. (P, critical)

Excluded under the evidence rule: no quantified “OST improves outcomes by N%” figure with a traceable primary author and year was found, so none is reported or counted toward the grade. The practitioner testimonials of better alignment and faster decisions are uncontrolled self-report and are not treated as evidence of effect.