Muchos problemas de producto y de negocio se tuercen antes de que la gente siquiera empiece a estudiarlos. Esto ocurre porque el equipo no se ha puesto de acuerdo sobre qué problema intenta resolver. Una sola pregunta puede hacer que la gente piense al mismo tiempo en la causa, el plan y la solución.
Cada persona puede responder a una pregunta distinta. Encontrar la causa, hacer un plan y elegir una solución son tres trabajos diferentes. Cuando la gente los mezcla, puede pasar por alto hechos importantes o tomar decisiones débiles. Por ejemplo, alguien podría adivinar la causa cuando el equipo realmente necesita un plan. O el equipo podría hablar de soluciones antes de saber qué provocó el problema.
Una buena forma de estudiar un problema es seguir uno de tres caminos claros. El equipo hace preguntas paso a paso y verifica que no se repita nada ni se deje nada fuera. La IA puede ayudar con estas comprobaciones. El product manager sigue decidiendo qué problema estudiar, cuál es el problema principal y qué preguntas debe responder el equipo.
Desenreda las ramas del pensamiento
- Un Why-tree encuentra causas. Su raíz pregunta por qué está ocurriendo algo. Sus hojas enumeran posibles causas. El resultado final es un conjunto de hipótesis comprobables.
- Un What-tree desglosa el trabajo. Su raíz pregunta qué trabajo requiere un entregable. Sus hojas enumeran análisis, decisiones, compromisos, artefactos o procesos. El resultado final es un plan en el orden correcto.
- Un How-tree enumera caminos posibles. Su raíz pregunta cómo podría el equipo alcanzar un objetivo elegido. Sus hojas enumeran acciones concretas. El resultado final es un conjunto de opciones clasificadas.
Usa Why para causas, What para unidades de trabajo y How para acciones. Cada tipo de hoja respalda una decisión diferente.
Ejemplo
Entrada: "La activación de nuevos usuarios está por debajo de lo esperado. Necesitamos decidir qué hacer."
El siguiente visual usa marcadores de posición para los tipos de ramas y no contiene hallazgos sobre un producto real.
\\`text
WHY: ¿Por qué la activación de nuevos usuarios está por debajo de lo esperado?
├── 1. [Familia de causas candidatas A]
├── 2. [Familia de causas candidatas B]
└── 3. [Familia de causas candidatas C]
Resultado: hipótesis comprobables
WHAT: ¿Qué necesitamos desglosar para elaborar un plan de activación?
├── 1. Evidencia
│ └── 1.1 [ANÁLISIS] Evidencia que necesita el plan
├── 2. Decisiones
│ └── 2.1 [DECISIÓN] Elección que depende del análisis
├── 3. Acuerdos
│ └── 3.1 [COMPROMISO] Propiedad o alcance a confirmar
└── 4. Síntesis
└── 4.1 [SÍNTESIS] Plan que depende de las ramas 1–3
Resultado: plan de trabajo secuenciado
HOW: ¿Cómo podríamos mejorar la activación de nuevos usuarios?
├── 1. [Intervención vinculada a una causa confirmada]
├── 2. [Intervención vinculada a otra causa confirmada]
└── 3. [Familia de intervenciones dentro de las restricciones establecidas]
Resultado: opciones clasificadas
\\`
Yo usaría Why aquí porque el equipo sabe que la activación es baja pero no ha encontrado la causa. How encajaría si el equipo conociera la causa. What encajaría si el equipo necesitara elaborar un plan de activación.
Las comprobaciones estructurales no pueden probar que el árbol sea cierto
Los tres árboles usan la misma regla MECE.
Las ramas de cada nivel no deben solaparse. Las ramas de cada nivel deben cubrir todas las áreas importantes. Esta comprobación ayuda a un PM a identificar áreas que están cubiertas por más de una rama y áreas que no están cubiertas en absoluto.
Cuando me enfrento a un problema desordenado, hablo del contexto con la IA. Uso la habilidad para redactar ramas, construir el árbol y ejecutar las comprobaciones MECE. Guardo el resultado en el chat o lo copio en Miro u otra herramienta visual.
Haz que el método sea repetible
Un solo product manager puede hacer un árbol de problemas a mano. Pero un equipo tiene que hacer el mismo trabajo una y otra vez. Deben crear ramas, ordenarlas, comprobar cada nivel y dibujar un árbol claro para muchos problemas diferentes.
Un agente de IA puede hacer estos pasos repetidamente. El product manager añade detalles sobre el producto y decide cómo describir el problema, nombrar el problema principal y eliminar las ramas que no son necesarias. Cuando todos usan los mismos pasos, los líderes de producto y los revisores pueden entender el trabajo más fácilmente. Pueden ver por qué el equipo construyó el árbol de esa manera y comprobar que cubre todo el problema sin repetir ideas.
Cuando te enfrentes a un problema nuevo, primero decide qué respuesta necesitas. ¿Necesitas encontrar las causas, hacer un plan de trabajo o pensar en diferentes opciones? Luego elige Why, What o How para que coincida con ese objetivo. Construye tu primer árbol. A continuación, busca una rama que falte y una rama que repita otra idea antes de usar el árbol.
Si un equipo de producto quiere usar este método una y otra vez, no debería pedir a cada product manager que construya todo el proceso y compruebe todas las reglas a mano. La IA puede hacer ese trabajo repetitivo para que el equipo pueda dedicar más tiempo a resolver el problema.
Dale esta habilidad a tu equipo
\mckinsey-issue-tree\ es una de las 243 habilidades de PM dentro de AI PM OS, el sistema operativo compartido para equipos de producto. Funciona en Claude Code, Cowork o Cursor y se actualiza al menos una vez cada 2 semanas, en la versión 2.5.
Cada PM mantiene su propio contexto de producto mientras el equipo comparte flujos de trabajo y estándares de revisión, de modo que los árboles de problemas y los planes analíticos se basan en tu producto, tus usuarios y tus limitaciones reales, en lugar de consejos genéricos de PM.
No tienes que montar nada de eso. AI PM OS integra \mckinsey-issue-tree\ en la capa operativa del equipo junto con flujos de trabajo para estrategia, investigación, decisiones, gestión de stakeholders y medición.
