Definition
Opportunity Solution Tree
An opportunity solution tree is a visual map, created by Teresa Torres, that connects a desired outcome at the top to the customer opportunities (unmet needs and pain points) beneath it, then to candidate solutions and the assumption tests that validate them. It keeps a team focused on outcomes and makes the reasoning behind product decisions explicit.
Key takeaways
- An opportunity solution tree (Teresa Torres, 2016) maps a desired outcome to customer opportunities, then to solutions and assumption tests.
- Anchoring everything to one outcome keeps a team from chasing unrelated features.
- Framing solutions as children of opportunities forces the question: which customer need does this feature serve?
- It's a living map updated through discovery, not a one-time plan — branches are added, reframed, or pruned as evidence arrives.
Teresa Torres introduced the opportunity solution tree (OST) in 2016 as the central artifact of continuous discovery. The root is a single desired outcome — usually a measurable business or product result. Below it branch the opportunities: customer needs, pain points, and desires learned from talking to users. Under each opportunity sit potential solutions, and under those, the assumption tests that check whether a solution will actually work.
The structure forces good habits. By anchoring on one outcome, it prevents a team from chasing unrelated features. By framing solutions as children of opportunities, it makes teams ask which customer need a feature serves before building it. And by surfacing assumptions, it turns implicit bets into explicit, testable claims.
Crucially, the tree is a living map, not a one-time plan. As discovery continues, opportunities are added, reframed, or pruned, and the team chooses which branch to pursue based on evidence — visualizing trade-offs instead of arguing over a flat backlog.
Planoda lets you tie issues and experiments back to the opportunity and outcome they serve, so the delivery work always traces to a validated need.
Related terms
- Continuous DiscoveryContinuous discovery is the practice of engaging with customers regularly — ideally weekly — to inform product decisions, rather than running discovery as a one-off phase before delivery. Small cross-functional teams interview users, spot unmet needs, test solution ideas, and feed that learning directly into what they build, keeping discovery and delivery running in parallel.
- Jobs to Be Done (JTBD)Jobs to Be Done is a framework for understanding why customers adopt a product: people "hire" products to make progress on a specific job in a given circumstance. It shifts focus from customer demographics and product features to the underlying goal — the job — revealing the real competition and the true criteria by which customers judge success.
- OKR (Objectives and Key Results)OKR is a goal-setting framework that pairs a qualitative Objective — what you want to achieve — with three to five measurable Key Results that prove you got there. Set per quarter and scored at the end, OKRs align a team on a small number of outcomes, keeping effort focused on results rather than a list of activities.
- RoadmapA roadmap is a high-level, time-oriented view of what a team or product plans to build and roughly when. It communicates direction and sequencing across initiatives and projects, aligning stakeholders on priorities. Unlike a backlog of granular tasks, a roadmap operates at the altitude of themes, outcomes, and quarters rather than individual issues.
- Product OwnerA product owner is the person accountable for maximizing the value a Scrum team delivers. They own and order the product backlog, decide what gets built and in what sequence, and translate stakeholder needs into clear, prioritized work. They are a single, empowered decision-maker — not a committee — so the team always has one authoritative source of priority.