Opportunity solution tree

An Opportunity Solution Tree (OST) is a visual thinking tool that helps product teams systematically explore the path from a business outcome to testable solutions. Created by Teresa Torres as part of the Continuous Discovery framework, the OST structures the messy work of product discovery into a clear hierarchy: outcome at the top, opportunities branching below, solutions beneath those, and experiments at the base. This structure prevents teams from jumping straight to solutions while ensuring every decision connects back to desired outcomes.

Why it matters

Product teams frequently fall into two traps. The first is building solutions without understanding the problem - shipping features because stakeholders requested them or because competitors have them, without validating that they address real customer needs. The second is analysis paralysis - endlessly researching without committing to action.

The Opportunity Solution Tree addresses both problems. It forces teams to explicitly connect solutions to customer opportunities and business outcomes, preventing aimless building. It also creates a clear path from discovery to action, with experiments providing the mechanism to move forward despite uncertainty.

The visual nature of the tree makes thinking visible to the entire team and stakeholders. Everyone can see what outcome the team is pursuing, what opportunities they've identified, and what solutions they're considering. This transparency improves alignment and quality of discussion.

Structure of an opportunity solution tree

The tree has four levels, each serving a distinct purpose.

Outcome sits at the top - a single, measurable business or product result the team is trying to achieve. This is typically assigned by leadership and represents what success looks like. Examples: "Increase trial-to-paid conversion from 8% to 12%" or "Reduce customer support tickets by 25%."

Opportunities branch from the outcome - the customer needs, pain points, or desires that, if addressed, would drive the outcome. Opportunities come from customer research: interviews, feedback analysis, behavioral data. They represent the "problem space." Examples: "Users struggle to understand pricing options" or "Users can't find help documentation when stuck."

Solutions branch from opportunities - the specific product changes, features, or interventions that might address each opportunity. Multiple solutions can address a single opportunity. These represent the "solution space." Examples: "Interactive pricing calculator," "Simplified pricing tiers," or "Comparison table."

Experiments branch from solutions - the small tests that help the team learn whether a solution will actually work before fully building it. Experiments reduce risk by validating assumptions early. Examples: "A/B test pricing page layout," "Prototype test with 10 users," or "Fake door test for new feature."

Building an opportunity solution tree

Creating an effective OST requires disciplined process.

Start with a clear outcome. The outcome should be specific, measurable, and within the team's ability to influence. "Improve user experience" is too vague; "Increase 7-day activation rate from 40% to 55%" gives the team something concrete to pursue.

Map opportunities through research. Conduct customer interviews, analyze feedback, review support tickets, and examine behavioral data to understand what's preventing or enabling the outcome. Each opportunity should represent a distinct customer need, not a solution in disguise. "Users need a mobile app" is a solution; "Users need to check status while away from their desk" is an opportunity.

Generate multiple solutions per opportunity. Avoid anchoring on the first idea. For each opportunity, brainstorm several possible approaches. This expands the solution space and increases the chances of finding effective interventions.

Design experiments to test assumptions. For each promising solution, identify the riskiest assumptions and design small experiments to test them. What would need to be true for this solution to work? How can you test that cheaply?

Using the tree for decision-making

The OST isn't just a documentation tool - it's a decision-making framework.

Prioritize opportunities before solutions. Not all opportunities are equal. Some have larger potential impact on the outcome; some are easier to address; some affect more customers. Evaluate opportunities before diving into solutions to ensure you're working on the right problems.

Compare solutions within opportunities. When you've identified an important opportunity, evaluate the candidate solutions against each other. Which is most promising? Which is cheapest to test? Which has the most uncertain assumptions?

Let experiments guide decisions. Run experiments on your most promising solutions. Results tell you whether to proceed with building, pivot to a different solution, or return to exploring other opportunities.

Prune regularly. As you learn, some branches become more promising and others less so. Update the tree to reflect current understanding. A stale tree loses its value as a thinking tool.

Common mistakes

Several patterns undermine OST effectiveness.

Solutions masquerading as opportunities happens frequently. "Users need a dashboard" is a solution, not an opportunity. The opportunity might be "Users need visibility into team progress" - which could be addressed by a dashboard, email digest, Slack integration, or other solutions. Keep the opportunity level focused on customer needs, not product features.

Single-solution thinking defeats the purpose. If you've identified an opportunity and generated only one solution, you're probably anchoring. Push for at least three solutions per opportunity before evaluating.

Skipping experiments is tempting when you're confident, but confidence isn't knowledge. Even small experiments can reveal surprises that change direction. The discipline of testing separates discovery from feature factory.

Neglecting the tree turns it into documentation rather than a living tool. Update it weekly based on new research, experiment results, and shifting priorities.

Opportunity solution trees and continuous discovery

The OST is central to Teresa Torres's Continuous Discovery Habits framework, which advocates for regular, small-scale research rather than occasional big studies.

In continuous discovery, teams conduct customer interviews weekly, synthesize findings into opportunities, and run experiments regularly. The OST becomes the map for this ongoing work - always reflecting current understanding and guiding next actions.

This approach differs from traditional product development, where research happens in phases separated from delivery. Continuous discovery integrates research into the regular rhythm of product work.

Connecting to customer feedback

Customer feedback provides raw material for opportunity identification. Support tickets reveal pain points; feature requests hint at unmet needs; churn interviews expose failure modes.

Tools like Klero help product teams aggregate and analyze feedback at scale, surfacing patterns that become opportunities on the tree. When dozens of customers express similar frustrations, that pattern represents a validated opportunity worth exploring solutions for.

The key is translating feedback into opportunity language. "We need bulk editing" is a feature request (solution); "Users spend too much time making repetitive changes" is the underlying opportunity.