Decision Tree Framework: Consulting Template and Example

Learn when to use a decision tree framework in case interviews, how to build one, what questions to ask, and how to practice the structure.

Updated Jun 10, 2026. Reviewed by Ned.

A decision tree framework helps you solve a consulting case when the client must choose between alternative actions under uncertainty. Start with the decision the client needs to make, branch into mutually exclusive options, map the uncertain outcomes that could follow, then name the data that would prove which path is best. In interviews, the value is not the diagram itself. The value is showing that you can make tradeoffs explicit, avoid overlapping logic, and move from uncertainty to a testable recommendation. That is why a decision tree belongs in your case interview structure toolkit, but only for the right type of prompt. It works best when the client is deciding whether to launch, wait, invest, enter, pilot, expand, or exit. If the case is still asking why performance changed, diagnose the drivers before you compare choices.

For a broader distinction between memorized labels and useful structure, read case structure versus case framework. To see where decision trees fit alongside issue trees, MECE** structures, and driver trees in the full case toolkit, the case interview frameworks complete guide provides the selector logic. When a decision involves weighing costs against uncertain benefits, the cost-benefit analysis framework applies similar go/no-go logic in a more quantified format.

What a decision tree framework means in a case interview

A consulting decision tree starts with a decision node: the client choice you are helping make. From there, each branch represents a path the client could control, such as launch now, pilot first, wait, enter a smaller segment, or stop the initiative. Under each branch, chance nodes represent uncertain outcomes that could change the answer: demand might be strong or weak, costs might scale or break, competitors might respond aggressively, or execution might be harder than expected.

For the basic anatomy, IBM's overview of decision trees is useful context, but the case interview version is simpler: use the tree to make the client's choice, uncertainty, and next test visible.

The endpoint is not a pretty diagram. The endpoint is a recommendation path. If branch A has attractive demand, manageable risk, and execution capability, it may support moving forward. If branch B has a worse downside profile or depends on assumptions the client cannot verify, it may fall away.

This is different from an issue tree. An issue tree breaks a problem into causes or topics to investigate. A decision tree compares choices after the decision is clear. A driver tree is even more diagnostic: it breaks a metric, such as profit or revenue, into drivers before deciding what to do.

When to use it instead of an issue tree

Use a decision tree when the case prompt sounds like a choice. Common signals include: Should the client enter this market? Should it launch a new offer? Should it invest in capacity? Should it change price? Should it acquire, partner, pilot, delay, or exit? These prompts need options, uncertainty, and a recommendation.

Do not use it as your opening move when the case is still diagnostic. If the prompt says profits are declining, customers are churning, operations are failing, or growth has slowed, you usually need to understand the issue before recommending a path. A profitability case interview guide starts with revenue and cost drivers for exactly that reason.

The clean rule is this: if you do not yet know what decision the client is making, start with an issue tree. If the client already has choices on the table, use a decision tree to compare them. In both cases, keep your branches separate enough and complete enough to be useful. The MECE framework matters here because overlapping branches make the recommendation weaker.

Decision tree template: nodes, branches, tests, and recommendation

A practical decision tree does not need a complex visual. In an interview, a simple table is often clearer because it forces you to connect each branch to an assumption and a next test.

A strong spoken opening can sound like this: I would clarify the decision we are making, separate the options the client controls, then test the uncertainties that would change the recommendation. I would prioritize the branch with the largest strategic upside and the most decision-relevant uncertainty.

That last sentence matters. Treating every branch equally makes the structure slow. Prioritize the branch where the answer could swing the recommendation.

If you need to turn this from a table into spoken case structure, practice the conversion before you do full mocks.

Build decision trees under case pressure

Use the free structure drill to turn an ambiguous prompt into branches, tests, and a prioritized next step.

Start the structure drill

Worked example: launch, delay, or test a new offer

Imagine a client is considering a new premium offer in a market it already serves. The decision is not why the current business is underperforming. The decision is whether to launch now, pilot first, delay, or stop.

A candidate could structure it this way: I would compare the paths the client can control, then test demand, economics, execution capability, and strategic risk under each path. If launch now has strong demand, attractive economics, and manageable delivery risk, I would lean toward speed. If demand is uncertain but the downside is contained, I would test through a pilot. If execution constraints are severe or the offer distracts from a stronger core opportunity, I would delay or stop.

The next data request should be tied to the branch that matters most. For launch now, ask for customer evidence, margin logic, operational readiness, and likely competitive response. For pilot first, ask what the pilot must prove and what decision would follow. For delay, ask what would need to change before the client reconsiders.

This style fits naturally in a market entry case interview guide, because market entry is often a choice between enter, test, partner, wait, or walk away.

Worked numerical example: comparing paths by expected value

When the interviewer hands you probabilities and payoffs, the same tree becomes quantitative. Each branch ends in chance nodes, and the expected value of a branch is the sum of (probability of each outcome) times (its payoff).

Suppose the interviewer gives you these numbers for the same premium offer:

The expected value of each path is the sum of its contributions:

• Launch now: ($6.0M) + (-$1.6M) = +$4.4M

• Pilot first: ($3.0M) + (-$0.5M) = +$2.5M

• Wait: $0

On expected value alone, launch now leads. But state the caveat out loud: launch now also carries the only meaningful downside (-$4M at 40% probability), while the pilot caps the loss at -$1M. If the client is loss-averse or capital-constrained, the pilot's lower expected value can still be the better choice because it buys information and limits the downside. The number narrows the decision; it does not replace the judgment.

Two disciplines matter here. First, do not invent probabilities or payoffs the interviewer did not give you. Ask for them, and if they are unavailable, keep the recommendation qualitative. Second, sense-check the inputs: a 60% chance of strong demand is an assumption worth pressure-testing before you anchor a recommendation on it.

Questions to ask before choosing the initial branch

Before you branch, make sure you know what decision you are actually solving. Good clarifying questions are practical, not decorative.

Ask: What is the client's objective? Who owns the decision? What constraints matter most? Is the opportunity time-sensitive? Is the choice reversible? What is the main downside if we are wrong? What data is available now? What uncertainty would most change the recommendation?

Those questions prevent over-branching. A weak candidate creates a branch for every topic that comes to mind. A strong candidate branches around the choices the client controls, then uses chance nodes only where uncertainty affects the final answer.

You also need to know when expected value matters. If the interviewer gives probabilities, payoffs, or cost ranges, you can compare paths through expected value logic. If those inputs are missing, do not invent them. Explain what you would need to estimate the value of each path and keep the recommendation qualitative until the interviewer provides the facts.

Mistakes that make a decision tree weak

The most common mistake is using decision-tree language when the case is actually diagnostic. If profits fell and you immediately branch into fix options, the interviewer may see that you skipped root cause. Diagnose first, then decide.

Another mistake is overlapping branches. If one branch is improve pricing and another is improve margins, the logic may collide. Better phrasing is: I would separate the controllable options into price change, product mix change, cost action, or no action, then test which path creates the best tradeoff.

Fake precision is also a problem. Starting with probabilities too early can make the structure sound technical but unsupported. Better phrasing is: I would only assign probabilities after we have evidence on demand, execution risk, and competitor response.

A final mistake is building a tree that never reaches a recommendation. Every branch should answer: if this is true, what would we recommend? If the implication is unclear, the branch is probably a topic, not a decision path.

Practice drill: build a decision tree under interview pressure

Use this drill when you want the framework to become automatic. Take a choice-based prompt, then state the client decision in plain English. Branch only by options the client controls. Under each branch, name the uncertainty that would change the answer. Then ask for the data that would test the highest-leverage assumption and give a recommendation based on the evidence you have.

Interactive drill set. Write an answer before revealing the worked solution, then continue into CoachNed for scored practice and AI feedback.

The structure is working if another person can follow your logic without seeing your notes. Then move into a full case so the tree has to survive exhibits, pushback, and synthesis.

Once your branches are clear on paper, the next step is testing whether you can defend them live.

Test the structure in a full case

Run a free AI-guided case and see whether your branches, data requests, and recommendation hold together live.

Practice a free case

Sources and Further Reading (checked 2026-05-30)

• McKinsey & Company - Interviewing at McKinsey

• Boston Consulting Group - Consulting Interview Process

• Bain & Company - Interviewing

• IBM - What is a Decision Tree?

• Lucidchart - What is a Decision Tree Diagram

• Atlassian - What is a decision tree, and how do you create one?

• Yale Office of Career Strategy - Consulting