Issue Trees: how to build problem trees

Issue trees. The tool that defines whether you pass or fail at Bain, McKinsey, BCG. Let me be direct: in my 13 years in consulting, evaluating 300+ interviews, I've seen candidates with excellent issue trees pass and candidates without them fail. The difference between a mediocre issue tree and an excellent one is the difference between a "maybe" and a clear yes from the partner.

What's interesting is that 75% of candidates use issue trees they memorized from books. 25% build their own, from scratch, designed for the specific case. That 25% has a much higher chance of passing. Not because their frameworks are perfect. But because they show that entienden how consulting works.

In this article, I'll teach you exactly what an issue tree is, why it works, how to build it from scratch, and how to avoid the mistakes 9 out of 10 candidates make.

Introduction: Why the Issue Tree Is Your Best Weapon in the Interview

When you enter a consulting case, the partner expects to see one thing: structured thinking. Not opinions. Not assumptions. Not "I think it's because..." Structured thinking.

The issue tree is exactly that. It's the tool that converts a chaotic problem into a logical tree where each branch answers a clear question: "What would have to be true for my hypothesis to be correct?"

I've seen brilliant candidates fail without an issue tree. I've seen mediocre candidates pass because their issue tree was specific, deep, and logical. The Bain partner doesn't seek genius. They seek structured thinking. They seek methodology.

The difference between issue tree and MECE framework is subtle but critical. MECE is the construction rule (Mutually Exclusive, Collectively Exhaustive). Issue tree is the practical application of that rule. A well-made issue tree is always MECE. But not every MECE framework is a good issue tree.

Why? Because the issue tree is designed for something specific: testing a hypothesis. Each branch, each sub-branch, exists to answer a question that gets you closer to the truth or farther from it.

In this article, I'll not only tell you what it is. I'll show you how to build issue trees that work in real interviews, with step-by-step examples, practical exercises, and the exact questions you'll ask yourself when you get it wrong.

What Is an Issue Tree: A Consultant's Mental Structure

An issue tree is a visual tool that breaks down a complex problem into smaller, manageable, logically related parts. Sounds simple. It is simple. But execution is what separates the best.

The structure is like this:

Hypothesis (the main problem) se divide en 2-4 ramas principales, cada una de las cuales se divide en sub-ramas, and so on until you get to specific questions you can test with data.

Simple visual example:

```

Why are the client's sales falling?

│

├─ Demand problem?

│ ├─ Fewer customers?

│ ├─ Fewer purchases per customer?

│ └─ Lower price?

│

├─ Supply problem?

│ ├─ Less production capacity?

│ ├─ Lower quality?

│ └─ Distribution problems?

│

└─ External factors?

├─ New competition?

├─ Regulatory change?

└─ Economic cycle?

```

Each branch answers: "What would need to be true to explain the problem?"

Lo clave es esto: It's not a list of topics. It's a logic tree. Each element connects to the previous one. Each deepens the question. The goal is to break down the complex until you find the specific you can test with data.

The Critical Errors: Where 9 Out of 10 Candidates Fail

He evaluado cientos de casos. Los errores son predecibles.

Error 1: Generic Issue Tree Without Hypothesis

Candidato llega a la entrevista y presenta esto:

```

Problema: Los ingresos bajaron

├─ Revenue

│ ├─ Precio

│ └─ Volumen

└─ Costs

├─ Fijos

└─ Variables

```

It's technically well-structured. But it's generic. It works for any revenue case. It has no hypothesis. The partner asks: "Why did you organize it that way?" and the candidate says "it's a standard framework." That kills the interview.

The right way is the opposite: start with a hypothesis based on the case data.

Error 2: Lack of Logical Structure

I've seen issue trees where the branches don't connect logically. For example:

```

Why did the margin fall?

├─ Ingresos

├─ Clientes

├─ Competencia

└─ Talento

```

Where's the logic? How do they relate? Is something missing? It's all fragmented. There's no clear direction.

An issue tree must have structure: first the macro (revenue vs. costs), then the meso (within revenue, what happened), then the micro (specific data). Like a funnel. From broad to specific.

Error 3: Branches That Don't Connect to the Case

Candidate memorizes an issue tree from a book and applies it to every case without adapting. The partner sees that immediately. It's like watching someone read a script without emotion. You know they're not thinking. Just repeating.

Example: A case about a retail chain's profitability. The candidate presents an issue tree about total market, organic vs. inorganic growth, etc. Technically sound. But the case doesn't mention inorganic. Doesn't fit. It's filler.

Error 4: Profundidad Insuficiente

I've seen issue trees that stop at level 2. Two levels of depth. That's not enough to test a real hypothesis. A good issue tree has 3-4 levels. At each level you dig deeper. At the lowest level, you have specific questions you can answer with data.

Error 5: No Comunicar Antes de Analizar

This is the biggest error. The candidate builds the issue tree mentally, then starts analyzing without showing the structure. The partner doesn't know where they're going. Halfway through the analysis, they ask "wait, where are you going?" and the candidate gets lost.

La regla de oro: Build the issue tree. Communicate it. Then analyze. En ese orden.

How to Build an Issue Tree: Step-by-Step Method

I've been building issue trees at Bain for 13 years. The method doesn't change.

Step 1: Understand the Case and Form a Hypothesis

Don't start with the tree. Start with the question.

Read the case twice. First read: capture information. Second read: what exactly is the problem? What do I know? What don't I know?

At Bain, in my evaluations, I always asked the candidate: "What's your initial hypothesis?" 30% answered correctly. 70% said "I don't have one" or presented a vague assumption.

A hypothesis is a specific proposal about what's happening. It's not "the client has a problem." It's: "The client's margin fell because the cost of serving new customers grew faster than the revenue from them."

Note the difference. Specific. Testable. Clear direction.

Step 2: Identify the Big Logical Divisions

This is where the tree starts. Not with small branches. With big divisions.

For a profitability problem: Revenue vs. Costs.

For a market problem: Supply vs. Demand.

For a strategy problem: Internal vs. External.

For a growth problem: Organic vs. Inorganic.

These divisions are the trunk of the tree. Everything else hangs from here.

Paso 3: Profundiza en Cada Rama Principal

Within each main branch, ask yourself: "What would need to be true within this category for my hypothesis to be correct?"

Ejemplo:

• ●If my hypothesis is "costs went up," then within Costs I need to ask:
• ●Did fixed costs increase?
• ●Did variable costs increase?
• ●Are there one-time costs impacting the period?

Cada pregunta es una sub-rama.

Step 4: Dig Deeper Once More

For each sub-branch, dig deeper: What specifically would cause this to be true?

Ejemplo:

• ●Si "Subieron los costes variables," entonces:
• ●Did they go up because we processed more transactions? (Volume up)
• ●Did they go up because the unit cost increased? (Cost per unit up)
• ●Did the transaction mix shift toward more expensive ones? (Mix shift)

Now you have questions you can work with. You can ask for data. You can test.

Step 5: Make Sure It's MECE

Antes de presentar, verifica:

• ●Do the branches at each level not overlap?
• ●Together do they cover everything important?
• ●Does each branch deepen the previous question?

Si hay solapamiento o brechas, corrige antes de la entrevista.

Mediocre vs. Excellent Issue Trees: Real Comparison

I'll show you a real case and how mediocre vs. excellent candidates handle it.

El Caso:

"Your client is a Spanish gym chain that has seen its operating margin fall from 18% to 11% over the last two years, despite membership growing 5%. What's happening?"

Mediocre Issue Tree (What 75% Does)

```

Why did the margin fall?

├─ Revenue

│ ├─ Precio

│ └─ Volumen

└─ Costs

├─ Fijos

└─ Variables

```

What's wrong?

• ●It's generic. Works for any profitability case.
• ●Doesn't connect to the specific case (low margin despite membership growth).
• ●No hypothesis. No direction.
• ●Es superficial. Dos niveles apenas.
• ●The candidate shows no thinking. Just memorization.

Excellent Issue Tree (What 25% Does)

Hypothesis: The margin fell because, even though membership grew 5%, the nuevos socios generan menor ingresos por unidad o requieren mayor costo de servicio. O ambos.

```

Why did the margin fall from 18% to 11% with membership growth?

├─ Revenue por Socio

│ ├─ Did average revenue per member fall?

│ │ ├─ Premium customers left and were replaced by basic ones

│ │ ├─ New members are younger/less profitable

│ │ └─ Promociones/descuentos aumentaron

│ └─ Did revenue mix change?

│ ├─ Menos servicios premium vendidos

│ └─ More reliance on basic membership

│

├─ Costo de Servir por Socio

│ ├─ Did variable costs per partner increase?

│ │ ├─ Staff needed grew faster than membership

│ │ ├─ Servicios (utilities, mantenimiento) se incrementaron

│ │ └─ Costes de riesgo (churn, no-show) subieron

│ └─ Are fixed costs diluted?

│ ├─ New locations with low occupancy

│ ├─ Rent for new locations more expensive

│ └─ CAPEX investment flowing through P&L

│

└─ Eficiencia Operativa

├─ Did capacity utilization decrease?

│ └─ Nuevas gyms con bajo uso durante ramp-up

└─ Did geographic mix change?

└─ Nuevas ubicaciones en zonas menos densas/rentables

```

What's right?

• ●It's specific to the case. Each branch connects with the information given.
• ●It has a clear hypothesis that guides the entire structure.
• ●Es profundo. Tres o cuatro niveles de profundidad.
• ●Cada pregunta es testeable. Puedes pedir datos.
• ●Show thinking. Not memorization.

See the difference? The second is an issue tree. The first is a template.

The Golden Rule: Hypothesis First, Tree Second

If you memorize one thing from this article, make it this: The hypothesis defines the tree. Not the other way around.

At Bain, when a candidate presented a generic issue tree, I asked: "Why are those your branches?" If they answered "because it's a standard framework," we were done. They had failed.

If they answered "because based on the case, the situation is X and my hypothesis is Y, so I need to test these areas specifically," we continued. They had passed.

Your hypothesis is your compass. It guides every decision in the tree. Each branch exists to test or refute that hypothesis.

Without a hypothesis, you have no direction. You have a pretty but empty tree.

Build Your Issue Tree: Practical Step-by-Step Exercise

I want you to do it. With structure. Without fear of getting it wrong.

El Caso:

"A Spanish airline wants to understand why its revenue per passenger fell 12% in the last year, despite maintaining the same number of flights and similar load factors."

Tu tarea:

1. 1Read the case. What exactly is the problem?
2. 2What's your initial hypothesis?
3. 3How would you divide the problem into main branches?
4. 4What specific questions do you need to answer in each branch?
5. 5Is your tree MECE?

Write this before reading my solution. It's important.

---

Solution (Model):

Problema: Revenue per passenger fell 12% with flights and occupancy maintained. Means each passenger generates less revenue.

Hypothesis: Passengers are paying less per ticket (price cut or shift to cheaper fares) or ancillary revenue (baggage, meals, premium seats) fell.

Árbol:

```

Why did revenue per passenger fall 12%?

├─ Ingresos Base por Pasajero (Ticket)

│ ├─ Did average price per ticket fall?

│ │ ├─ General tariff reduction

│ │ ├─ Greater proportion of discounts/promotions

│ │ ├─ Mix shift: more passengers on low-cost routes

│ │ └─ Competitive pressure

│ └─ Did route mix change?

│ ├─ More domestic flights (lower fare)

│ ├─ Menos rutas internacionales (higher fare)

│ └─ Change in geographic distribution

│

├─ Ingresos Complementarios por Pasajero

│ ├─ Fewer ancillary services sold?

│ │ ├─ Menos bagaje checking (pasajeros con solo carry-on)

│ │ ├─ Menos comidas/bebidas a bordo

│ │ └─ Menos upgrades de asiento comprados

│ └─ Did ancillary service prices drop?

│ ├─ Competition forced prices down

│ └─ Change in airline policy

│

└─ Factores Externos

├─ Change in passenger demand?

│ ├─ Economic crisis (fewer trips or budget trips)

│ └─ Change in preferences (more price-sensitive)

└─ Change in client mix?

├─ More budget travelers

└─ Fewer business travelers (who pay more)

```

This tree is specific. Testable. Connected to the case. Has clear direction.

Mistakes I Make Now: Review of My Own Evolution

After 13+ years in consulting, 9+ at Bain & Company, and 300+ interviews evaluated, I'll tell you something you won't hear elsewhere: I still make mistakes in issue trees.

Five years ago, I would have presented a deeper, broader tree. Now, I aim to be more selective. I only dig deeper into what really impacts the hypothesis. The art is knowing what to leave out.

The most common mistake I see in candidates is the opposite: they want to add everything. Branches that don't matter. Questions they won't answer. It's filler. The partner sees it.

My advice: start with big divisions. Then dig deeper. But before adding a branch, ask yourself: "Does this branch help me test my hypothesis?" If no, eliminate it.

The best issue tree isn't the biggest. It's the one that answers the case with the least complexity necessary.

Frequently Asked Questions: What You Really Need to Know

Q: How many branches should I have at the top level?

It depends on the case. Some cases have two natural branches (Revenue/Costs). Others have three (Market/Competition/Capacity). Others have four or more. No magic number. Rule: if you have more than five branches at the top level, you're probably being too fragmented. Group them.

Q: Should I memorize issue trees from books or build my own?

Build your own, but base them on templates. The books (McKinsey, Bain, BCG) use proven frameworks. Learn the logic behind them. Then adapt to the case. The 25% of candidates who pass do exactly that. They don't memorize. They understand the logic and apply it.

P: Is it bad to change my issue tree during the interview if the partner suggests something different?

It's not bad. It's flexibility. The partner tests if you can adapt. If you recognize their structure makes sense and you adapt, it shows flexible thinking. That's positive. What's bad is clinging to your tree when it's clearly not the best.

P: Does an excellent issue tree guarantee passing?

No. It guarantees the structure is solid. But you could have perfect structure, get the math wrong, make weak conclusions, or communicate poorly. I've seen candidates with excellent issue trees fail in execution. The tree is necessary. It's not sufficient.

Q: How do I know if my issue tree is too deep or not deep enough?

Rule of thumb: each branch at the lowest level should be answerable with specific data in the interview or outside it. If you end with questions like "What happened in operations?" (too broad), you need to dig deeper. If you end with questions like "What was the GBP exchange rate?" (too specific), you need to generalize.

Q: Is the issue tree only for diagnostic cases?

No. It works for all types of cases. Market, operation, strategy, viability. In each one, the logic is the same: break down the problem into its logical elements.

Q: If I make an error in the issue tree, is everything lost?

No. Errors are information. If the partner asks "Why did you include that branch?" and you recognize it's not relevant, you correct and move forward. That's critical thinking. What's bad is not recognizing the error and moving on.

The Path: From Here to the Interview

Issue trees are mastered through practice. Not reading.

Here's your plan:

Semana 1: Learn the basic frameworks. Revenue/Costs. Internal/External. Supply/Demand. Memorize the logic, not the form.

Semana 2: Build issue trees from scratch for 5 cases. Don't use books. Think for yourself. It will be imperfect. That's fine. That's the point.

Semana 3: Have someone experienced review your trees. Pay attention to feedback. Especially: Where are the overlaps? What's missing?

Semana 4: Practice communicating the tree in 60 seconds. No reading. Doesn't sound memorized. Natural. Like you're thinking out loud.

Semana 5+: Practice the complete analysis. Tree + data analysis + conclusion. The tree is just the start. Then you have to execute.

At Bain, the candidates who passed had practiced issue trees 30-40 times. It wasn't magic. It was deliberate repetition.

The difference between the 25% who build original issue trees and the 75% who memorize is practice. The 25% dedicated time to understanding the logic. The 75% tried to cut corners.

Which side do you want to be on?

Your issue tree is your map in the interview. If it's clear, you navigate well. If it's confusing, you get lost. That simple.

---

Expand your knowledge:

• ●Framework MECE: la base de todo
• ●How to structure and frame a case from the beginning
• ●Types of cases you'll encounter at McKinsey, BCG, Bain
• ●Your complete preparation plan

Domina los frameworks con ejemplos paso a paso:

Crack The Frameworks → nextepmbb.com/recursos