Building Opportunity Solution Trees with AI (Teresa Torres Method)

What an Opportunity Solution Tree actually is

Teresa Torres' Opportunity Solution Tree has three layers, and the discipline is in keeping them separate. At the root sits one desired outcome — a metric you're trying to move, not a feature you want to ship. Below it, opportunities: the specific customer needs, pain points, and desires that could move that outcome, each one evidenced by something a real user said or did. Below those, solutions — the candidate ways to address an opportunity, each one meant to be tested, not committed to on sight.

The failure mode almost every team falls into is starting from the bottom: a solution someone already wants to build, retrofitted with an opportunity that justifies it and an outcome that justifies that. The tree looks right in the deck. It just wasn't built in the order that makes it trustworthy.

A tree built backwards from a solution isn't discovery — it's a roadmap wearing a discovery costume.

The second failure mode is subtler and just as common: the tree is built forwards, in the right order, but from the wrong material. A room full of smart people brainstorming opportunities from memory produces branches that sound like customer needs but are really the team's own assumptions about customers, restated with more structure. Nothing in that tree is false exactly — it's just untested, and a tree of untested branches gives false confidence precisely because it looks rigorous. The fix isn't a better workshop format. It's insisting that every opportunity trace back to something a specific user said or did, which is exactly the kind of bookkeeping an AI agent is good at and a room full of sticky notes is not.

Step 0 — You need an outcome and evidenced opportunities, not a blank canvas

Don't open a whiteboard tool and start drawing boxes. Before you touch a tree, you need two things written down: a single outcome metric your team owns, and a set of opportunities that came from real evidence — most commonly, interview synthesis checked against hypotheses. If your "opportunities" are actually a brainstormed list from a workshop, you have a wishlist, not a tree. Go collect the evidence first.

Step 1 — Ground the agent in the outcome and the evidence, once

Same rule as every other agentic PM workflow: give the agent your context in files before asking it to structure anything. In your workspace, keep:

• context/outcome.md — the one metric this tree is organized around, and why it matters this quarter
• context/interview-synthesis.md — the evidenced findings from your interview analysis pass, quotes and all
• context/product.md — what exists today, so the agent doesn't propose a solution that already shipped

This is the same context-first discipline behind every artifact in an agentic PM workflow — the tree is downstream of evidence you already gathered, not a fresh brainstorm the agent invents from nothing.

Step 2 — Ask for a tree, with a rule about evidence

Here's a starting prompt. The instruction that matters most is the traceability rule — without it, you get a tree that reads well and can't be defended in a review:

Read context/outcome.md, context/interview-synthesis.md and
context/product.md first.

Build an Opportunity Solution Tree for the outcome in context/outcome.md.

Structure:
- Root: the outcome metric
- Opportunities: customer needs/pain points/desires that could move it,
  pulled ONLY from context/interview-synthesis.md
- Solutions: 2-3 candidate solutions per opportunity, clearly marked
  as untested ideas, not commitments

Rules:
1. Every opportunity must cite which interview(s) support it. If you
   can't cite a source, don't include it — flag it as a gap instead.
2. Don't propose a solution for an opportunity we haven't validated
   with at least 2 separate interviews. Mark thin opportunities as
   "needs more evidence" instead of building solutions under them.
3. Rank opportunities by how directly they connect to the outcome,
   not by how interesting the solution sounds.

Rule 1 is what separates this from a whiteboard exercise: every branch has a receipt. Rule 2 stops the agent from architecting elaborate solutions under opportunities that are really just one enthusiastic user's opinion. Rule 3 fights the natural pull toward whichever opportunity has the most exciting solution attached — rank by outcome impact, not by which idea is more fun to build.

What good output looks like: not "users want better onboarding," but something with a paper trail — "Opportunity: sellers can't tell why a bulk upload failed until they open the raw error log (evidenced by interviews 2, 4, and 6 — interview 4 quoted the exact log line they had to Google). Needs more evidence: 'sellers want a dashboard redesign' — only interview 1 mentioned this unprompted, marking as a gap rather than a validated opportunity. Candidate solutions for the bulk-upload opportunity: (1) surface the failing row inline instead of a generic error, (2) email a diagnostic summary after a failed batch. Both untested — recommend a scrappy prototype of (1) first, since it's the cheaper build and directly answers what interviews 2, 4, and 6 asked for." Every clause traces back to a specific interview, and the thin opportunity is labeled thin instead of quietly promoted to a solution.

Step 3 — Prune ruthlessly; the agent will over-generate

Left alone, an agent will happily produce twelve plausible opportunities and thirty candidate solutions, because plausible is cheap to generate. Your job is the opposite instinct: cut the tree down to what you can actually act on this quarter. Ask directly — "which 3 opportunities, if solved, move the outcome most, and which are cheapest to test first?" — and be willing to demote an interesting opportunity to "parking lot" if it's not one of those three. A tree with forty boxes doesn't focus a team; a tree with the right five does.

Treat the tree as a living map, not a one-time deliverable. As new interviews come in, feed the updated synthesis back to the same session and ask the agent to reconcile: which opportunities gained more evidence, which lost support, what's new. A tree that never gets revisited calcifies into the same "organized opinion" problem it was built to avoid.

Step 4 — From tree to roadmap

Once an opportunity is well-evidenced and a solution direction looks worth testing, the tree's job is done — it hands off to an initiative or straight into a PRD if the evidence is strong enough to commit without a separate framing step. The point of keeping this in the same agent session is that the handoff carries the evidence with it: the PRD's problem statement can cite the same interview quotes the tree was built on, instead of a fresh team re-deriving "why are we building this" from scratch.

Common mistakes to avoid

• Starting from a solution. If you already know what you want to build, you're not doing discovery — write the PRD directly and be honest about it.
• Opportunities with no evidence behind them. A branch nobody can trace to an interview is a guess wearing a tree's clothing.
• Building solutions under thin opportunities. One person's opinion doesn't earn a solutions layer. Mark it as needing more evidence and move on.
• Never pruning. A tree with every plausible branch kept "just in case" doesn't focus anyone. Cut hard, park the rest.
• Treating the tree as a one-time artifact. New evidence should update the tree, not sit in a separate document nobody reconciles.

FAQ