Updated October 2026. By Dr. Florian Smeritschnig, former McKinsey Senior Consultant
An issue tree is a diagram that breaks one question into smaller, non-overlapping sub-questions, layer by layer, until each branch is small enough to answer with a single analysis. Consultants at McKinsey, BCG, and Bain use issue trees to split up client work and to structure case interviews. There are three main kinds. A why tree finds the cause of a problem, a how tree lists ways to fix it, and a hypothesis tree tests an answer you already suspect. “Logic tree” is the umbrella name for all three.
Most guides teach issue trees by handing you finished examples: a profitability tree, a market entry tree, an M&A tree. That feels efficient. It’s also why so many candidates draw a tree that looks right and still can’t crack the case, because a tree copied from someone else’s problem answers someone else’s question.
I spent 5 years at McKinsey, where I evaluated candidates, and since 2020 I’ve delivered 2,300+ case interviews and coaching sessions. This guide shows you how to build an issue tree from the question in front of you. You’ll get the three types and when to use each, a six-step build method with a simple test for when a branch is finished, one practice problem worked three ways, and what to do with the tree once the case gets going.
If you’d rather learn structuring with video lessons from the ground up, StrategyCase’s free Case Interview Foundations course starts there.
Key Takeaways
- An issue tree splits one question into sub-questions until every end point can be answered with one analysis or one data request. If you can’t name the data, that branch isn’t finished.
- The question picks the tree: a why tree for “why is this happening?”, a how tree for “how do we fix it?”, and a hypothesis tree when you already have a likely answer to test.
- Use one way of cutting per level (an equation, a process, segments, or components), and check that each split is MECE before you go a level deeper.
- Size isn’t quality. Go two or three levels deep only where the answer probably sits, then say which branch you’d test first and why.
- Don’t memorize issue tree examples. McKinsey’s own interview guidance asks for tailored solutions rather than standard frameworks, so the method is what carries over. From my own experience, candidates with memorized issue trees were rejected almost immediately.
What Is an Issue Tree?
Issue tree (definition): A visual breakdown of one question into sub-questions that branch out to the right or downward. Each split is mutually exclusive and collectively exhaustive (MECE): no overlaps, no gaps. The tree is finished when every end point, called a leaf, can be answered with a single analysis.
Every issue tree has three parts:
- Root: the one question the tree answers. Everything below it exists to answer it.
- Branches: the sub-questions. Each level splits the level above it using one logic.
- Leaves: the end points. A good leaf names something you could go and measure.
This isn’t an interview-only device. In a McKinsey Podcast episode on the firm’s seven-step problem-solving method, former McKinsey partner Charles Conn describes step two as using logic trees to take a problem apart, and explains that the pieces then get assigned to team members. The same episode notes that McKinsey tests for problem solving when it recruits. So the tree you draw in a case is a small version of how a real engagement gets organized.
If you’ve read about case structures, you’ve already seen issue trees. The opening structure you present in a case is one. This guide covers the tree itself: how to build it at any level, and how to work through it once the case starts. For another perspective on that opening structure, see our guide to case interview frameworks.
The 3 Types of Issue Trees and When to Use Each
The question in front of you picks the type. Here they are side by side, using the practice problem worked out in full further down (a city bike-share scheme whose rides per bike have dropped).
| Type | Root question | What it’s for | Example root |
|---|---|---|---|
| Why tree (diagnostic, also called a problem tree) | “Why is this happening?” | Finding root causes | “Why have rides per bike fallen?” |
| How tree (solution tree) | “How can we achieve this?” | Generating and sorting options | “How can we raise rides per bike again?” |
| Hypothesis tree | A claim you want to test | Confirming or killing a likely answer fast | “Rides fell mainly because fewer bikes are usable.” |
Why trees and how trees
Former strategy consultant Arnaud Chevallier draws this line in Strategic Thinking in Complex Problem Solving (Oxford University Press, 2016): diagnostic trees answer a “why” question, and solution trees answer a “how” question. A why tree ends in causes you can confirm or rule out with data. A how tree ends in actions someone could take.
In a case they often run back to back. You diagnose with a why tree, then switch to a how tree when the interviewer asks what the client should do. A how tree is really brainstorming in a case interview with structure imposed on it, which is why it beats a list of ideas.
Issue tree vs. hypothesis tree
An issue tree asks questions. A hypothesis tree makes claims. In a hypothesis tree, the root is your best guess at the answer, and each branch is a sub-claim that has to be true for the root to hold. You attach a test to each branch: the data that would prove it wrong.
That makes hypothesis trees faster when you have a strong starting view, and riskier when you don’t. If the root guess is wrong, the whole tree points at the wrong place. It’s the tool behind the answer-first approach Bain is known for.
A practical rule: start with a hypothesis tree when the prompt and your first data point toward one cause. Start with an issue tree when you can’t yet rank the possibilities.
What about logic trees and decision trees?
“Logic tree” is the umbrella term, and it’s the one McKinsey’s podcast uses for this whole family. Search for it and you’ll also find truth trees from formal logic and fault trees from engineering. Those are different tools with the same name.
A decision tree maps choices and their possible outcomes, often with probabilities, so you can compare options such as launching, licensing, or waiting. You might draw one at the bottom of a how tree once you’re down to two or three real options. It doesn’t replace the issue tree that got you there.
How to Build an Issue Tree in 6 Steps
These six steps work at every level of the tree, not only at the top. The fifth step, the leaf test, is what turns a neat diagram into something you can actually work through.
1. Write the root as a question someone has to act on
A vague root produces a vague tree. “Bike-share performance” is a topic. “Why have rides per bike fallen by a third in 12 months, and what should the city do about it?” is a question with a metric, a time frame, and a decision-maker.
McKinsey senior partner Hugo Sarrazin makes the same point in that podcast. Teams spend a long time on the problem statement alone, because people often arrive at the first meeting with quite different views of what they’re there to solve.
A pattern I see in first sessions: a candidate has done dozens of practice cases with peers, and the feedback keeps coming back as “not MECE.” The structure isn’t the root problem. They generate categories before clarifying the decision the client actually needs to make, so every structure looks reasonable and none of them answers the question.
2. Pick one cut for the level
A cut is the logic you use to split a node. Four cover most problems:
- Equation: split a metric into its math. Rides per bike = share of bikes usable × rides per usable bike.
- Process: split along steps in order. Find a bike, unlock it, ride, return it.
- Segments: split a population. Commuters vs. leisure riders, central vs. outer stations.
- Components: split a system into its parts. Bikes, docks, the app, the repair depot.
Use one cut per level. Putting “commuters” next to “broken bikes” on the same level is the most common reason trees overlap and leave gaps. When the root contains a number, start with the equation: if the math is right, the split is MECE by construction.
3. Check that each split is MECE
At every node, ask two questions:
- Could anything belong in two branches? That’s an overlap.
- Does anything belong in none? That’s a gap.
An equation passes if the math holds. Segments pass if they add up to the whole population. Our guide on how to be MECE in a case interview covers the test in detail.
4. Go deeper only where it matters
Two or three levels is plenty for a 30-minute case. Go deep on the branches where you suspect the answer sits.
5. Run the leaf test
For every leaf, finish this sentence: “To answer this, I’d look at ___.” If you can name a specific number, comparison, or data request, the leaf is done. If you can only name a topic, split it again or cut it.
| Leaf that fails | The same leaf, passing |
|---|---|
| “Bike quality” | “Share of the fleet out of service each week, this year vs. last” |
| “Customer behavior” | “Trips per active member per month, by segment” |
| “Competition” | “E-scooter trips in the same zones since they launched” |
The leaf test turns the tree into a work plan. Every passing leaf is an analysis you can request in a case or hand to a teammate on a project.
6. Prioritize, and say where you’d start
Branches don’t deserve equal attention. Conn describes using this on a far bigger problem. At the Moore Foundation, Gordon Moore asked his team how to save Pacific salmon. They broke the problem down, then asked of each branch how big a lever it was and whether they could actually move it. Ocean conditions mattered a lot but couldn’t be changed, so the work focused on fish habitats and harvesting practices instead.
Sarrazin’s version of the rule is worth remembering: “They don’t have equal weight just because they’ve got equal space on the page.” In a case, name the branch you’d test first and give the reason. Usually that’s a mix of how much it could explain and how quickly data can confirm or kill it.
Issue Tree Example: One Problem, Three Trees
Here’s a practice prompt. I made it up for this guide, so none of the numbers describe a real city:
A mid-sized city runs a docked bike-share scheme. The fleet hasn’t changed in size, but over the past 12 months, rides per bike per day have fallen by about a third. The city’s transport authority wants to know why, and what to do about it.
I picked it on purpose. There’s no standard bike-share structure to recall, so you have to build from the question. Below is the same prompt as a why tree, a how tree, and a hypothesis tree.
The why tree: what caused the drop?
Root: Why have rides per bike per day fallen by about a third?
- A. Fewer of the bikes are usable
- A1. More bikes are in repair: more breakdowns, or slower repairs
- A2. More bikes are gone for good: theft and vandalism
- B. Each usable bike gets ridden less
- B1. Riders want fewer trips: fewer riders, or fewer trips per rider
- B2. Fewer of the wanted trips happen: no bike at the start, or no free dock at the end
Each leaf passes the leaf test, because each one names its data:
- A1: the weekly out-of-service share and the average days a bike spends in repair
- A2: bikes written off per month
- B1: active members, casual users, and trips per member
- B2: app searches that ended without an unlock, plus the hours stations spend completely empty or full
Look at what the first cut does. Because it’s an equation (rides per bike = usable share × rides per usable bike), the tree is MECE without any extra effort, and the first split already tells you who to talk to: the operations team for A, the demand side for B. Conn makes a similar point in the podcast: the way you take a problem apart often hints at the answer early.
Important note: just because a tree is MECE does not mean that there are no interdependencies. For instance, if no bikes are available or there are waiting/unproductive times for riders, fewer trips are started or desired.
The how tree: what could the city do?
Root: How can the city get rides per bike back to last year’s level within 12 months?
- Get more bikes usable
- Repair faster: more mechanic hours, spare parts on hand
- Lose fewer bikes: better locks, GPS tags on the fleet
- Get more rides from each usable bike
- Raise demand: passes and pricing, employer and university partnerships, links to train and bus stations
- Serve the demand that’s already there: move bikes toward busy stations at peak times, add docks where stations fill up
The how tree mirrors the why tree’s first level. Once the diagnosis tells you which branch caused the drop, you build most of the how tree under that branch and keep the rest brief.
The hypothesis tree: testing the likely answer
Now say the interviewer’s first data point is that far more of the fleet sits in repair than a year ago. A hypothesis tree gets you to the answer faster.
Root hypothesis: Rides fell mainly because fewer bikes are usable, not because fewer people want to ride.
| Sub-hypothesis | What would prove it wrong |
|---|---|
| Usable bikes fell enough to explain most of the drop | Usable bikes fell by much less than a third, so the rest has to come from branch B |
| Demand held up | Active riders or trips per rider fell sharply |
| The cause is repair capacity, not a wave of breakdowns | Breakdowns per bike rose while repair times stayed flat |
The first branch is quick math. If 90% of the fleet was usable last year and 60% is usable now, usable bikes are down by a third (0.60 ÷ 0.90 ≈ 0.67). If rides per usable bike held steady, that alone would explain the whole drop, before you’ve looked at demand at all. Every branch carries a kill condition, so one or two data requests either confirm the answer or collapse it.
Why You Shouldn’t Memorize Issue Tree Examples
Most issue tree guides finish with a gallery: a profitability tree, a market entry tree, an M&A tree, a pricing tree. They’re useful for seeing what a finished tree looks like. As something to memorize, they’re the same trap as memorized frameworks, one level down.
McKinsey’s interviewing page is direct about this. It tells candidates there’s no single logical solution to a case and asks them to listen carefully and offer tailored solutions rather than standard frameworks. Look at its own practice cases: one asks whether a beauty company should train in-store consultants to use virtual channels, and another asks how the Diconsa store network in Mexico could offer basic financial services to the rural poor for the Gates Foundation. No stored tree fits either one.
What carries over between cases is the method: a sharp root question, one cut per level, a MECE check, the leaf test, and a clear priority. The bike-share tree above won’t help you in your next case. Having built it will.
Want reps on prompts that have no stock answer? StrategyCase’s Structuring for Frameworks and Brainstorming Course gives you unfamiliar prompts to build from scratch, so you practice the build instead of the recall (on top of a 7-hour video course on case interview structuring).
How to Use an Issue Tree in a Case Interview
Your opening structure is the top of the tree. What separates strong candidates is what they do with it over the next 20 minutes:
- Draw it so the interviewer can read it. Use a landscape page, put the root at the top or left, and keep labels short.
- Walk it top-down. Root first, then the cut you used (“I’ve split this into usable bikes and rides per usable bike”), then level one, then where you’d start and why. It’s the same top-down logic as the Pyramid Principle.
- Ask for data branch by branch. Every leaf that passed the leaf test is a ready-made data request.
- Cross off what the data rules out, and say so. “Repair share is flat, so I’m ruling out A1 and moving to A2.”
- Update the tree when the case changes. New information can add a branch or kill one. Changing the tree is fine. Ignoring data to protect it isn’t.
- Build the recommendation from the confirmed branches. Lead with the answer, give the two or three branches that support it, then name the next steps.
From the interviewer’s side of the table, the tree answers four questions quickly:
- Did you cover the whole problem?
- Did you go deep enough to be useful?
- Is there an insight in how you cut it?
- Do you know where to start, and why?
A tree that answers all four makes the rest of the case easier, because the interviewer can follow every move you make.
The firm changes how you use it, not whether. In McKinsey’s interviewer-led format, the interviewer often points you to a branch, and your tree shows you know where that branch sits in the whole problem. Our McKinsey case interview guide covers that format.
In candidate-led cases, which you’ll meet at BCG and Bain, the tree is your map for deciding what to ask next. And estimation questions are equation trees all the way down: a market sizing case is a math tree with a number at every leaf.
If you’re an experienced hire, you may already use trees at work. The adjustment is speed and size. A case gives you minutes, not weeks, so cut to two levels and commit to a priority sooner than feels comfortable.
Structuring is one of three skills a case tests. StrategyCase’s Case Interview Academy trains it alongside exhibit interpretation and case math, with video lessons and thousands of practice drills.
Issue Tree Template and Common Mistakes
The template
Use this as a checklist while you build, level by level:
| Level | What you write | Check before moving on |
|---|---|---|
| Root | One question with a metric, a time frame, and a decision-maker | Could someone act on the answer? |
| Level 1 | 2 to 4 branches from one cut: equation, process, segments, or components | MECE? Only one cut used? |
| Level 2 | Splits under the branches you suspect most | Same check, at every node |
| Leaves | “To answer this, I’d look at ___” | Can you name the data or the analysis? |
| Priority | The branch you’d test first, and why | Could it explain the most, and can you test it fast? |
4 issue tree mistakes and how to fix them
| Mistake | What it looks like | Fix |
|---|---|---|
| Generc topic labels | “Market”, “Operations”, “Competition” | Write each branch as a tailored topic |
| Mixed cuts on one level | “Commuters”, “Broken bikes”, and “Pricing” side by side | One cut per level; move the others down a level |
| Overlapping branches | Empty stations show up under both supply and demand | Re-cut with an equation, or define where each branch stops |
| Defending the tree | The data kills a branch and the candidate keeps working it | Cross it off out loud and move to the next priority |
How to Practice Building Issue Trees
You don’t need full cases to practice this. You need a steady supply of real questions and a way to check your trees:
- Use the news. A retailer’s sales drop, a delayed rail line, a hospital’s waiting list. Write the root, pick one cut, run the leaf test. Ten minutes each.
- Build the why tree and the how tree for the same problem, the way the bike-share example does. It trains the switch you’ll make mid-case.
- Cut one problem two or three ways. Conn says in the podcast that he likes to try two or three different cuts, because each shows a different angle on what might be going wrong. Compare which version points to the answer fastest.
- Time-box the top two levels to a couple of minutes, which is close to the pause you get in an interview.
- Have someone attack your tree. Ask them two questions: “What’s missing?” and “Why this cut?” Gaps are hard to see in your own work.
If your interview is less than two weeks away, skip the example galleries. Do a many root-plus-first-level drills a day on unfamiliar prompts, and save full cases for once your trees pass the leaf test without effort.
Frequently Asked Questions
What is a McKinsey issue tree?
McKinsey doesn’t publish an official template under that name. The term usually refers to the logic trees in step two of McKinsey’s seven-step problem-solving method, where a problem is broken into parts that can be prioritized and assigned to the team. In a McKinsey case interview, your structure is expected to work the same way.
Is an issue tree the same as a logic tree?
In consulting, yes. “Logic tree” is the broader name, and why trees, how trees, and hypothesis trees are all kinds of it. Outside consulting, the term can also mean a truth tree in formal logic or a fault tree in engineering.
Is an issue tree the same as a case interview framework?
They’re close relatives. A case framework is the opening structure you present. It goes down to leaves you can test with data, and through the whole case as you rule branches in or out.
How many branches and levels should an issue tree have?
For a case interview, aim for 2 to 4 branches per node and two or three levels, prioritizing only where you suspect the answer. Bigger trees can’t be worked through in 30 minutes, and smaller ones usually stop at topics instead of testable drivers.
Can I change my issue tree during a case interview?
Yes, and you should when the data rules a branch out or reveals a new one. Say what changed and why. Updating the tree shows judgment, while sticking with a tree the data has disproved shows the opposite.
What’s the difference between an issue tree and a decision tree?
An issue tree breaks a question into parts so you can find causes or options. A decision tree maps a choice and its possible outcomes, often with probabilities. Use the issue tree to reach a short list of options, and a decision tree to compare them.
Related Guides
- The complete case interview guide: where structuring fits among the skills a case tests
- Case interview math: working through the equation branches of your tree
- How to read charts and exhibits: what to do when a leaf’s data arrives as a chart
- Case interview examples: real prompts to practice building trees on
The Bottom Line
An issue tree is a simple idea that takes practice to do well: one question, split into sub-questions until every leaf can be answered with one analysis. The three types follow from the question. Use a why tree to diagnose, a how tree to find solutions, and a hypothesis tree when you already have a likely answer to test.
What makes a tree good isn’t its size or how closely it matches an example. It’s a sharp root, one cut per level, MECE splits, leaves that pass the leaf test, and a clear first priority. Those habits carry over to any case you’ll face, including the ones built so that no stored structure fits.
Build them on unfamiliar problems, get your trees challenged, and keep the examples for reference, not recall. Start StrategyCase’s free Case Interview Foundations course to build structuring, exhibit reading, and case math in the order they develop, then move on to the structuring drills when you’re ready for timed reps.
About the author: Dr. Florian Smeritschnig is the founder of StrategyCase.com and a former McKinsey Senior Consultant who evaluated candidates for the firm. Since 2020 he has delivered 2,300+ mock interviews and coaching sessions, and his clients have secured 700+ consulting offers, 340 of them at McKinsey, BCG, and Bain. He is the author of three books on consulting interviews and careers, including The 1%: Conquer Your Consulting Case Interview.
