Introduction
Two feature ideas are competing for one quarter of engineering time, and nobody in the room can say which customer need either one serves. That's the situation an Opportunity Solution Tree (OST) is built for: a visual product discovery framework that connects a desired outcome to customer opportunities, possible solutions, and the experiments needed to test them.
This guide is for product managers, product leaders, designers, engineers, and the cross-functional teams around them, especially at growing B2B SaaS companies. The tree is most useful when discovery evidence and product decisions are scattered across tools, tickets, and half-remembered customer calls.
The tree asks a team to show which customer need a feature idea serves and what evidence points to that need, so a bet is harder to pick on gut feeling or because the loudest stakeholder wants it. Below, we'll cover the tree's structure, how to build one, where it fits in a product organization, and the mistakes that turn a useful discovery tool into shelfware.
Key Takeaways
- An OST maps the relationship between an outcome, customer opportunities, solution ideas, and assumption tests.
- The framework ties discovery to one measurable outcome, so the team judges its work by whether that number moves.
- Opportunities need customer evidence behind them and must stay separate from solutions.
- A useful tree is a living decision map that the team updates as each new piece of evidence arrives.
- In multi-team organizations, every tree needs a clear scope, owner, and outcome.
What Is an Opportunity Solution Tree?
An Opportunity Solution Tree is a visual map showing the possible paths a product team can take toward a desired outcome. Each branch represents a customer need, a solution idea meant to address it, or an experiment designed to test whether that solution actually works. Product Talk defines the OST as a tool for making discovery decisions together.
The Four Core Components
Every tree is built from four layers:
- Outcome — the measurable product or business result the team is trying to move
- Opportunities — customer needs, pain points, or unmet desires that could influence that outcome
- Solutions — features, workflows, or process changes that might address an opportunity
- Assumption tests — low-cost experiments that check whether a solution is desirable, usable, feasible, or likely to move the outcome
Opportunity vs. Solution
These two are easy to mix up. "Customers struggle to compare options on our pricing page" is an opportunity. It describes a real friction point. "Add a comparison table" is one of several possible solutions to that opportunity.
A quick test: if there's more than one way to address something, you're looking at an opportunity. If there's only one way, you've written a solution and mislabeled it.
How an OST Differs From Other Product Artifacts
| Artifact | What it does |
|---|---|
| OKR | Sets a measurable organizational goal and key results |
| Roadmap | Communicates planned direction and commitments |
| Backlog | Stores and orders committed delivery work |
| OST | Maps discovery reasoning before a team commits to building anything |
The tree sits upstream of all three. It's where a team figures out what's worth building before it ever reaches a roadmap slot or a backlog ticket.
Teresa Torres introduced the opportunity solution tree as a named visual framework in 2016, then expanded on it in Continuous Discovery Habits. The tree supports continuous discovery—weekly contact with customers—so opportunity choices stay tied to evidence that keeps arriving week after week.
Why Opportunity Solution Trees Are Used in Product Discovery
Roadmap debates often start with "Which feature should we build next?" An OST reframes that into "Which customer opportunity would move our outcome, and what do we need to learn before picking a solution?" That shift moves the meeting toward evidence and away from a contest between feature ideas.
Shared context across teams. When product, design, engineering, sales, and customer success can see the same tree, arguments about priorities turn into discussions of the evidence on the map. That matters even more once a company has multiple product areas, where context otherwise lives in someone's head.
Business and customer value in balance. The outcome keeps discovery commercially relevant. The opportunity space keeps it grounded in what customers actually need. Neither one works well alone. An outcome without opportunities turns into guesswork; opportunities without an outcome turn into an endless wish list.
Visible prioritization. Competing opportunities, their supporting evidence, and the assumptions behind each solution all sit on one map. That stops the loudest feature request, or a single executive's favorite idea, from becoming the roadmap by default.
In Shorter Loop, each opportunity on the tree carries the feedback and claims linked to it, and the team scores each one by hand on spread, intensity and value (how many customers have the problem, how much it hurts them, and the revenue behind it) before anyone discusses a solution. RICE Score is available on solutions in Strategy Builder as one optional way to compare the options under an opportunity. The team still makes the call.
Skipping this step is common. McKinsey's research on design practices found that only around half of the companies it studied conducted user research before generating their first design ideas or specifications. The rest were writing specs before they had customer evidence to write them from.
OSTs also support continuous discovery: every experiment result feeds the next decision.
How an Opportunity Solution Tree Works
An opportunity solution tree moves in one continuous loop: set an outcome, map opportunities from evidence, pick one target, test solutions against risky assumptions, then feed what you learn back into the next decision.
The five steps below are a common working sequence:
Step 1: Define the Outcome
Pick one outcome the team can actually influence, specific enough to guide discovery without dictating a feature. Connect it to company strategy or OKRs, but avoid something as broad as total company revenue, where nearly any idea can be justified.
Step 2: Identify and Map Opportunities
Pull evidence from customer interviews, support conversations, sales calls, surveys, and behavioral analytics. Treat sales requests and support tickets as signals to investigate before anything from them goes onto the tree.
A pattern needs several customers behind it; one loud voice is a lead to follow up. Group related findings into branches, and expect the first draft to be messy—it gets refined as more evidence arrives.
Step 3: Select a Target Opportunity
Compare opportunities by customer importance, frequency, affected segments, and strength of evidence. Pick one to focus on. Designing solutions for every branch at once spreads a team too thin to learn anything well.
Step 4: Generate and Test Solutions
Invite product, design, engineering, and customer-facing teams to propose multiple ways to address the chosen opportunity—many options first, then narrow. Break the strongest candidates into assumptions, then test the riskiest one first:
- Prototype evaluation — watch users react to a candidate design
- Concierge test — deliver the service manually before any interface exists
- Fake-door test — show an unbuilt feature to gauge click interest
- Technical spike — have engineering check whether something is buildable
- Pricing conversation — ask what customers have actually paid for or done in the past
- Usability study or controlled experiment — run once something is actually built
Step 5: Learn and Update
Record what each test showed, what it didn't show, and the resulting decision: continue, revise, discard, or pivot to another opportunity. Connect that result back to the outcome and keep the evidence attached. That's what keeps a tree useful months later.
The loop is easier to see with an example. FlowDesk, a fictional demo dataset Shorter Loop uses to show the product, sets this outcome: cut first-90-day churn from 22% to 12%.
In the demo, support conversations, sales notes, and past churn interviews start out in three tools and are grouped into themes. The largest cluster is about dispatchers: the schedule lives in someone else's account, so the people who use it daily can't easily get to it.
Before building anything, the demo runs a two-week test of a share-schedule link, with a bar set in advance that at least half of new accounts would use it:
- 22 of 30 new accounts shared a schedule link
- 14 gained a second user without being prompted
That clears the bar, so in the demo the schedule-sharing solution moves forward. A competing idea, a done-for-you import service favored by leadership, stays parked: its main claim is still untested, with no test behind it.
Where Opportunity Solution Trees Are Applied and How to Keep Them Useful
OSTs show up across the product lifecycle: discovery, strategy conversations, quarterly planning, roadmap reviews, and solution testing right before or during delivery.
Scoping in Multi-Team Organizations
- Give each outcome its own tree, owned by the team accountable for that outcome
- When two trios keep hitting the same customer problem, hold one copy of that opportunity and link both trees to it, so the interviews behind it stay in one place and two teams do not test the same assumption twice
- Segment only when customer groups have different needs, or separate teams own separate outcomes
- Link opportunity and solution nodes to interview notes, analytics, experiment results, and delivery work so the reasoning doesn't disappear once the workshop ends
This is where trees tend to fall apart in growing organizations. With several product areas and a dozen tools, the link between a customer interview and the ticket it inspired is easy to lose.
In Shorter Loop the tree is part of the working record. The Tree view in Product Strategy shows objectives, opportunities and solutions in one hierarchy, and each item carries its own Evidence tab listing the claims in it and the feedback, documents, analytics and related work for and against them. Epics created from a solution sync two-way with Jira, Azure DevOps, GitHub, GitLab, or Asana, while delivery status stays in the delivery tool. A single trio running one tree has little to gain here: a whiteboard and a shared document will hold a single outcome well enough. The case for a tool starts when several trios keep trees at once and someone has to find the interview behind a branch six weeks later.
Maintenance Cadence
A reasonable cadence is to revisit the opportunity space every three or four customer interviews. For a team interviewing weekly, that's about every three to four weeks. Archive branches that go stale, and start a new tree when the outcome's direction changes. When only the target number moves, update the tree you have. You can build one from real feedback in a 14-day trial, no credit card required.
A Compact B2B SaaS Example
Say the outcome is improving onboarding activation. Evidence points to two opportunities: unclear setup requirements and difficulty reaching first value.
- One team tests a guided checklist against the first opportunity
- Another tests an in-app sample dataset against the second
Both compare against the same activation metric, so the team can see which bet is worth scaling without assuming either result in advance.
Common Issues and When an Opportunity Solution Tree May Not Be Appropriate
What an OST Is For
- Holding one outcome and the competing routes to it in a single view, so the choice between them is visible
- Keeping each opportunity attached to the research behind it, so anyone can check a polished tree against its sources
- Staying small enough that the outcome and the decision in front of the team remain legible; keep the detail in the items and the diagram uncluttered
Common Misuse to Watch For
- Starting with a preferred solution and reverse-engineering an opportunity to justify it
- Writing opportunities as disguised feature requests
- Choosing an outcome the team can't actually influence
- Treating one customer's request as representative of a whole segment
- Skipping assumption tests under delivery pressure, then rebuilding the tree later to make a rushed call look planned
When Something Else Fits Better
Use a lighter tool when the job is narrow and already decided:
- Decision tree — a simple yes/no call
- Process map — operational handoffs
- Backlog — delivery work already committed
- Incident-response plan — urgent defects
None of these need the discovery structure an OST provides.
Signs a tree needs to be simplified or reframed:
- Unclear ownership
- Unrelated outcomes crammed onto one tree
- Branches with zero evidence
- Experiments that can't actually move the outcome
- Stakeholders only use it to defend ideas they already decided to build
Conclusion
A quick diagnostic for an existing tree: pick the opportunity your team is currently working on and ask what the most recent piece of customer evidence behind it is, and when it arrived. If the answer is "the workshop where we drew the tree," the tree has stopped being a discovery tool.
If that's your answer, leave the rest of the tree as it is. Schedule two customer interviews against that one opportunity this week, add what they show to the branch, and decide at the next planning meeting whether the target opportunity still holds.
Frequently Asked Questions
What is an opportunity solution tree?
It's a visual map connecting a desired outcome to the customer opportunities, solution ideas, and experiments that could help a team reach it. The structure keeps each discovery choice tied to the evidence behind it.
Who invented the opportunity solution tree?
Teresa Torres introduced the framework as part of her continuous discovery approach, first describing the visual in 2016 and later expanding on it in her book, Continuous Discovery Habits.
How does an opportunity solution tree differ from a decision tree?
An OST maps customer opportunities, solutions, and experiments toward an outcome. A decision tree branches on choices and uncertain outcomes—for example, HBR's classic case of picking a small or large plant based on market size.
