Muchos problemas de producto y negocio salen mal incluso antes de que la gente empiece a estudiarlos. Esto ocurre porque el equipo no se ha puesto de acuerdo sobre qué problema están tratando de resolver. Una sola pregunta puede hacer que la gente piense en la causa, el plan y la solución al mismo tiempo.
Cada persona puede responder a una pregunta diferente. Encontrar la causa, hacer un plan y elegir una solución son tres trabajos distintos. 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é causó el problema.
Una buena manera de estudiar un problema es seguir uno de tres caminos claros. El equipo hace preguntas paso a paso y verifica que nada se repita o quede fuera. La IA puede ayudar con estas verificaciones. 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 Árbol de Por qué encuentra causas. Su raíz pregunta por qué está sucediendo algo. Sus hojas enumeran posibles causas. El resultado final es un conjunto de hipótesis comprobables.
- Un Árbol de Qué 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 Árbol de Cómo enumera posibles caminos. Su raíz pregunta cómo podría el equipo alcanzar una meta elegida. Sus hojas enumeran acciones concretas. El resultado final es un conjunto de opciones clasificadas.
Usa Por qué para causas, Qué para unidades de trabajo y Cómo 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 gráfico a continuación usa marcadores de posición para los tipos de ramas y no contiene hallazgos sobre un producto real.
\\`text
POR QUÉ: ¿Por qué la activación de nuevos usuarios está por debajo de lo esperado?
├── 1. [Familia de causa candidata A]
├── 2. [Familia de causa candidata B]
└── 3. [Familia de causa candidata C]
Resultado: hipótesis comprobables
QUÉ: ¿Qué necesitamos desglosar para producir un plan de activación?
├── 1. Evidencia
│ └── 1.1 [ANÁLISIS] Evidencia que necesita el plan
├── 2. Decisiones
│ └── 2.1 [DECISIÓN] Decisió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
CÓMO: ¿Cómo podríamos aumentar 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 Por qué aquí porque el equipo sabe que la activación es baja pero no ha encontrado la causa. Cómo encajaría si el equipo conociera la causa. Qué encajaría si el equipo necesitara producir un plan de activación.
Las comprobaciones estructurales no pueden probar que el árbol sea verdadero
Los tres árboles usan la misma regla MECE.
Las ramas en cada nivel no deben superponerse. Las ramas en 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 complicado, hablo del contexto con la IA. Uso la habilidad para redactar ramas, construir el árbol y ejecutar las comprobaciones MECE. Mantengo el resultado en el chat o lo copio en Miro u otra herramienta visual.
Haz que el método sea repetible
Un 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, verificar cada nivel y dibujar un árbol claro para muchos problemas diferentes.
Un agente de IA puede hacer estos pasos repetidamente. El product manager agrega 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 verificar que cubra todo el problema sin repetir ideas.
Cuando te enfrentes a un nuevo problema, primero decide qué respuesta necesitas. ¿Necesitas encontrar las causas, hacer un plan de trabajo o pensar en diferentes opciones? Luego elige Por qué, Qué o Cómo para que coincida con ese objetivo. Construye tu primer árbol. Luego, 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 pedirle a cada product manager que construya todo el proceso y verifique 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 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 vuelvan basados en tu producto, tus usuarios y tus restricciones reales, en lugar de consejos genéricos de PM.
No tienes que armar nada de esto. AI PM OS integra \mckinsey-issue-tree\ en la capa operativa del equipo junto con flujos de trabajo para estrategia, investigación, decisiones, trabajo con stakeholders y medición.
