Viele Produkt- und Geschäftsprobleme gehen schief, bevor man überhaupt anfängt, sie zu untersuchen. Das liegt daran, dass das Team sich nicht darüber geeinigt hat, welches Problem es lösen will. Eine einzige Frage kann dazu führen, dass die Leute gleichzeitig über die Ursache, den Plan und die Lösung nachdenken.
Jede Person könnte eine andere Frage beantworten. Die Ursache zu finden, einen Plan zu erstellen und eine Lösung auszuwählen sind drei verschiedene Aufgaben. Wenn man sie vermischt, kann man wichtige Tatsachen übersehen oder schwache Entscheidungen treffen. Zum Beispiel könnte jemand die Ursache erraten, obwohl das Team eigentlich einen Plan braucht. Oder das Team spricht über Lösungen, bevor es weiß, was das Problem verursacht hat.
Ein guter Weg, ein Problem zu untersuchen, ist, einem von drei klaren Pfaden zu folgen. Das Team stellt Fragen Schritt für Schritt und prüft, ob nichts wiederholt oder ausgelassen wird. KI kann bei diesen Prüfungen helfen. Der Produktmanager entscheidet weiterhin, welches Problem untersucht werden soll, was das Hauptproblem ist und welche Fragen das Team beantworten soll.
Die Gedankenzweige entwirren
- Ein Why-Baum findet Ursachen. Seine Wurzel fragt, warum etwas passiert. Seine Blätter listen mögliche Ursachen auf. Das Endergebnis ist eine Reihe von testbaren Hypothesen.
- Ein What-Baum gliedert die Arbeit auf. Seine Wurzel fragt, welche Arbeit ein Liefergegenstand erfordert. Seine Blätter listen Analysen, Entscheidungen, Zusagen, Artefakte oder Prozesse auf. Das Endergebnis ist ein Plan in der richtigen Reihenfolge.
- Ein How-Baum listet mögliche Wege auf. Seine Wurzel fragt, wie das Team ein gewähltes Ziel erreichen könnte. Seine Blätter listen konkrete Aktionen auf. Das Endergebnis ist eine Reihe von bewerteten Optionen.
Verwende Why für Ursachen, What für Arbeitseinheiten und How für Aktionen. Jeder Blatttyp unterstützt eine andere Entscheidung.
Beispiel
Eingabe: „Unsere Neukundenaktivierung ist unterdurchschnittlich. Wir müssen entscheiden, was zu tun ist.“
Die folgende Grafik verwendet Platzhalter für Zweigtypen und enthält keine Erkenntnisse über ein reales Produkt.
1WHY: Why is new-user activation underperforming?23├── 1. [Ursachenfamilie A]45├── 2. [Ursachenfamilie B]67└── 3. [Ursachenfamilie C]89Output: testable hypotheses1011WHAT: Was müssen wir bei der Erstellung eines Aktivierungsplans aufschlüsseln?1213├── 1. Evidenz1415│ └── 1.1 [ANALYSE] Vom Plan benötigte Evidenz1617├── 2. Entscheidungen1819│ └── 2.1 [ENTSCHEIDUNG] Von der Analyse abhängige Entscheidung2021├── 3. Vereinbarungen2223│ └── 3.1 [ZUSAGE] Zu bestätigende Verantwortung oder Umfang2425└── 4. Synthese2627└── 4.1 [SYNTHESE] Von den Zweigen 1–3 abhängiger Plan2829Output: sequenced workplan3031HOW: Wie könnten wir die Neukundenaktivierung steigern?3233├── 1. [Maßnahme mit bestätigter Ursache]3435├── 2. [Maßnahme mit einer anderen bestätigten Ursache]3637└── 3. [Maßnahmenfamilie innerhalb der genannten Einschränkungen]3839Output: ranked options
Ich würde hier Why verwenden, weil das Team weiß, dass die Aktivierung niedrig ist, aber die Ursache noch nicht gefunden hat. How würde passen, wenn das Team die Ursache kennte. What würde passen, wenn das Team einen Aktivierungsplan erstellen müsste.
Strukturelle Prüfungen können nicht beweisen, dass der Baum wahr ist
Alle drei Bäume verwenden dieselbe MECE-Regel.
Die Zweige auf jeder Ebene sollten sich nicht überschneiden. Die Zweige auf jeder Ebene sollten alle wichtigen Bereiche abdecken. Diese Prüfung hilft einem PM, Bereiche zu identifizieren, die von mehr als einem Zweig abgedeckt werden, und Bereiche, die überhaupt nicht abgedeckt sind.
Wenn ich auf ein unübersichtliches Problem stoße, bespreche ich den Kontext mit der KI. Ich nutze die Fähigkeit, Zweige zu entwerfen, den Baum zu erstellen und die MECE-Prüfungen durchzuführen. Das Ergebnis behalte ich im Chat oder kopiere es in Miro oder ein anderes visuelles Tool.
Die Methode wiederholbar machen
Ein einzelner Produktmanager kann einen Problembaum von Hand erstellen. Aber ein Team muss die gleiche Arbeit immer wieder erledigen. Sie müssen Zweige erstellen, sie in eine Reihenfolge bringen, jede Ebene prüfen und für viele verschiedene Probleme einen klaren Baum zeichnen.
Ein KI-Agent kann diese Schritte immer wieder ausführen. Der Produktmanager fügt Details zum Produkt hinzu und entscheidet, wie das Problem beschrieben wird, das Hauptproblem benannt wird und nicht benötigte Zweige entfernt werden. Wenn alle die gleichen Schritte verwenden, können Produktleiter und Prüfer die Arbeit leichter verstehen. Sie können sehen, warum das Team den Baum so aufgebaut hat, und prüfen, ob er das gesamte Problem abdeckt, ohne Ideen zu wiederholen.
Wenn du vor einem neuen Problem stehst, entscheide zuerst, welche Antwort du brauchst. Musst du die Ursachen finden, einen Arbeitsplan erstellen oder verschiedene Optionen durchdenken? Wähle dann Why, What oder How, um dieses Ziel zu erreichen. Baue deinen ersten Baum. Suche als nächstes nach einem fehlenden Zweig und einem Zweig, der eine andere Idee wiederholt, bevor du den Baum verwendest.
Wenn ein Produktteam diese Methode immer wieder anwenden möchte, sollte es nicht jeden Produktmanager bitten, den gesamten Prozess von Hand aufzubauen und alle Regeln zu prüfen. KI kann diese wiederholte Arbeit erledigen, damit das Team mehr Zeit für die Lösung des Problems aufwenden kann.
Gib deinem Team diese Fähigkeit
mckinsey-issue-tree ist eine der 243 PM-Fähigkeiten in AI PM OS, dem gemeinsamen Betriebssystem für Produktteams. Es läuft in Claude Code, Cowork oder Cursor und wird mindestens alle zwei Wochen aktualisiert, Version 2.5.
Jeder PM behält seinen eigenen Produktkontext, während das Team Workflows und Überprüfungsstandards teilt, sodass die Problembäume und Analysepläne in deinem Produkt, deinen Nutzern und deinen tatsächlichen Einschränkungen verankert sind, anstatt nur allgemeine PM-Ratschläge zu sein.
Du musst nichts davon zusammensetzen. AI PM OS integriert mckinsey-issue-tree in die Betriebsebene des Teams, zusammen mit Workflows für Strategie, Forschung, Entscheidungen, Stakeholder-Arbeit und Messung.
