Contents
Use this when a decision branches into a sequence of choices and uncertain outcomes, each with different probabilities and payoffs. The decision tree maps every path forward, assigns values and likelihoods, then calculates backward to reveal which first move maximises expected value — turning a tangle of contingencies into arithmetic.
Section 1
What This Tool Does
Most consequential decisions aren't single choices. They're chains. You decide whether to launch a product, and that decision leads to a market response — strong or weak — which triggers another decision about whether to scale or pivot, which leads to another set of uncertain outcomes. The human brain handles this poorly. Not because people can't think sequentially, but because they can't hold the full tree of possibilities in working memory while simultaneously weighting each branch by its probability and value. By the third branching point, intuition has quietly dropped half the paths and overweighted the most vivid remaining scenario. You end up optimising for the future you can most easily imagine, not the future with the highest expected value.
The decision tree was formalised in the operations research tradition of the 1950s and 1960s, with Howard Raiffa and Robert Schlaifer at Harvard Business School providing the foundational framework in their 1961 work on applied statistical decision theory. The tool emerged from a simple observation: military and industrial planners were making sequential decisions under uncertainty using gut feel and scenario narratives, and they were systematically getting it wrong. Not because they lacked intelligence, but because narrative reasoning — "if we do X, then probably Y will happen, and then we'll do Z" — collapses the probability distribution into a single storyline. The decision tree forces you to keep all the storylines alive simultaneously.
The mechanism is straightforward. You draw the decision as a tree, branching left to right. Square nodes represent choices you control. Circular nodes represent uncertain outcomes you don't control. Each branch from a chance node gets a probability (which must sum to 1.0 across siblings). Each terminal branch — the end of a path — gets a payoff value. Then you work backward from the endpoints, calculating expected values at each chance node (probability × payoff, summed across branches) and selecting the highest-value option at each decision node. The result is a single recommended action at the root of the tree, backed by the full arithmetic of every downstream possibility.
The core cognitive shift: the decision tree forces you to price uncertainty rather than ignore it. Instead of asking "what will happen if we do this?" — a question that invites a single narrative answer — it asks "what are all the things that could happen, how likely is each, and what is each worth?" That reframing is the entire intervention. It converts a story into a calculation, and calculations don't suffer from availability bias or anchoring.
The tool's elegance lies in its backward induction logic. You don't decide what to do first and then figure out the consequences. You start at the consequences — every possible endpoint — and let the math pull you backward to the optimal first move. This reversal is unnatural for human cognition, which is precisely why it works. Your brain wants to reason forward from the present. The decision tree reasons backward from every possible future.
Section 2
How to Use It — Step by Step
Instructions on the left. Worked example — "Should a Series B SaaS company build an AI feature in-house, acquire a startup that has one, or license from a third-party vendor?" — on the right.
Step 1 — Frame
Identify the initial decision and the key uncertainties that follow it
Start by listing the choices available to you right now — these form the first branches from the root decision node (drawn as a square). Then, for each choice, ask: "What uncertain event determines whether this works?" Those events become chance nodes (drawn as circles). Don't try to capture every possible contingency. Limit yourself to the one or two uncertainties per branch that most affect the outcome. A tree with more than three levels of branching becomes unwieldy and the precision of your probability estimates won't justify the complexity.
Worked example
SaaS company — AI feature decision
The CEO faces three options: Build (18-month internal development), Acquire (buy a 12-person AI startup for $8M), or License (integrate a third-party API at $600K/year). The key uncertainty for each: Build → will the internal team ship on time and at quality? Acquire → will the acquired team retain and integrate successfully? License → will the vendor maintain competitive feature parity? Each option also faces a shared downstream uncertainty: market adoption (strong vs. weak demand for AI features among the existing customer base).
Step 2 — Structure
Draw the tree with decision nodes, chance nodes, and terminal outcomes
Lay out the tree left to right. The root is your decision node. Each branch leads to a chance node representing the primary uncertainty. Each chance node branches into outcomes (typically 2–3: success/failure, or high/medium/low). If a second decision follows — "do we double down or cut losses?" — add another decision node. Every path through the tree must terminate in a payoff. Draw every path, even the ones you'd rather not think about. The tree's value comes from forcing you to confront the full range of outcomes, including the ugly ones.
Worked example
Structuring the SaaS tree
Root decision node → three branches (Build, Acquire, License). Each leads to a chance node for execution risk. Build branches into: ships on time (0.45) or delayed/underperforms (0.55). Acquire branches into: successful integration (0.50) or key talent departs (0.50). License branches into: vendor maintains parity (0.70) or vendor falls behind (0.30). Each of those outcomes then hits a second chance node for market adoption: strong (0.60) or weak (0.40). That gives us 12 terminal paths — every combination of choice, execution outcome, and market response.
Step 3 — Assign
Estimate probabilities for each chance branch and payoffs for each terminal node
This is where most teams either rush or stall. Probabilities must sum to 1.0 at each chance node. Use base rates where available — industry data on acquisition integration success rates, historical on-time delivery rates for your engineering team, vendor churn statistics. Where data is thin, use calibrated estimates from the people closest to the work. Payoffs should be in the same unit (typically net present value of incremental revenue minus costs over a defined time horizon). Be explicit about what's included: revenue uplift, development costs, opportunity costs, integration expenses. A payoff estimate that's off by 2x matters less than a probability estimate that's off by 2x — the tree is more sensitive to probabilities than to terminal values.
Worked example
Populating the numbers
Build + on time + strong adoption: $22M incremental revenue over 3 years minus $4M dev cost = $18M. Build + on time + weak adoption: $6M revenue minus $4M = $2M. Build + delayed + strong adoption: $10M (late to market, competitors capture share) minus $6M (cost overruns) = $4M. Build + delayed + weak: $2M minus $6M = −$4M. Acquire + integrates + strong: $20M minus $8M acquisition = $12M. Acquire + integrates + weak: $7M minus $8M = −$1M. Acquire + talent departs + strong: $5M minus $8M = −$3M. Acquire + talent departs + weak: $1M minus $8M = −$7M. License + parity + strong: $15M minus $1.8M (3yr license) = $13.2M. License + parity + weak: $4M minus $1.8M = $2.2M. License + falls behind + strong: $6M minus $1.8M = $4.2M. License + falls behind + weak: $1M minus $1.8M = −$0.8M.
Step 4 — Calculate
Work backward from terminal nodes using expected value at each chance node
Start at the rightmost nodes. At each chance node, multiply each branch's payoff by its probability and sum the results. That gives you the expected value (EV) of arriving at that chance node. Move left. At the next chance node, do the same — but now the "payoffs" feeding in are the EVs you just calculated. At decision nodes, select the branch with the highest EV. Continue until you reach the root. The option with the highest EV at the root is your recommended action. Write the EV on each node as you go — this creates an audit trail that makes the logic transparent and debatable.
Worked example
Rolling back the SaaS tree
Build + on time → EV = (0.60 × $18M) + (0.40 × $2M) = $11.6M. Build + delayed → EV = (0.60 × $4M) + (0.40 × −$4M) = $0.8M. Build overall → EV = (0.45 × $11.6M) + (0.55 × $0.8M) = $5.66M. Acquire + integrates → EV = (0.60 × $12M) + (0.40 × −$1M) = $6.8M. Acquire + departs → EV = (0.60 × −$3M) + (0.40 × −$7M) = −$4.6M. Acquire overall → EV = (0.50 × $6.8M) + (0.50 × −$4.6M) = $1.1M. License + parity → EV = (0.60 × $13.2M) + (0.40 × $2.2M) = $8.8M. License + falls behind → EV = (0.60 × $4.2M) + (0.40 × −$0.8M) = $2.2M. License overall → EV = (0.70 × $8.8M) + (0.30 × $2.2M) = $6.82M.
Step 5 — Interpret
Compare EVs, test sensitivity, and decide
The highest EV at the root is your starting recommendation — but not necessarily your final answer. Run sensitivity analysis on the inputs that matter most. Which probability, if changed by ±10 percentage points, flips the recommendation? That's where you should invest in better information before committing. Also consider the distribution of outcomes, not just the average. Two options with similar EVs may have very different risk profiles — one might have a tight range of outcomes while the other has a high ceiling and a catastrophic floor. If the downside of the worst path threatens the company's survival, EV alone isn't sufficient. Factor in your risk tolerance explicitly.
Worked example
What the tree reveals
License wins at $6.82M EV, narrowly beating Build ($5.66M) and decisively beating Acquire ($1.1M). But the sensitivity analysis is revealing: if the probability of on-time build delivery rises from 0.45 to 0.60 — achievable by hiring two senior ML engineers — Build's EV jumps to $7.28M and overtakes License. The acquisition is the weakest option not because of its upside (which is strong if integration succeeds) but because the downside is severe: a 50% chance of losing $4.6M in expected value. The tree's recommendation: license now, but invest in building internal capability. If the team demonstrates it can ship ML features reliably, revisit the build option in 12 months.
Section 3
When It Works Best
✓
Ideal Conditions for Decision Trees
| Dimension | Best fit |
|---|---|
| Decision structure | Sequential decisions where each choice opens a different set of possibilities. The tool shines when you face a chain — decide now, observe an outcome, decide again — rather than a single one-shot choice. Capital allocation, product strategy, M&A, clinical trial design, litigation strategy: all naturally sequential. |
| Uncertainty profile | Outcomes that can be decomposed into a small number of discrete scenarios with estimable probabilities. You don't need precise probabilities — directionally correct estimates still produce useful comparisons. But you do need the uncertainty to be decomposable: "the market will be strong or weak" is workable. "Something unprecedented might happen" is not. |
| Payoff measurability | Outcomes that can be expressed in a common unit — dollars, lives saved, months of runway, customer lifetime value. The tree's arithmetic requires commensurable endpoints. When outcomes involve incommensurable values (brand reputation vs. short-term revenue), the tree still helps structure the problem but the rollback calculation becomes a judgment call rather than pure math. |
| Stakeholder alignment | Decisions involving multiple stakeholders who disagree on the best path. The tree externalises the reasoning: disagreements become debates about specific probabilities or payoff estimates rather than vague arguments about "strategy." This is the tool's underrated superpower — it turns subjective disputes into calibration exercises. |
| Reversibility | Particularly valuable for irreversible or expensive-to-reverse decisions where you can't afford to "try and see." An acquisition can't be undone. A two-year development programme consumes resources that won't come back. The tree forces you to price the full range of consequences before you commit, which is exactly the discipline irreversible decisions demand. |
| Information value | When you're considering whether to gather more information before deciding — running a pilot, commissioning a study, waiting for a competitor's move — the tree can quantify the value of that information. Add a branch for "wait and learn," update the probabilities on the downstream branches, and compare the EV of deciding now vs. deciding later with better data. This is one of the most powerful and least-used applications of the tool. |
Section 4
When It Breaks Down
⚠
Failure Modes
| Failure pattern | What goes wrong | What to use instead |
|---|---|---|
| False precision | Teams assign probabilities to three decimal places and payoffs to the nearest thousand, creating an illusion of mathematical certainty. The output looks like engineering when the inputs are educated guesses. A tree that says Option A has an EV of $6.82M and Option B has $6.71M is not telling you A is better — it's telling you the options are indistinguishable given your input uncertainty. | Run sensitivity analysis on every input. If a ±10% swing in any probability flips the answer, the tree hasn't resolved the decision — it's identified where you need better data. |
| Incomplete tree structure | The most common structural error: omitting branches that represent uncomfortable outcomes. Teams draw the success paths in detail and give the failure paths a single terminal node with a rough estimate. But the failure paths often contain embedded decisions — "if the acquisition fails, do we write it off or try to salvage?" — that dramatically affect the EV calculation. | Pre-Mortem before building the tree to surface failure scenarios; Inversion to identify missing branches |
| Continuous uncertainty forced into discrete buckets | Market size isn't "big or small." It's a continuous distribution. Forcing it into two or three discrete outcomes loses information and can distort the EV calculation, especially when the distribution is skewed. A market that's most likely moderate but has a fat tail of extreme upside looks very different from a symmetric "high or low" split. | Monte Carlo simulation for decisions with continuous uncertain variables; use the tree for structure but simulate the distributions |
| Correlated uncertainties treated as independent | The tree structure implies that the probability at each chance node is independent of other branches. In practice, uncertainties are often correlated: if the market is weak, your competitor is also more likely to cut prices, and your team is more likely to lose morale. Treating these as independent chance nodes underestimates the probability of cascading bad outcomes. | Scenario Planning to define coherent future states; Causal Loop Diagrams to map correlations between uncertainties |
| EV maximisation in the presence of ruin risk | Expected value is an average across outcomes. If one branch leads to bankruptcy and it has a 15% probability, the EV calculation might still recommend that path if the upside is large enough. But you only get one run at company survival. EV-maximising logic is correct for repeated bets; it can be catastrophic for one-shot decisions where the downside is existential. | Regret Minimisation Framework for decisions with asymmetric, irreversible downsides; apply a minimum-threshold constraint before running the EV calculation |
| Exponential branch explosion | Each additional level of branching multiplies the number of terminal nodes. A tree with 3 options, each facing 3 outcomes, followed by 2 more decisions with 2 outcomes each, has 108 terminal nodes. The tree becomes unreadable, the probability estimates become increasingly speculative, and the analytical overhead exceeds the decision's importance. | Limit to 2–3 levels of branching; use Issue Trees to simplify the problem structure before building the decision tree |
The most dangerous failure mode is false precision masking genuine uncertainty. The decision tree's greatest strength — converting ambiguity into numbers — is also its greatest vulnerability. Once probabilities and payoffs are written on a whiteboard, they acquire a solidity they don't deserve. The team debates whether the probability of successful integration is 0.50 or 0.55, as if that distinction were meaningful, while ignoring the possibility that the entire framing is wrong — that the real risk isn't integration failure but market timing, a variable they never put on the tree at all.
The protection is twofold. First, always run the sensitivity analysis. Identify the two or three inputs that, if wrong, would change the decision. Those are your "value of information" targets — the places where spending money to reduce uncertainty has the highest return. Second, treat the tree's output as a conversation starter, not a verdict. The number at the root node is less important than the structure of the tree itself, which makes explicit every assumption, every probability estimate, and every payoff judgment that the team is collectively making. The tree's real product is transparency, not a number.
Section 5
Visual Explanation
Decision tree for the SaaS AI feature decision. Square nodes = decisions you control. Circular nodes = uncertain outcomes. Terminal values in bold. Expected values shown at each node, calculated via backward induction. The optimal path (License) is highlighted.
Section 6
Pairs With
The decision tree handles the arithmetic of sequential choice under uncertainty. It does not generate options, challenge assumptions, or account for emotional and organisational realities. Pair it deliberately.
Use before
Issue Trees
Before you can build a decision tree, you need to know what you're deciding between. Issue trees decompose a strategic question into its constituent parts, surfacing the real options. A decision tree built on an incomplete set of alternatives is optimising within the wrong frame. Issue trees prevent that.
Use before
Scenario Planning
Scenario planning identifies the two or three macro-uncertainties that define your operating environment. These become the chance nodes in your decision tree. Without scenario planning, teams default to "things go well" and "things go badly" — binary and vague. Scenario planning gives the chance nodes specificity and narrative coherence.
Use after
Pre-Mortem
The tree tells you the optimal path. The pre-mortem asks: "Assume we took that path and it failed catastrophically. Why?" This surfaces risks the tree's structure may have missed — correlated failures, implementation risks, political obstacles — that don't show up as probability-weighted branches but can kill the strategy anyway.
Use after
Reversible vs. Irreversible Decisions
If the tree's top two options have similar EVs, the tiebreaker is often reversibility. The option that preserves more future optionality — that lets you change course if early signals are bad — is worth a modest EV discount. This framework makes that tradeoff explicit.
Mental model
Second-Order Thinking
Decision trees naturally encode second-order effects — the consequences of consequences. But only if you build enough levels. Second-order thinking as a mental discipline pushes you to ask "and then what?" at each terminal node, often revealing that what looked like an endpoint is actually a branching point that belongs in the tree.
Mental model
[Cost](/mental-models/cost)-Benefit Analysis
CBA and decision trees are cousins. CBA works for single-stage decisions with known costs and benefits. When the decision is sequential — when what you learn or what happens after the first choice changes the next choice — the decision tree is CBA with time and contingency built in. Use CBA for the simple calls. Graduate to the tree when the decision branches.
Section 7
Real-World Application
Genentech — pricing the option value of a drug development pipeline
The scenario
Pharmaceutical development is the canonical domain for decision trees, and Genentech's approach to its oncology pipeline in the early 2000s illustrates why. The company faced a recurring strategic question: at each stage of clinical trials (Phase I, II, III), should it continue investing in a drug candidate, license it out to a larger pharma company, or kill it? Each decision point involved tens of millions of dollars, and the uncertainties — clinical efficacy, FDA approval probability, market size, competitive timing — were nested and sequential. A drug that clears Phase II still faces a roughly 50% chance of failing Phase III. A drug that clears Phase III still faces pricing and reimbursement uncertainty.
How the tool appliedGenentech's portfolio management team built decision trees for each major pipeline candidate, with decision nodes at each trial phase (continue/license/kill) and chance nodes for clinical success, regulatory approval, and commercial uptake. The probabilities were drawn from industry base rates — historically, about 63% of oncology drugs entering Phase III fail — adjusted for molecule-specific data from earlier trial phases. Payoffs at terminal nodes reflected net present value of projected revenue streams minus remaining development costs, with different values depending on whether Genentech retained full rights or had licensed the compound.
What it surfacedThe critical insight wasn't about any single drug. It was about the portfolio. When Genentech's leadership looked at the trees side by side, they could see that several candidates with modest individual EVs collectively provided enormous option value — the right to make future decisions as information emerged. Killing a Phase II candidate with a $30M negative EV in isolation looked rational. But that candidate's Phase II data, if positive, would unlock a Phase III decision with a potential $800M payoff. The tree made visible what intuition obscured: the value of continuing wasn't the drug's current expected value but the option to learn and decide again. This insight directly influenced Genentech's decision to maintain a broader pipeline than pure EV-per-candidate analysis would have recommended.
The non-obvious factorWhat distinguished Genentech's use of decision trees from textbook application was their treatment of probability updates. After each trial phase, the team didn't just proceed to the next decision node — they revised the probabilities on all downstream chance nodes using Bayesian updating based on the actual trial data. A Phase II result that showed efficacy at the 90th percentile of expectations didn't just mean "proceed to Phase III." It meant the Phase III success probability should be revised upward from the base rate. This dynamic recalibration turned the decision tree from a static planning tool into a living decision system that got smarter as information accumulated. Most organisations build the tree once and execute it. Genentech rebuilt it at every node.
Section 8
Analyst's Take
Faster Than Normal — Editorial View
The decision tree is one of the few analytical tools that is simultaneously underused and overrated. Underused because most founders and operators never build one — they make sequential decisions under uncertainty using narrative reasoning, gut feel, and whatever scenario is most vivid in their mind at the time. Overrated because the people who do build them often treat the output as more precise than the inputs warrant. The tree's math is exact. The numbers feeding it are not. That gap is where bad decisions hide.
The failure mode I see most frequently isn't technical — it's structural. Teams build trees that are too shallow. They model the first decision and its immediate uncertain outcome, calculate an EV, and stop. But the tree's real power emerges at the second and third levels, where the interaction between your choices and the world's responses creates paths you wouldn't have considered through forward reasoning alone. A two-level tree is barely more useful than a pros-and-cons list. Three levels is where the tool starts earning its keep. The discipline is to keep asking "and then what happens, and what would I do?" until you've captured the decisions that actually determine long-term value. Most of the time, the first decision matters less than the contingent decisions that follow it — and those contingent decisions are invisible without the tree.
The highest-leverage modification: build the tree collaboratively, but assign probabilities individually. Have each team member independently estimate the probability at every chance node before anyone shares. Then display the estimates side by side. The disagreements are the most valuable output of the entire exercise. When your CTO assigns a 0.70 probability to on-time delivery and your VP of Engineering assigns 0.35, you haven't found a number — you've found a conversation that needs to happen before any strategy is chosen. The tree becomes a disagreement-detection machine, and that function alone justifies the time investment. Consensus probabilities are often wrong. Visible disagreement about probabilities is almost always useful.
Section 9
Top Resources
01
Decision Analysis and Behavioral Research — Howard Raiffa (1968)
Primary sourceThe foundational text. Raiffa, who co-developed the modern decision tree framework at Harvard Business School, lays out the full theory: structuring sequential decisions, assigning utilities, incorporating risk preferences, and computing optimal strategies via backward induction. Dense and academic, but every serious practitioner should read at least the first five chapters. This is where the tool was born.
02
Book
Essential context for understanding why the decision tree is necessary. Kahneman's work on prospect theory, base rate neglect, and the planning fallacy explains exactly the cognitive failures that decision trees are designed to correct. Chapter 24 on "The Engine of Capitalism" is particularly relevant — it documents how entrepreneurs systematically overestimate success probabilities, precisely the bias that forcing explicit probability estimates is meant to counteract.
03
Book
Lafley and Martin's strategy framework at Procter & Gamble used decision-tree logic implicitly throughout their "strategy choice cascade." The book demonstrates how large organisations can structure sequential strategic choices — where to play, how to win — with explicit consideration of competitive responses and market uncertainties. Read this for the organisational application of tree-structured thinking, even though they never draw a formal tree.
04
Book
Thorndike profiles eight CEOs who were exceptional capital allocators — and capital allocation is fundamentally a decision-tree problem. Each investment decision branches into uncertain outcomes that trigger further allocation decisions. Henry Singleton at Teledyne and John Malone at TCI both made sequential, probability-weighted bets that only make sense when you see the full tree of contingent decisions they were implicitly computing. The book never uses the term "decision tree," but the thinking is unmistakable.
05
How to Measure Anything — Douglas Hubbard (2010)
BookThe practical companion to any decision tree exercise. Hubbard's core argument — that anything can be measured, and that even rough measurements dramatically improve decisions — directly addresses the most common objection to decision trees: "we can't estimate these probabilities." His calibration techniques for subjective probability estimation are the missing skill that makes decision trees actually work in practice rather than in textbooks.
Decision Tools Library — Browse by phase
Why this matters next
mental modelsSecond-Order Thinking
Issue Trees applied the Second-Order Thinking mental model
mental modelsLeverage
Issue Trees applied the Leverage mental model
mental modelsNarrative
Issue Trees applied the Narrative mental model
mental modelsIntelligence
Issue Trees applied the Intelligence mental model
mental modelsScale
Issue Trees applied the Scale mental model
mental modelsIntuition
Issue Trees applied the Intuition mental model
Continue exploring
DMSHCASP
Decision tool
Decision Matrix
Score options across weighted factors to identify a clear winner
Decision tool
Six Thinking Hats
Examine a decision from six cognitive perspectives — facts, emotions, risks, ben
Decision tool
Cost-Benefit Analysis
Quantify the economic trade-offs of each option to determine net value
Decision tool
Scenario Planning
Construct multiple plausible futures and test how each option performs across th
More like this, in your inbox
I send a newsletter every week — free, no spam, unsubscribe anytime.