2026-10-14
October 14, 2026
Most programs arrive pre-decided: a list of things to build, no record of the needs they serve. Teresa Torres's opportunity solution tree is the cheapest way to give a TPM that record back.
Open the last program brief you inherited. Count the nouns. Dashboards, migrations, a new service, an agent platform, a rewrite. Now count the customer needs the document names, the problems someone could point at and say "this hurts, here is who it hurts, here is how we know." In most briefs the first count is twenty and the second is zero or one. The program is a bundle of solutions that lost its reasons somewhere between the offsite and the kickoff.
That is not a planning failure. It is a discovery failure, and TPMs are unusually exposed to it because we receive programs rather than originate them. A product manager is at least nominally holding the question of whether this is the right thing to build. A TPM is handed the answer and asked when it lands. Every dependency map, every milestone plan, every RAID log we write is a careful treatment of a decision nobody can reconstruct.
Teresa Torres's opportunity solution tree is a small structural fix for this. It does not ask you to run a discovery phase or hire researchers. It asks you to keep a picture that links the outcome the program exists for, the needs that would move it, the candidate solutions, and the assumptions each solution rests on. Below, why this belongs in program management and not only in product, and how to build one without a research team.
The opportunity solution tree comes from Teresa Torres of Product Talk, and it is the central artifact of her book Continuous Discovery Habits. The structure is four levels. At the root sits a desired outcome. Beneath it is the opportunity space: customer needs, pain points and desires that, if addressed, would drive that outcome. Beneath that is the solution space: the options a team might build. And hanging off each solution are assumption tests, the cheap experiments that tell you whether the idea deserves to survive. Product Talk's own description of the tree says it "makes implicit assumptions explicit," and that is the property a TPM should care about.
Consider what a program plan actually encodes. A Gantt chart or a milestone list is a statement about sequence and capacity. It says nothing about why. When a dependency slips or a stakeholder asks whether we still need the third workstream, the plan cannot answer, because the reasoning lived in someone's head or in a deck that has since been archived. The tree is the missing layer. It is the program's memory of why.
The first discipline Torres insists on is the one most programs fail: opportunities are customer needs, not solutions in disguise. Her test is practical. If an item on the opportunity layer can be addressed in only one way, it is probably a solution wearing a need's clothing. "We need a unified observability platform" fails the test. "On-call engineers cannot tell which of three alerting systems owns a page" passes it, because there are many ways to address it, from better routing to deleting two of the systems. For internal programs, the customer is usually an engineer, an on-call rotation, a partner team or a finance reviewer. The test still works. Name the person and the moment.
The second discipline is compare and contrast. Torres's argument is that when teams weigh a single idea they fall into a yes-or-no debate, and when they compare several they make better decisions. Her guidance is to generate a handful of solutions for one target opportunity and take about three forward. Programs almost never do this. The solution arrives singular, usually from the loudest senior voice, and the planning that follows treats it as settled. Asking a steering committee "which two other ways could we address this need, and why are we not doing those?" is one of the cheapest and most uncomfortable questions in the TPM toolkit.
The third is assumption testing over solution debate. Torres puts it plainly: the best way to evaluate solutions is through assumption testing. Take the program's chosen solution and write down what must be true for it to work. Teams will adopt the new pipeline. The migration tool handles the long-tail services. The partner team will staff its side by Q2. Then rank by risk and test the riskiest one first, for days rather than quarters. A TPM already does a version of this in risk reviews. The tree changes what gets asked: not "what could go wrong with delivery" but "what are we assuming about whether this is the right thing."
Now the honest limits. Torres's recipe starts with prerequisites: a target customer, a clearly defined outcome, and a few story-based customer interviews. She recommends a product outcome, something a customer's behavior changes, over a pure business outcome or traction metric. Many programs, especially compliance work, cost programs and platform consolidations, have outcomes that are not customer-behavior shaped, and the tree strains there. My read, which is an extension and not Torres's claim: use the tree at the front of any program where the what is still contestable, and skip it where the what is legally or contractually fixed. A regulatory deadline does not need an opportunity layer. A "platform modernization" with an eighteen-month budget absolutely does.
There is also a cadence argument. Torres's broader point is that discovery is a habit, not a phase. For programs that means the tree is not drawn once at kickoff and filed. It is revisited when evidence arrives. A failed assumption test or a surprising incident prompts the question her framework builds in: evolve the solution, pick a different opportunity, or revisit the outcome. A program that cannot ask the third question has no way to stop.
Try this week. Pick one active program and write its tree on a single page in 45 minutes: the outcome at the top, three to five customer needs you can attribute to a named person or team, and under the one you believe matters most, the three solutions that could address it. Circle the chosen solution and write its riskiest assumption. If you cannot fill the opportunity layer without inventing needs, you have found your next discovery task, and probably your next steering committee question.
What it is. A visual map that connects a desired outcome to the customer needs that would move it, the solutions that could address those needs, and the assumption tests that decide which solutions survive. Torres, founder of Product Talk, published her step-by-step guide to building one in December 2023.
When to use it. At program kickoff when the solution has been handed down and nobody can state the need behind it. Also mid-flight when scope keeps growing, when a stakeholder asks "why are we doing this," or when a roadmap has become a list of features with no shared reason.
How to run it:
When NOT to use it. When the outcome and the solution are fixed by regulation, contract or a hard external date, because there is nothing left to discover and the tree becomes theater.
One-line example: "Consolidate the CI systems" becomes an opportunity ("engineers wait on flaky builds with no clear owner"), three candidate solutions, and the assumption that tests all three: teams will actually migrate if it costs them less than a week.
Building resilient AI-powered software, and planning for when things go wrong — Gergely Orosz (Oct 13) shares Sam Newman's book excerpts on disaster-recovery patterns, with a warning that AI vendors add uncertainty through reliability, shifting model behavior and rising cost. A sound prompt for your next dependency review: which of your programs assume a single model provider?
AI is changing the way we build products: lessons from Teresa Torres — Lucid's write-up (Feb 2026) of Torres calling AI evals "a new discovery habit," and her advice to synthesize interviews yourself before comparing against an AI summary. Useful for TPMs deciding where AI belongs in discovery and where it quietly replaces the learning.
Engineering leadership in 2026 (LeadDev) — A talk page from Scott Carey (June 2026) built on a survey of 600+ engineering leaders about how their roles are shifting. The findings sit behind a free registration, so treat this as a pointer to check, not a summary.
"The best way to evaluate solutions is through assumption testing."
— Teresa Torres, Product Talk
Don't miss what's next. Subscribe to Critical Path: