Opportunity solution trees
Grow one page from an outcome through interview-backed opportunities to solutions and tests, and cut the branch whose arithmetic cannot move the number.
On this page
An opportunity solution tree (Teresa Torres, Continuous Discovery Habits) is one page that connects the quarter's outcome to the solutions being built, through the customer needs that justify them. Its value is in what it forbids: no solution without an opportunity above it, no opportunity without an interview behind it, and no branch alive without a test that could kill it. The tree below has one outcome, four opportunities, six solutions and three tests, and one branch is cut before anything is built.
The four layers
The outcome sits at the root, as a metric with a target: tickets carried overnight at the 14-agent tenant, 130 today, under 20 by quarter end. It is the job statement from jobs to be done with a date on it. "Launch drafting" is not an outcome; it is a solution that has climbed the tree.
Opportunities are needs, pains and desires heard in interviews, written in the customer's words. "Replies to repeat questions take as long as new ones" is an opportunity. "Needs an AI assistant" is a solution in disguise, and the tell is that it names what we would build rather than what they struggle with.
Solutions hang under opportunities, at least two under any opportunity the team is serious about. One solution per opportunity means nothing was compared, and a tree with that shape was drawn from the backlog backwards.
Assumption tests are the leaves: the smallest experiment that could falsify the riskiest assumption under a solution. A test has a pass line written before it runs, so the result is a decision rather than a discussion.
The worked tree
Sixteen interviews this month, run as continuous interviewing describes, produced four opportunities. Each carries its count, and the count is a count of conversations, not of agents.
O1 — "Replies to repeat questions take as long as new ones" (11 of 16). The 3-minute reply, even when the answer is one of twenty standard ones. Solutions: S1, the model drafts a reply from the ticket and the nearest macro; S2, the model ranks the three most likely macros and the agent picks. Moving the reply from 3 minutes to 2 returns 560 agent-minutes a day, 280 replies at the new 2 minutes, more than twice the 130 in the backlog.
O2 — "I pick the wrong macro out of 200" (7 of 16). Solutions: S3, search over the macros by intent rather than title; S4, retire the macros nobody used in 90 days, which an export shows is about 140 of the 200. S4 has no model in it and belongs on the tree anyway; a tree that only grows model-shaped solutions is a roadmap wearing a costume. Scale: 1 ticket in 6 loses about 90 seconds to a wrong pick, 93 × 1.5 ≈ 140 agent-minutes a day.
O3 — "An escalation waits on a second person" (9 of 16). Solution: S5, a drafted escalation summary the agent corrects rather than writes. 1 ticket in 12 escalates, about 47 a day; the agent spends 4 minutes on the summary and a draft would save 2, so 94 agent-minutes a day. Real, and the customer's 20-minute wait is a different metric from the one at the root. It has one solution so far, so T3 checks the drafted summary is worth having before a second solution goes under O3 to compete with it.
O4 — "I retype the customer's order details" (2 of 16). Solution: S6, order details filled from the CRM. The pain is real, and the arithmetic cuts it: it happens on 1 ticket in 10 and costs 15 seconds, so 56 × 0.25 = 14 agent-minutes a day. Solved outright, O4 moves the outcome by about 5 replies at 3 minutes each, against a target of 110 fewer tickets overnight. It is cut, and the cut is written on the tree with its number, so the next person to hear it in an interview can see why it is not being built.
The three tests sit under the solutions that need them. T1, under S1: three agents, one afternoon, 60 tickets; the branch survives if at least 30 drafts are inserted. T2, under S2: log for a week whether the agent picks one of the three ranked macros; pass at 70%. T3, under S5: 20 escalations with a drafted summary; pass if 14 go out unchanged. T1 is the one-day prototype. The 5% ceiling on wrong replies sent, from the job statement, is the test after T1, and it needs a golden set rather than an afternoon.
Growing and pruning weekly
The tree is not drawn once. Each week's interviews add an opportunity or raise a count; each test kills a solution or scopes it; and the Friday version is the one artefact that shows why this solution is being built and not that one. When an executive asks why the team is not building the CRM fill, the answer is one branch, dashed, with "14 minutes a day" written beside it.
Before the fix, the tree was a backlog with a heading: five features, each with an opportunity invented on the day to justify it, every opportunity with exactly one child. After the fix, O1 has two solutions competing, one of them cheap (S2 needs no generation at all), and the competition is settled by T1 and T2 rather than by whoever spoke last. The tree feeds prioritisation rather than replacing it: once two branches survive their tests, RICE and ICE, worked decides the order with reach and effort the tree does not carry.
What the tree cannot do is tell you that an opportunity is common. 11 of 16 interviews is eleven conversations from a handful of tenants. The count says where to look; the ticket log at the tenant, 560 a day, says how often. The arithmetic above used the log for every rate and the interviews for none of them.
In an interview
What is being tested is whether you can connect a feature to an outcome through evidence, and whether you can say, before building, what result would make you cut it. Walk the branch out loud: "The outcome is 130 to under 20 overnight. Eleven of sixteen interviews named the slow repeat reply. Two solutions under it; the first gets an afternoon with three agents and dies if fewer than 30 of 60 drafts are inserted." Then name the branch you cut and the number that cut it.
The mistake that loses points is a tree with one solution under every opportunity, drawn from the backlog backwards — the interviewer can see that no choice was ever made. The second is cutting a branch by taste: "the CRM thing felt small" loses to "14 agent-minutes a day, about 5 replies against 130".
Check yourself
1. A stakeholder adds "AI chatbot for end customers" to the tree. Where does it go?
Nowhere yet. It is a solution, and no opportunity above it exists: none of the 16 interviews had a customer asking for self-serve. It goes in a parking lot with the interview question that could find its opportunity — "tell me about the last time a customer asked something the help centre already answers" — and if that story shows up in next week's four interviews, it earns a branch.
2. T1 returns 22 of 60 drafts inserted. Cut S1?
The rule said 30 and 22 is 37%, so the default is cut. Look at the split first: if 20 of the 38 discards came from one ticket type, S1 survives scoped to the other types and the rule is re-run on them. If discards are spread evenly, cut and move the afternoon to S2, which needs no generation and has a cheaper test. One rule, one look at the distribution, then the cut.
3. Two opportunities each return about 90 agent-minutes a day. Which gets the first test?
The one with the cheaper test. Equal value means you are buying information, so a week of logging beats a day of building, and a day of building beats a month of engineering. Tie-break on spread: an opportunity heard at 5 of 9 tenants outranks one heard at 2, because the product serves every tenant, not only the nine interviewed.