How to Build an Opportunity Solution Tree

Quick Answer (TL;DR)

An Opportunity Solution Tree (OST) is a visual map with four layers: a desired outcome at the top, opportunities (customer needs and pain points) in the middle, solutions (features and ideas) below those, and experiments (assumption tests) at the bottom. You build it iteratively by starting with one clear outcome, filling in opportunities from customer research, brainstorming multiple solutions per opportunity, and testing the riskiest assumptions before committing to build. The OST replaces gut-feel feature lists with an evidence-based approach to deciding what to build next. For the full theoretical foundation, see the Opportunity Solution Tree framework deep dive.

Why You Need an Opportunity Solution Tree

Product teams face the same structural challenge: too many possible features and no reliable way to choose between them. Stakeholders push their favorites. Customers request specific solutions. Competitors ship new things. The backlog grows. Prioritization becomes a political negotiation rather than an evidence-based decision.

The OST solves this by making the logic behind every feature visible. Each solution traces up through an opportunity to a measurable outcome. If a proposed feature does not connect to a real customer opportunity that serves your target outcome, it does not belong on the tree. This clarity makes prioritization significantly simpler: you are not comparing unrelated features against each other but evaluating which opportunities have the strongest evidence and which solutions best address them.

Teresa Torres developed the OST as the centerpiece of her continuous discovery habits methodology. It is designed for product trios (PM, designer, tech lead) to maintain and update weekly, keeping the team aligned on what they know, what they do not know, and what they need to learn.

The Four Layers of an OST

Layer 1: The Desired Outcome

The top of the tree is a single, measurable outcome your team is pursuing. Not a feature. Not a project. An outcome.

Good outcomes:

• Increase trial-to-paid conversion from 8% to 12% this quarter
• Reduce time-to-first-value from 45 minutes to under 10 minutes
• Increase weekly active usage from 3 to 5 sessions per user

Bad outcomes:

• Launch the new onboarding flow (this is a solution, not an outcome)
• Improve the user experience (this is not measurable)
• Increase revenue (this is too broad for one team to own)

The outcome should be something your team can influence directly and measure within a quarter. If your outcome is too broad, break it down. "Increase revenue" might decompose into "increase trial conversion" for the growth team and "reduce churn" for the retention team.

Your team's outcome should connect to the broader product strategy and roadmap. If it does not, you are optimizing in isolation.

Layer 2: Opportunities

Below the outcome, map the customer opportunities that could drive progress toward it. Opportunities are customer needs, pain points, and desires uncovered through research.

How to find opportunities:

• Customer interviews. Weekly conversations with users and prospects. Ask about their workflows, frustrations, and goals. Do not pitch solutions.
• Support tickets. Patterns in what customers struggle with reveal unmet needs.
• Usage data. Drop-off points in funnels, underused features, and high-frequency actions all signal opportunities.
• Sales calls. Reasons prospects say no or ask for features that do not exist.

Structuring opportunities:

Opportunities should be phrased from the customer's perspective, not your team's.

• "I waste time manually copying data between tools" (customer pain point)
• "I cannot tell if my changes are working" (unmet need)
• "I want to share results with my team without exporting" (desire)

Group related opportunities under parent opportunities to create a hierarchy. For example, "Onboarding takes too long" might be a parent with children like "I do not know where to start," "The setup wizard asks too many questions," and "I cannot import my existing data."

A healthy tree has 8 to 15 opportunities at any given time. Fewer than that, and you have not done enough research. More than that, and you need to prune or group.

Layer 3: Solutions

Below each opportunity, brainstorm multiple possible solutions. This is critical: never settle on one solution per opportunity. Generate at least three.

Why multiple solutions matter:

The first solution you think of is rarely the best. It is the most obvious. By forcing yourself to generate alternatives, you discover simpler, cheaper, or more creative approaches. A product trio ideating together brings three different perspectives, which naturally produces more diverse solutions.

Example: Opportunity = "I cannot tell if my changes are working"

• Solution A: Add a real-time preview panel
• Solution B: Send a weekly impact summary email
• Solution C: Add before/after comparison on the dashboard
• Solution D: Create a "changes" activity feed with metric annotations

Each solution addresses the same opportunity differently. Some are cheap to build. Some are high-effort but high-impact. Some are technically simple. Some require new infrastructure. The trio evaluates these trade-offs together before committing to test any of them.

Do not evaluate solutions immediately. First generate, then evaluate. Mixing generation and evaluation kills creativity.

Layer 4: Experiments

Below each solution, list the experiments that will test its riskiest assumptions. Every solution rests on assumptions. Your job is to identify the ones that would kill the solution if they are wrong, and test those first.

Common assumption types:

Designing experiments:

Keep experiments small. The goal is to learn, not to build. A good experiment takes days, not weeks. Ask: what is the smallest thing we can do to reduce our uncertainty about this assumption?

For a fake door test, you might add a button that leads to a "coming soon" page and measure click rates. For a prototype test, the designer builds a clickable prototype in Figma and runs five usability sessions. For a technical spike, the tech lead spends two days proving the data pipeline is feasible.

Evaluating results:

After each experiment, the trio reviews the results and makes one of three decisions:

1. Proceed. The assumption held. Move to the next riskiest assumption or, if all critical assumptions are tested, move the solution to the delivery backlog.
2. Pivot. The assumption was partly wrong. Modify the solution and test again.
3. Drop. The assumption failed. Remove this solution from the tree and explore alternatives.

Building Your First OST: Step by Step

Step 1: Choose Your Outcome (Day 1)

Work with your manager or product leader to select a measurable outcome for your team this quarter. Write it at the top of a Miro board, FigJam canvas, or whiteboard.

Step 2: Seed with Existing Knowledge (Day 1)

Before doing new research, map what you already know. Pull from recent customer interviews, support tickets, NPS comments, and sales feedback. Add these as opportunities under the outcome. You will likely have five to eight opportunities from existing knowledge.

Step 3: Validate and Expand Through Research (Weeks 1 to 3)

Run weekly customer interviews focused on the outcome area. After each interview, debrief with the trio and add new opportunities to the tree. Merge duplicates. Group related items under parent opportunities.

By week three, you should have a solid opportunity map with 8 to 15 items, organized into a meaningful hierarchy.

Step 4: Prioritize Opportunities (Week 3)

Not all opportunities are equal. Evaluate each one on:

• Frequency: How often do customers encounter this problem?
• Intensity: How painful is it when they do?
• Breadth: What percentage of your target users experience it?
• Strategic fit: Does solving this align with company goals?

Use a simple scoring approach or apply frameworks like RICE to rank opportunities. Select two or three to focus on first.

Step 5: Ideate Solutions (Week 4)

For each priority opportunity, run a trio ideation session. Set a timer for 15 minutes and generate as many solutions as possible. Use the design thinking principle of diverge before converge: generate first, evaluate second.

After generating, the trio evaluates solutions on effort, impact, and risk. Select one or two solutions per opportunity to test.

Step 6: Test Assumptions (Weeks 4 to 8)

For each selected solution, identify the riskiest assumption. Design a small experiment to test it. Run the experiment. Review results. Decide: proceed, pivot, or drop.

Repeat until you have at least one validated solution ready for the delivery backlog.

Step 7: Hand Off to Delivery

When a solution passes through assumption testing, the trio brings it to the full team during sprint planning. Share the outcome it serves, the opportunity it addresses, the evidence from experiments, and any remaining open questions. The team builds it with full context on why it exists and what customer problem it solves.

OST Template Structure

Here is a practical template for maintaining your tree.

OUTCOME: [Measurable goal for the quarter]
│
├── OPPORTUNITY: [Customer need/pain point]
│   ├── Solution A: [Description]
│   │   ├── Assumption: [Riskiest assumption]
│   │   └── Experiment: [How to test] → Result: [What happened]
│   ├── Solution B: [Description]
│   │   ├── Assumption: [Riskiest assumption]
│   │   └── Experiment: [How to test] → Result: [Pending]
│   └── Solution C: [Description]
│
├── OPPORTUNITY: [Customer need/pain point]
│   ├── Solution A: [Description]
│   └── Solution B: [Description]
│
└── OPPORTUNITY: [Customer need/pain point]
    └── (needs more research before ideating)

Color-code the tree to show status:

• Green: Validated through experiments, ready for delivery
• Yellow: Currently being tested
• Red: Failed assumption testing, dropped
• Gray: Not yet explored

Common Pitfalls

Jumping straight to solutions. Teams skip opportunity mapping and start brainstorming features immediately. Without understanding the customer problem, you are guessing. Spend at least two weeks on opportunity discovery before ideating solutions.

One solution per opportunity. If you only generate one solution, you have not explored the space. Force yourself to brainstorm at least three. The second and third ideas are often better than the first.

Testing too late. Teams sometimes design the full solution before running any experiments. By then, they are emotionally committed and will rationalize bad results. Test the riskiest assumption first, before investing in detailed design.

Treating the tree as static. An OST that does not change weekly is not being used properly. New research adds opportunities. Failed experiments remove solutions. Shifting strategy changes the outcome. Update the tree in every weekly discovery session.

Ignoring the outcome. Over time, teams drift into solving interesting problems that do not connect to the target outcome. Every opportunity and solution should trace back to the outcome at the top. If it does not, it belongs on a different tree or a future quarter's focus.

Where to Go from Here

The OST is one piece of a broader discovery practice. To build a complete system:

• Establish a product trio to own the tree collaboratively.
• Adopt continuous discovery habits for the weekly rhythm of interviews, mapping, and testing.
• Run dual-track agile to keep discovery and delivery flowing in parallel.
• Use assumption mapping to systematically identify which assumptions to test first.

The OST is not a one-time exercise. It is a living artifact that grows smarter as your team talks to more customers and runs more experiments. The teams that maintain it consistently build fewer features that nobody uses and more features that drive real outcomes.

Explore More

• What Is an Opportunity Solution Tree? - Expert answer on opportunity solution trees for product discovery.
• Top 8 Agile Frameworks for Product Teams (2026) - 8 agile frameworks compared side by side for product teams.
• Top 10 AI Tools for Product Managers (2026) - 10 AI-powered tools that save product managers hours every week.
• Top 10 Customer Feedback Tools and Methods (2026) - 10 tools and methods for collecting, organizing, and acting on customer feedback.