Decision Tree Analysis Example for a Launch-or-Wait Call

A decision tree analysis example is easiest to learn from a real choice: you lay out each option, map the uncertain events that follow, put a rough probability and a dollar value on each outcome, and compare the expected value of each path. You do not need clean data. You need honest ranges, a willingness to see which assumptions the answer depends on, and about an hour.

This article builds one from scratch for a launch-or-wait decision, using numbers a small team could actually produce in a meeting.

The situation

Picture a 14-person company selling project management software to contractors, at about $3.2M in annual recurring revenue. The team has built a change-order tool that is roughly 80% done. The product lead wants to ship it in six weeks as it stands. The engineering lead wants four more months to finish a QuickBooks integration and polish the rough edges.

Both have good arguments, and that is the problem. Meetings on this kind of question tend to turn into a contest of confidence. A decision tree replaces that with a shared picture of what could happen and what each outcome is worth.

What a decision tree actually is

A decision tree has three parts:

• Decision nodes are choices you control. Launch now or wait.
• Chance nodes are events you do not control. Customers love it or ignore it, a competitor ships or does not.
• Leaves are the end outcomes, each with a value attached.

You read it from left to right and calculate from right to left. At each chance node you multiply every outcome's value by its probability and add the results. That sum is the expected value of that branch. At the decision node you compare branches and pick the best.

That is all of it. The skill is in choosing sensible branches and being honest about the numbers.

Step-by-step: build the tree

Step 1: State the decision and the time window

Write one sentence: "Should we launch the change-order tool in six weeks as it stands, or wait four months and launch with the QuickBooks integration?"

Then pick one measurement window. We will use net value over the next 12 months, meaning incremental revenue minus incremental costs, including the remaining build cost. Using one window for every branch keeps the comparison fair. If you skip this, the waiting option quietly gets credit for a better product and none of the penalty for lost months.

If you are not sure you have the right question yet, spend ten minutes on framing the problem first. A tree built on the wrong question gives a precise wrong answer.

Step 2: List the options, including a boring one

Start with the two on the table. Ask whether a third exists, such as launching to 20 beta customers only. We will come back to it, because it is where trees often end up pointing.

Step 3: Name the uncertain events that matter

Most decisions hinge on one or two uncertainties. Resist the urge to model everything. Here they are:

• Launch now: How do customers respond? Strong adoption, modest adoption, or a flop where bugs cause refunds and churn.
• Wait: Does a competitor ship a comparable feature during the four-month delay? Then, how do customers respond to our launch?

Notice that the competitor event only appears under "wait." That is deliberate. If a competitor ships either way, it belongs on both branches. Here the team judged that a competitor beating them to market matters mainly when they are not in market yet.

Step 4: Put rough probabilities on each branch

Do not debate decimals. Have three people write down their estimates separately, then compare. If two say 30% and one says 50%, use the gap as a conversation, not an average to hide.

Anchor on base rates where you have them. This team had shipped five features in the last two years. Two got strong adoption, two got modest adoption, and one underperformed badly. That gives rough odds near 40/40/20 for a typical launch. They shaded the strong case down to 30% because this launch would go out unpolished, and shaded the flop case up to 25%.

For the competitor, the sales team had heard rumors from two prospects and seen one job posting. They settled on a 35% chance of a comparable release within four months.

Step 5: Put a dollar value on every leaf

Estimate each leaf as net 12-month value. For launch now:

• Strong adoption: about 120 paying accounts at roughly $350 a month in the first year, with some ramp, less support and hosting costs and the remaining $40k of development. Net: +$400k.
• Modest adoption: roughly a third of that. Net: +$150k.
• Flop: refunds, two existing accounts lost, and a month of engineering time on cleanup. Net: -$60k.

For waiting, every outcome loses four months of revenue and carries about $90k of extra development cost. If a competitor ships first, the strong and modest outcomes shrink further because the feature is no longer a differentiator.

Step 6: Calculate expected values

Here is the full tree in one table. Joint probability is the chance of reaching that leaf from today.

Launching now comes out ahead by roughly $33k in expected value. That is a modest edge on a $150k-ish swing, so the margin is not what matters. What matters is the next step.

Stress-test the answer

A tree with guessed inputs is only useful if you check how fragile the conclusion is. Change one assumption at a time and find the break-even point.

The competitor probability. The wait branch is worth $187.5k if no competitor ships and $48.5k if one does. Its overall value falls as the competitor risk rises. Waiting beats launching now only if the chance of a competitor shipping is below about 11%. The team believed 35%, and nobody in the room argued it was under 11%. So this assumption is not close to flipping the result.

The flop rate for launching now. Hold strong adoption at 30% and push probability from "modest" into "flop." Waiting wins only once the flop probability climbs past roughly 41%. The team had said 25%. For waiting to be right, you must believe that the unpolished launch fails nearly twice as often as your own history suggests.

That is the real output of the exercise. The question changed from "which option feels safer?" to "do we believe the rough product has a better than 4 in 10 chance of flopping?" That is a question people can answer with evidence, such as beta feedback and support load on similar features.

What the tree told this team to do

Launch now beat waiting under reasonable assumptions, and it kept winning when the inputs moved. But the flop branch was the ugliest leaf, and it was cheap to shrink. The team chose a version of the third option: ship in six weeks to existing customers who opted in, cap it at around 40 accounts, and hold the public announcement until two weeks of support data came in.

That choice follows the logic in reversible vs irreversible decisions. A capped launch can be pulled back. A full public launch of a buggy tool, with a big announcement, cannot be un-announced. Cutting the flop probability from 25% to something like 15% by limiting exposure is worth more than any amount of fine-tuning the other numbers.

If you want to compare this to how timing plays out strategically, first mover vs fast follower covers when being early pays and when it just means being the one who finds the bugs.

Common mistakes

Mistake 1: False precision

Writing "37.5%" does not make a guess better. It makes people defend the decimal instead of the logic. Use round numbers in 5% steps and spend your effort on sensitivity checks. If a conclusion survives moving every probability by 10 points either way, you can trust it. If it flips, you have learned that the decision is a close call and that more information is worth buying.

Mistake 2: Leaving the cost of waiting off the tree

Teams love the "wait" branch because it feels free. It never is. In this example, waiting cost four months of revenue, $90k in extra development, and a 35% chance of losing the differentiator. Always put the delay on the tree as a real cost, not a footnote.

Mistake 3: Tuning the numbers to reach the answer you already want

This happens quietly. Someone nudges the strong-adoption odds up "because the demo went well," and the tree now agrees with their gut. Guard against it by setting probabilities before anyone calculates totals, and by having someone who prefers the other option review the inputs. Our guide to cognitive biases that hurt business decisions covers the usual suspects, including overconfidence and anchoring.

Mistake 4: Treating expected value as a promise

A $172k expected value does not mean you will make $172k. In this tree, 25% of the time you lose money. If the company could not survive a $60k loss, you would weigh that branch much more heavily, even though the average looks good. The tree shows the spread, so look at the worst leaf and ask whether you can live with it.

Mistake 5: Building a tree too big to check

Three options, two uncertain events and three outcomes each is plenty. Once the tree has 40 leaves, nobody can sanity-check it, and errors hide in the branches.

Template

Copy this outline into a doc and fill it in before your next meeting:

• Decision: one sentence, with the options.
• Time window: the period you measure value over (for example, next 12 months).
• Options: A, B, and a cautious variant of each if one exists.
• Key uncertainties: one or two events that most affect the outcome.
• Outcomes per uncertainty: three at most (strong, modest, weak).
• Probabilities: written independently by at least two people, then reconciled. Must sum to 100% at each chance node.
• Value of each leaf: net dollars (or hours) over the window, including build cost and cost of delay.
• Expected value per option: sum of probability times value.
• Break-even checks: how far must the two shakiest probabilities move to flip the answer?
• Worst leaf: what is the downside, and can we survive it?
• Decision and review date: what we chose, and when we will compare results with our estimates.

That last line matters. Record the tree and your estimates in a decision log so that in six months you can see whether your 30% events happen about 30% of the time. Over a few decisions, your probabilities get noticeably better.

Key takeaways

• A decision tree turns a debate about confidence into a set of specific, checkable estimates, and rough probabilities are enough to make it useful.
• Measure every branch over the same time window, and always count the cost of waiting as a real number.
• Run a break-even check on your two least certain inputs. The question "how wrong can I be before the answer changes?" is more valuable than the expected value itself.
• Look at the worst leaf, not just the average. If you cannot survive it, redesign the option to shrink it, as the capped beta did here.
• Set probabilities before totals are calculated, and have a skeptic review them, so the tree does not just echo what you already wanted.
• Log the tree and your estimates, then compare them with what happened.