Issue Trees: cómo construir árboles de problemas

Issue trees. La herramienta que define si pasas o fallas en Bain, McKinsey, BCG. Te lo digo directo: en mis 13 años en consultoría, evaluando más de 300 entrevistas, he visto candidatos con issue trees excelentes pasar y candidatos sin ellos fallar. La diferencia entre un issue tree mediocre y uno excelente es la diferencia entre un "tal vez" y un sí claro del socio.

Lo interesante es que el 75% de los candidatos usan issue trees que memorizaron de libros. El 25% construye los propios, desde cero, diseñados para el caso específico. Ese 25% tiene mucha más probabilidad de pasar. No porque sus frameworks sean perfectos. Sino porque demuestran que entienden cómo funciona la consultoría.

En este artículo te voy a enseñar exactamente qué es un issue tree, por qué funciona, cómo se construye desde cero, y cómo evitar los errores que cometen 9 de cada 10 candidatos.

Introducción: Por Qué el Issue Tree Es Tu Mejor Arma en la Entrevista

Cuando entras a un caso de consultoría, el socio espera ver algo específico: pensamiento estructurado. No opiniones. No suposiciones. No "creo que es porque...". Pensamiento estructurado.

El issue tree es exactamente eso. Es la herramienta que convierte un problema caótico en un árbol lógico donde cada rama responde a una pregunta clara: "¿Qué tendría que ser verdad para que mi hipótesis sea correcta?"

He visto candidatos brillantes fracasar sin un issue tree. He visto candidatos mediocres pasar porque su issue tree era específico, profundo y lógico. El socio de Bain no busca genio. Busca pensamiento estructurado. Buscador metodología.

La diferencia entre issue tree y framework MECE es sutil pero crítica. MECE es la regla de construcción (Mutually Exclusive, Collectively Exhaustive). Issue tree es la aplicación práctica de esa regla. Un issue tree bien hecho es siempre MECE. Pero no todo framework MECE es un buen issue tree.

¿Por qué? Porque el issue tree está diseñado para algo específico: testear una hipótesis. Cada rama, cada sub-rama, existe para responder una pregunta que te acerca a la verdad o te la aleja.

En este artículo no solo te diré qué es. Te mostraré cómo construir issue trees que funcionen en la entrevista real, con ejemplos paso a paso, ejercicios prácticos, y las preguntas exactas que te harás cuando lo hagas mal.

Qué es un Issue Tree: Estructura Mental de un Consultor

Un issue tree es una herramienta visual que desglosa un problema complejo en partes más pequeñas, manejables y lógicamente relacionadas. Suena simple. Es simple. Pero la ejecución es lo que diferencia a los mejores.

La estructura es así:

Hipótesis (el problema principal) se divide en 2-4 ramas principales, cada una de las cuales se divide en sub-ramas, y así sucesivamente hasta que llegas a preguntas específicas que puedes testear con datos.

Ejemplo visual simple:

```

¿Por qué caen las ventas del cliente?

│

├─ ¿Problema de demanda?

│ ├─ ¿Menos clientes?

│ ├─ ¿Menos compras por cliente?

│ └─ ¿Precio más bajo?

│

├─ ¿Problema de oferta?

│ ├─ ¿Menos capacidad de producción?

│ ├─ ¿Calidad inferior?

│ └─ ¿Problemas de distribución?

│

└─ ¿Factores externos?

├─ ¿Nueva competencia?

├─ ¿Cambio regulatorio?

└─ ¿Ciclo económico?

```

Cada rama responde: "¿Qué sería necesario que fuera verdad para explicar el problema?"

Lo clave es esto: No es una lista de temas. Es un árbol de lógica. Cada elemento está conectado al anterior. Cada uno profundiza la pregunta. El objetivo es descomponer lo complejo hasta encontrar lo específico que puedes testear con datos.

Los Errores Críticos: Dónde Fracasan 9 de Cada 10 Candidatos

He evaluado cientos de casos. Los errores son predecibles.

Error 1: Issue Tree Genérico Sin Hipótesis

Candidato llega a la entrevista y presenta esto:

```

Problema: Los ingresos bajaron

├─ Revenue

│ ├─ Precio

│ └─ Volumen

└─ Costs

├─ Fijos

└─ Variables

```

Técnicamente está bien estructurado. Pero es genérico. Funciona para cualquier caso sobre ingresos. No tiene hipótesis. El socio pregunta: "¿Por qué organizaste así?" y el candidato dice "es un framework estándar." Eso mata la entrevista.

Lo correcto es lo opuesto: empezar con una hipótesis basada en los datos del caso.

Error 2: Falta de Estructura Lógica

He visto issue trees donde las ramas no conectan lógicamente. Por ejemplo:

```

¿Por qué bajó el margen?

├─ Ingresos

├─ Clientes

├─ Competencia

└─ Talento

```

¿Dónde está la lógica? ¿Cómo se relacionan? ¿Falta algo? Está todo fragmentado. No hay una dirección clara.

Un issue tree debe tener estructura: primero lo macro (revenue vs. costs), luego lo meso (dentro de revenue, qué pasó), luego lo micro (datos específicos). Es como un embudo. De lo amplio a lo específico.

Error 3: Ramas Que No Conectan Con el Caso

Candidato memoriza un issue tree de un libro y lo aplica a todos los casos sin adaptar. El socio ve eso de inmediato. Es como cuando ves a alguien leer un guión sin emoción. Sabes que no está pensando. Solo repitiendo.

Ejemplo: Un caso sobre rentabilidad de una cadena de tiendas. El candidato presenta un issue tree sobre mercado total, crecimiento orgánico vs. inorgánico, etc. Técnicamente bien. Pero el caso no habla de inorgánico. No encaja. Es relleno.

Error 4: Profundidad Insuficiente

He visto issue trees que paran a nivel 2. Dos niveles de profundidad. Eso no es suficiente para testear una hipótesis real. Un buen issue tree tiene 3-4 niveles. En cada nivel profundizas más. En el nivel más bajo, tienes preguntas específicas que puedes responder con datos.

Error 5: No Comunicar Antes de Analizar

Este es el error más grande. El candidato construye el issue tree mentalmente, luego comienza a analizar sin mostrar la estructura. El socio no sabe dónde va. A mitad del análisis, dice "espera, ¿por dónde vas?" y el candidato se pierde.

La regla de oro: Construye el issue tree. Comunícalo. Luego analiza. En ese orden.

Cómo Construir un Issue Tree: Método Paso a Paso

Llevo 13 años construyendo issue trees en Bain. El método no cambia.

Paso 1: Entiende el Caso y Forma una Hipótesis

No empieces con el árbol. Empieza con la pregunta.

Lee el caso dos veces. Primera lectura: captar información. Segunda lectura: ¿cuál es exactamente el problema? ¿Qué sé? ¿Qué no sé?

En Bain, en mis evaluaciones, siempre preguntaba al candidato: "¿Cuál es tu hipótesis inicial?" El 30% respondía correctamente. El 70% decía "no tengo" o presentaba una suposición vaga.

Una hipótesis es una propuesta específica sobre qué está pasando. No es "el cliente tiene un problema." Es: "El margen del cliente cayó porque los costes de servir a nuevos clientes crecieron más rápido que los ingresos provenientes de ellos."

Nota la diferencia. Específica. Testeable. Dirección clara.

Paso 2: Identifica las Grandes Divisiones Lógicas

Aquí es donde empieza el árbol. No con ramas pequeñas. Con las divisiones grandes.

Para un problema de rentabilidad: Revenue vs. Costs.

Para un problema de mercado: Oferta vs. Demanda.

Para un problema de estrategia: Interno vs. Externo.

Para un problema de crecimiento: Orgánico vs. Inorgánico.

Estas divisiones son el tronco del árbol. Todo lo demás cuelga de aquí.

Paso 3: Profundiza en Cada Rama Principal

Dentro de cada rama principal, pregúntate: "¿Qué tendría que ser verdad dentro de esta categoría para que mi hipótesis sea correcta?"

Ejemplo:

• ●Si mi hipótesis es "los costes subieron," entonces dentro de Costs necesito preguntar:
• ●¿Subieron los costes fijos?
• ●¿Subieron los costes variables?
• ●¿Hay costes puntuales que impactan el período?

Cada pregunta es una sub-rama.

Paso 4: Profundiza Una Vez Más

Para cada sub-rama, profundiza: ¿Qué específicamente causaría que esto sea verdad?

Ejemplo:

• ●Si "Subieron los costes variables," entonces:
• ●¿Subieron porque procesamos más transacciones? (Volume up)
• ●¿Subieron porque el costo unitario se incrementó? (Cost per unit up)
• ●¿Cambió el mix de transacciones hacia las más caras? (Mix shift)

Ahora tienes preguntas con las que puedes trabajar. Puedes pedir datos. Puedes testear.

Paso 5: Asegúrate de Que Sea MECE

Antes de presentar, verifica:

• ●¿Las ramas a cada nivel no se solapan?
• ●¿Juntas cubren todo lo importante?
• ●¿Cada rama profundiza la pregunta anterior?

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

Issue Trees Mediocres vs. Excelentes: Comparación Real

Voy a mostrarte un caso real y cómo lo manejan candidatos mediocres vs. excelentes.

El Caso:

"Tu cliente es una cadena de gimnasios en España que ha visto caer su margen operativo del 18% al 11% en los últimos dos años, a pesar de que el número de socios ha crecido 5%. ¿Qué está pasando?"

Issue Tree Mediocre (Lo Que Hace el 75%)

```

¿Por qué cayó el margen?

├─ Revenue

│ ├─ Precio

│ └─ Volumen

└─ Costs

├─ Fijos

└─ Variables

```

¿Qué está mal?

• ●Es genérico. Funciona para cualquier caso de rentabilidad.
• ●No conecta con el caso específico (margen bajo a pesar de crecimiento de socios).
• ●No hay hipótesis. No hay dirección.
• ●Es superficial. Dos niveles apenas.
• ●El candidato no demuestra pensamiento. Solo memorización.

Issue Tree Excelente (Lo Que Hace el 25%)

Hipótesis: El margen cayó porque, aunque el número de socios creció 5%, los nuevos socios generan menor ingresos por unidad o requieren mayor costo de servicio. O ambos.

```

¿Por qué el margen cayó del 18% al 11% con crecimiento de socios?

├─ Revenue por Socio

│ ├─ ¿Ingresos promedio por socio bajó?

│ │ ├─ Clientes premium dejaron y fueron reemplazados por básicos

│ │ ├─ Nuevos socios son más jóvenes/menos rentables

│ │ └─ Promociones/descuentos aumentaron

│ └─ ¿Mix de ingresos cambió?

│ ├─ Menos servicios premium vendidos

│ └─ Más dependencia de membresía base

│

├─ Costo de Servir por Socio

│ ├─ ¿Costes variables por socio subieron?

│ │ ├─ Personal necesario creció más rápido que socios

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

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

│ └─ ¿Costes fijos se diluyen?

│ ├─ Nuevas ubicaciones con baja ocupación

│ ├─ Rent de nuevas ubicaciones más caro

│ └─ Inversión CAPEX fluyendo por P&L

│

└─ Eficiencia Operativa

├─ ¿Capacidad utilizada disminuyó?

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

└─ ¿Mix geográfico cambió?

└─ Nuevas ubicaciones en zonas menos densas/rentables

```

¿Qué está bien?

• ●Es específico del caso. Cada rama conecta con la información dada.
• ●Tiene una hipótesis clara que dirije toda la estructura.
• ●Es profundo. Tres o cuatro niveles de profundidad.
• ●Cada pregunta es testeable. Puedes pedir datos.
• ●Demuestra pensamiento. No memorización.

¿Ves la diferencia? El segundo es un issue tree. El primero es un template.

La Regla de Oro: Hipótesis Primero, Árbol Después

Si memorizas una cosa de este artículo, que sea esto: La hipótesis define el árbol. No es al revés.

En Bain, cuando un candidato presentaba un issue tree genérico, preguntaba: "¿Por qué esas son tus ramas?" Si respondía "porque es un framework estándar," terminábamos. Habían fracasado.

Si respondía "porque según el caso, la situación es X y mi hipótesis es Y, entonces necesito testear estas áreas específicamente," continuábamos. Habían pasado.

Tu hipótesis es tu brújula. Guía cada decisión en el árbol. Cada rama existe para testear o refutar esa hipótesis.

Sin hipótesis, no tienes dirección. Tienes un árbol bonito pero vacío.

Construye Tu Issue Tree: Ejercicio Práctico Paso a Paso

Quiero que lo hagas tú. Con estructura. Sin miedo a equivocarte.

El Caso:

"Una aerolínea española quiere entender por qué sus ingresos por pasajero han caído 12% en el último año, a pesar de mantener el mismo número de vuelos y factores de ocupación (load factors) similares."

Tu tarea:

1. 1Lee el caso. ¿Cuál es exactamente el problema?
2. 2¿Cuál es tu hipótesis inicial?
3. 3¿Cómo dividirías el problema en ramas principales?
4. 4¿Qué preguntas específicas necesitas responder en cada rama?
5. 5¿Tu árbol es MECE?

Escribe esto antes de leer mi solución. Es importante.

---

Solución (Modelo):

Problema: Revenue per passenger bajó 12% con vuelos y ocupación mantenida. Significa que cada pasajero genera menos ingresos.

Hipótesis: Los pasajeros están pagando menos por ticket (baja de precio o cambio a tarifas más baratas) o los ingresos complementarios (bagaje, comidas, asientos premium) bajaron.

Árbol:

```

¿Por qué cayó el revenue por pasajero un 12%?

├─ Ingresos Base por Pasajero (Ticket)

│ ├─ ¿Precio promedio por ticket bajó?

│ │ ├─ Reducción de tarifa de lista general

│ │ ├─ Mayor proporción de descuentos/promocioneS

│ │ ├─ Cambio de mix: más pasajeros en rutas low-cost

│ │ └─ Presión competitiva

│ └─ ¿Mix de rutas cambió?

│ ├─ Más vuelos domésticos (lower fare)

│ ├─ Menos rutas internacionales (higher fare)

│ └─ Cambio en distribución geográfica

│

├─ Ingresos Complementarios por Pasajero

│ ├─ ¿Servicios ancilares vendidos menos?

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

│ │ ├─ Menos comidas/bebidas a bordo

│ │ └─ Menos upgrades de asiento comprados

│ └─ ¿Precios de servicios ancilares bajaron?

│ ├─ Competencia forzó bajar precios

│ └─ Cambio de política de la aerolínea

│

└─ Factores Externos

├─ ¿Cambio de demanda de pasajeros?

│ ├─ Crisis económica (menos viajes o viajes económicos)

│ └─ Cambio de preferencias (más price-sensitive)

└─ ¿Cambio de mix de clientes?

├─ Más budget travelers

└─ Menos business travelers (que pagan más)

```

Este árbol es específico. Testeable. Conectado con el caso. Tiene dirección clara.

Errores Que Cometo Ahora: Revisión de Mi Propia Evolución

Después de 13+ años en consultoría, 9+ en Bain & Company, y 300+ entrevistas evaluadas, te diré algo que no escucharás en muchos lados: todavía cometo errores en issue trees.

Hace cinco años, habría presentado un árbol más profundo y más amplio. Ahora, busco ser más selectivo. Solo profundizo en lo que realmente impacta la hipótesis. El arte está en saber qué dejar fuera.

El error más común que veo en candidatos es lo opuesto: quieren meter todo. Ramificaciones que no importan. Preguntas que no van a contestar. Es relleno. El socio lo ve.

Mi consejo: empieza con las grandes divisiones. Luego profundiza. Pero antes de agregar una rama, pregúntate: "¿Esta rama me ayuda a testear mi hipótesis?" Si la respuesta es no, elimínala.

La mejor issue tree no es la más grande. Es la que da respuesta al caso con la menor complejidad necesaria.

Preguntas frecuentes: Lo Que Realmente Necesitas Saber

P: ¿Cuántas ramas debería tener en el nivel superior?

Depende del caso. Algunos casos tienen dos ramas naturales (Revenue/Costs). Otros tienen tres (Mercado/Competencia/Capacidad). Otros tienen cuatro o más. No hay número mágico. Regla: si son más de cinco ramas en el nivel superior, probablemente estés siendo demasiado fragmentario. Agrupa.

P: ¿Debería memorizar issue trees de libros o construir los mios?

Construye los tuyos, pero basándote en plantillas. Los libros (McKinsey, Bain, BCG) usan frameworks probados. Aprende la lógica detrás. Luego adapta al caso. El 25% de candidatos que pasan hace exactamente eso. No memoriza. Entiende la lógica y la aplica.

P: ¿Es malo cambiar mi issue tree durante la entrevista si el socio sugiere algo diferente?

No es malo. Es flexibilidad. El socio prueba si puedes adaptarte. Si reconoces que su estructura tiene sentido y te adaptas, demuestra pensamiento flexible. Eso es positivo. Lo malo es aferrarse a tu árbol cuando claramente no es el mejor.

P: ¿Un excelente issue tree garantiza pasar?

No. Garantiza que la estructura sea sólida. Pero puedes tener una estructura perfecta, equivocarte en math, hacer conclusiones débiles, o comunicar mal. He visto candidatos con issue trees excelentes fallar en la ejecución. El árbol es necesario. No es suficiente.

P: ¿Cómo sé si mi issue tree es demasiado profundo o no lo suficiente?

Regla práctica: cada rama en el nivel más bajo debería poder responderse con datos específicos en la entrevista o fuera de ella. Si terminas con preguntas como "¿Qué pasó en operaciones?" (demasiado amplia), necesitas profundizar. Si terminas con preguntas como "¿Cuál fue el tipo de cambio en GBP?" (demasiado específica), necesitas generalizar.

P: ¿El issue tree es solo para casos de diagnóstico?

No. Funciona para todos los tipos de casos. Mercado, operación, estrategia, viabilidad. En cada uno, la lógica es la misma: descomponer el problema en sus elementos lógicos.

P: Si cometo un error en el issue tree, ¿está todo perdido?

No. Los errores son información. Si el socio te pregunta "¿Por qué incluiste esa rama?" y reconoces que no es relevante, corriges y sigues. Eso es pensamiento crítico. Lo malo es no reconocer el error y seguir adelante.

El Camino: De Aquí a la Entrevista

Los issue trees se dominan con práctica. No con lectura.

Aquí va tu plan:

Semana 1: Aprende los frameworks básicos. Revenue/Costs. Interno/Externo. Oferta/Demanda. Memoriza la lógica, no la forma.

Semana 2: Construye issue trees desde cero para 5 casos. No uses libros. Piensa por ti mismo. Será imperfecto. Está bien. Es el punto.

Semana 3: Haz que alguien experimentado revise tus árboles. Presta atención a los comentarios. Especialmente: ¿Dónde hay solapamientos? ¿Qué falta?

Semana 4: Practica comunicando el árbol en 60 segundos. Sin lectura. Sin que suene memorizado. Natural. Como si estuvieras pensando en voz alta.

Semana 5+: Practica el análisis completo. Árbol + análisis de datos + conclusión. El árbol es solo el inicio. Luego tienes que ejecutar.

En Bain, los candidates que pasaban habían practicado issue trees 30-40 veces. No era magia. Era repetición deliberada.

La diferencia entre el 25% que construye issue trees originales y el 75% que memoriza es práctica. El 25% dedicó tiempo a entender la lógica. El 75% trató de atajar.

¿De qué lado quieres estar?

Tu issue tree es tu mapa en la entrevista. Si es claro, navegas bien. Si es confuso, te pierdes. Simple así.

---

Amplía tu conocimiento:

• ●Framework MECE: la base de todo
• ●Cómo estructurar y enmarcar un caso desde el inicio
• ●Tipos de casos que encontrarás en McKinsey, BCG, Bain
• ●Tu plan completo de preparación

Domina los frameworks con ejemplos paso a paso:

Crack The Frameworks → nextepmbb.com/recursos