Molti problemi di prodotto e di business vanno male ancora prima che le persone inizino a studiarli. Questo accade perché il team non ha concordato su quale problema stia cercando di risolvere. Una singola domanda può portare le persone a pensare contemporaneamente alla causa, al piano e alla soluzione.
Ogni persona potrebbe rispondere a una domanda diversa. Trovare la causa, fare un piano e scegliere una soluzione sono tre lavori distinti. Quando le persone li mescolano, rischiano di perdersi fatti importanti o di prendere decisioni deboli. Ad esempio, qualcuno potrebbe indovinare la causa quando il team ha invece bisogno di un piano. Oppure il team potrebbe discutere di soluzioni prima di sapere cosa ha causato il problema.
Un buon modo per studiare un problema è seguire uno di tre percorsi chiari. Il team pone le domande un passo alla volta e verifica che nulla venga ripetuto o tralasciato. L'AI può aiutare con questi controlli. Il product manager decide comunque quale problema studiare, qual è il problema principale e quali domande il team deve rispondere.
Distingui i rami del pensiero
- Un Why-tree trova le cause. La sua radice chiede perché qualcosa sta accadendo. Le sue foglie elencano le possibili cause. Il risultato finale è un insieme di ipotesi verificabili.
- Un What-tree suddivide il lavoro. La sua radice chiede quale lavoro richiede un deliverable. Le sue foglie elencano analisi, decisioni, impegni, artefatti o processi. Il risultato finale è un piano nell'ordine corretto.
- Un How-tree elenca i percorsi possibili. La sua radice chiede come il team potrebbe raggiungere un obiettivo scelto. Le sue foglie elencano azioni concrete. Il risultato finale è un insieme di opzioni classificate.
Usa Why per le cause, What per le unità di lavoro e How per le azioni. Ogni tipo di foglia supporta una decisione diversa.
Esempio
Input: "L'attivazione dei nostri nuovi utenti è insufficiente. Dobbiamo decidere cosa fare."
Il diagramma seguente usa segnaposto per i tipi di ramo e non contiene risultati su un prodotto reale.
\\`text
WHY: Perché l'attivazione dei nuovi utenti è insufficiente?
├── 1. [Famiglia di cause candidate A]
├── 2. [Famiglia di cause candidate B]
└── 3. [Famiglia di cause candidate C]
Output: ipotesi verificabili
WHAT: Cosa implica produrre un piano di attivazione per noi?
├── 1. Evidenze
│ └── 1.1 [ANALISI] Evidenze di cui il piano ha bisogno
├── 2. Scelte
│ └── 2.1 [DECISIONE] Scelta che dipende dall'analisi
├── 3. Accordi
│ └── 3.1 [IMPEGNO] Proprietà o ambito da confermare
└── 4. Sintesi
└── 4.1 [SINTESI] Piano che dipende dai rami 1–3
Output: piano di lavoro sequenziale
HOW: Come potremmo migliorare l'attivazione dei nuovi utenti?
├── 1. [Intervento legato a una causa confermata]
├── 2. [Intervento legato a un'altra causa confermata]
└── 3. [Famiglia di interventi entro i vincoli indicati]
Output: opzioni classificate
\\`
Userei Why qui perché il team sa che l'attivazione è bassa ma non ne ha trovato la causa. How sarebbe adatto se il team conoscesse la causa. What sarebbe adatto se il team avesse bisogno di produrre un piano di attivazione.
I controlli strutturali non possono provare che l'albero sia vero
Tutti e tre gli alberi usano la stessa regola MECE.
I rami a ogni livello non dovrebbero sovrapporsi. I rami a ogni livello dovrebbero coprire tutte le aree importanti. Questo controllo aiuta un PM a identificare le aree coperte da più di un ramo e le aree non coperte affatto.
Quando mi trovo di fronte a un problema complesso, discuto il contesto con l'AI. Uso la competenza per abbozzare i rami, costruire l'albero ed eseguire i controlli MECE. Conservo il risultato nella chat o lo copio in Miro o in un altro strumento visivo.
Rendi il metodo ripetibile
Un product manager può creare un albero del problema a mano. Ma un team deve svolgere lo stesso lavoro più e più volte. Deve creare rami, metterli in ordine, controllare ogni livello e disegnare un albero chiaro per molti problemi diversi.
Un agente AI può eseguire questi passaggi ripetutamente. Il product manager aggiunge dettagli sul prodotto e decide come descrivere il problema, nominare la questione principale e rimuovere i rami non necessari. Quando tutti usano gli stessi passaggi, i leader di prodotto e i revisori possono comprendere il lavoro più facilmente. Possono vedere perché il team ha costruito l'albero in quel modo e verificare che copra l'intero problema senza ripetere idee.
Quando affronti un nuovo problema, decidi prima di tutto di quale risposta hai bisogno. Devi trovare le cause, fare un piano di lavoro o pensare a diverse opzioni? Poi scegli Why, What o How per corrispondere a quell'obiettivo. Costruisci il tuo primo albero. Successivamente, cerca un ramo che manca e un ramo che ripete un'altra idea prima di utilizzare l'albero.
Se un team di prodotto vuole usare questo metodo ripetutamente, non dovrebbe chiedere a ogni product manager di costruire l'intero processo e controllare tutte le regole a mano. L'AI può fare quel lavoro ripetitivo in modo che il team possa dedicare più tempo a risolvere il problema.
Dai questa competenza al tuo team
\mckinsey-issue-tree\ è una delle 243 competenze PM all'interno di AI PM OS, il sistema operativo condiviso per i team di prodotto. Funziona in Claude Code, Cowork o Cursor e viene aggiornato almeno una volta ogni 2 settimane, alla versione 2.5.
Ogni PM mantiene il proprio contesto di prodotto mentre il team condivide flussi di lavoro e standard di revisione, in modo che gli alberi del problema e i piani analitici siano radicati nel tuo prodotto, nei tuoi utenti e nei tuoi vincoli reali, invece di essere consigli PM generici.
Non devi assemblare nulla. AI PM OS integra \mckinsey-issue-tree\ nel livello operativo del team insieme a flussi di lavoro per strategia, ricerca, decisioni, lavoro con gli stakeholder e misurazione.
