Opportunity Solution Trees: The Discovery Framework PMs Need

What an opportunity solution tree actually is

The opportunity solution tree is a visual framework developed by Teresa Torres for connecting your desired product outcome to the customer opportunities that could move it, and then to the solutions and assumptions underneath each opportunity. Root of the tree: your outcome. First branch level: the opportunity space. Below that: more specific opportunities. Below that: potential solutions. Below that: the assumptions you'd need to test before betting on any solution.

What it is not: a diagram you draw once in Miro during a team offsite and never open again. That's the version of OST I see most often, and it explains why most teams say they "tried it" but got nothing out of it.

The tree only works if it's a living document your team updates as you learn. It's a shared memory for your discovery, not a deliverable for a quarterly review.

The three places teams get stuck

The first failure mode is treating OST as an output rather than a practice. Teams spend two hours building a beautiful tree, present it to stakeholders, and then move on. The tree becomes stale within weeks. The point of the tree is that it changes as you learn. If it's not changing, you're not doing discovery.

The second failure mode is skipping the opportunity framing step. This one is subtle but it kills the whole thing. Teams want to get to solutions fast, so they jump from outcome to "things we could build" without pausing to map the customer need space. An opportunity is not a solution in disguise. It's a gap between where your customer is and where they want to be. Getting that right takes time, and most teams rush it.

The third failure mode is moving to solutions before mapping assumptions. I've seen this pattern repeatedly: a team identifies a promising opportunity, falls in love with one solution, and starts building. Three months later, the solution solves the opportunity but the core assumption underneath it was wrong. The user didn't actually behave the way the team imagined. Mapping assumptions explicitly, before committing, is where OST earns its keep.

How to run your first OST session

Start with your current product outcome. If you don't have one, stop here and define it. Not a metric you want to move in the abstract, but a specific outcome your team owns for the next quarter. This is the root of your tree.

The opening question for the session is: "What's getting in the way of our users reaching this outcome?" That question pulls out opportunities, not features. Spend the first session just filling in the opportunity level. Resist solutions entirely. You want at least 10 to 15 opportunities before you start grouping and prioritising.

Update the tree after every customer interview. Not a full rebuild. Just: did we learn something that adds a new opportunity, removes one, or changes how we'd weight them? That's a 15-minute habit, not a project. Over time, patterns become visible that single interview summaries never show.

This connects directly to continuous discovery. [How to Redesign Your Discovery Process Around AI](/blog/how-to-redesign-discovery-process-around-ai) covers the process side of this in more depth, but the short version is: weekly interviews without a shared tree produce individual insights. A shared tree turns those insights into decisions.

How AI fits into OST practice in 2026

AI is genuinely useful at one specific point in the OST workflow: synthesising interview notes into opportunity candidates. If your team runs four customer calls a week, you don't have time to manually cross-reference themes across all four transcripts before your next planning session. AI can do that fast.

What AI cannot do is decide which opportunity is worth pursuing. That judgment call requires knowing your strategy, your constraints, and what you actually believe about your users. The tree is where that judgment lives. AI is useful input into it, not a replacement for it.

My experience is that teams who start using AI to pre-process interviews and surface opportunity candidates update their tree more consistently. The friction of the synthesis step was what was killing the habit.

One thing to do before your next sprint planning

Pick your current product outcome. Open a shared whiteboard. Write the outcome at the top and spend 20 minutes with your team asking "what's in the users' way?" Don't touch solutions yet. Just fill the opportunity level.

That's session one. The tree grows from there.