--- name: premortem description: "Führt ein Premortem auf einen Plan, Launch, ein Produkt, eine Einstellung, eine Strategie oder Entscheidung durch. Nimmt an, die Sache ist in der Zukunft schon gescheitert, und arbeitet rückwärts jeden Grund heraus, warum. Liefert einen revidierten Plan mit offengelegten blinden Flecken, Kill-Kriterien und Pre-Launch-Checkliste. MANDATORY TRIGGERS: 'premortem das', 'mach ein premortem', 'premortem für', 'was killt das', 'stress-test diesen plan', 'wo bricht das', 'finde die blinden flecken', 'was übersehe ich hier'. STRONG TRIGGERS: 'was könnte schiefgehen', 'übersehe ich was', 'poke holes in das', 'devils advocate das', 'zerpflück diesen plan', 'wo geht das schief'. NICHT triggern bei einfachen Feedback-Anfragen, Faktenfragen, reinem Text-Editing oder llm-council/panel-Anfragen. DO trigger wenn jemand einen Plan oder ein Commitment hat, bei dem ein Fehler teuer wird." --- # Premortem Ein Premortem ist das Gegenteil eines Postmortems. Statt nach dem Scheitern zu analysieren, was schiefging, nimmst du vorher an, es sei schon gescheitert, und findest heraus warum. Bevor du startest. Die Methode stammt vom Psychologen Gary Klein, veröffentlicht in der Harvard Business Review. Daniel Kahneman (Nobelpreisträger, "Schnelles Denken, langsames Denken") nannte sie seine mit Abstand wertvollste Entscheidungstechnik. Google, Goldman Sachs und Procter & Gamble nutzen sie vor großen Entscheidungen. Der Kern-Trick: Fragst du Leute "was könnte schiefgehen?", bekommst du vorsichtige, verwaschene Antworten. Sagst du "das ist gescheitert, erklär mir warum", schaltet das Gehirn in den Erzähl-Modus und produziert viel konkretere, ehrlichere, kreativere Gründe. Forscher in Wharton und Cornell nennen das "prospective hindsight" und haben gezeigt, dass es die Fähigkeit, künftige Ursachen zu erkennen, deutlich erhöht. Warum das mit AI besonders wichtig ist: Ein Sprachmodell tendiert dazu, zustimmend und optimistisch zu antworten. Fragst du "ist das ein guter Plan?", findet es Gründe, ja zu sagen. Das Premortem bricht dieses Muster, indem es den Rahmen umdreht: "Das ist tot, erklär wie es starb." Ab da sucht die AI nicht mehr nach Gründen, warum dein Plan funktioniert, sondern erklärt, wie er auseinanderfiel. Wichtig, ehrlich gesagt: Das killt nicht deinen Optimismus, es kalibriert ihn. Ein Premortem ersetzt keine Entscheidung. Es macht sie robuster. --- ## Wann ein Premortem sinnvoll ist Gute Premortem-Ziele: - Ein Produkt oder Feature, das du bauen willst - Ein Launch-Plan mit Geld oder Reputation im Spiel - Eine Preisänderung oder ein Geschäftsmodell-Wechsel - Eine Einstellung, die du machen willst - Ein Strategie- oder Positionierungs-Pivot - Eine Partnerschaft oder ein Deal, den du prüfst - Jedes Commitment, bei dem ein Fehler teuer wird Schlechte Premortem-Ziele: - Vage Ideen ohne konkreten Plan (erst beim Planen helfen, dann premortem) - Fragen mit einer richtigen Antwort (einfach beantworten) - Wunsch nach kreativem Feedback auf einen Draft (das ist Editing, kein Premortem) - Entscheidungen, die schon getroffen und unumkehrbar sind (ein Premortem hilft nur, solange du noch umlenken kannst) --- ## Kontext sammeln (die Mindestschwelle) Ein Premortem ist nur so gut wie der Kontext, auf dem es läuft. Vage Eingaben produzieren vage Szenarien, die niemandem helfen. Bevor du startest, brauchst du eine Mindestmenge an Kontext. ### Schritt 1: nach vorhandenem Kontext scannen Bevor du irgendetwas fragst, schau nach Kontext, der schon da ist: - **Das aktuelle Gespräch.** Vielleicht wurde der Plan, Launch oder die Entscheidung vorhin schon besprochen. Lies zurück und zieh das Relevante raus. - **Der Workspace.** Scanne kurz nach Dateien mit relevantem Kontext: `CLAUDE.md`, ein `memory/`-Ordner, explizit referenzierte Dateien, Briefs oder Pläne zum Thema. `Glob` + schnelle `Read`-Calls, nicht mehr als 30 Sekunden. Du suchst die Dateien, die die Szenarien in der Realität verankern. ### Schritt 2: prüfen, ob der Kontext reicht Du brauchst drei Dinge: 1. **Was ist es?** Ein klares Verständnis der Sache (Produkt, Launch, Einstellung, Preisänderung, Strategie). Du musst sie dem User in einem Satz zurückspiegeln können. 2. **Für wen / wen betrifft es?** Zielgruppe, Kunde, Team, Stakeholder. Szenarien hängen stark davon ab, wer beteiligt ist. 3. **Wie sieht Erfolg aus?** Das gewünschte Ergebnis. Scheitern wird definiert, indem man Erfolg umkehrt. Ohne Erfolgskriterium kein Scheitern-Kriterium. ### Schritt 3: Lücken im Gespräch füllen Hast du alle drei, leg direkt los. Frag nichts Unnötiges. Fehlt eins oder mehr, frag zuerst nach dem wichtigsten fehlenden Stück. Eine Frage nach der anderen. Nach jeder Antwort prüfen, ob es jetzt reicht. Nie mehr fragen als nötig. Konversationell, nicht wie ein Formular. Was du aus dem Kontext erschließen kannst, erschließt du, statt zu fragen. Fokus-Fragen (Beispiele): - "Was genau willst du launchen/bauen/entscheiden?" - "Für wen ist das?" - "Wie sieht ein Gewinn hier aus?" --- ## So läuft eine Premortem-Session ### Schritt 1: den Rahmen setzen (mit adaptivem Zeithorizont) Setz den Premortem-Rahmen explizit. Und **wähl den Zeithorizont passend zur Entscheidung**, statt stumpf "6 Monate" zu nehmen: - Launch / Kampagne: 3 Monate - Produkt / Feature: 6 Monate - Einstellung / Partnerschaft: 12 Monate - Strategie / Positionierung: 12 bis 18 Monate Im Zweifel den User kurz fragen oder den plausibelsten Horizont wählen und benennen. Dann: "OK, ich habe genug Kontext. Wir machen das Premortem. Prämisse: Es ist [Zeithorizont] später. [Der Plan] ist gescheitert. Vorbei. Wir schauen zurück und versuchen zu verstehen, was schiefging." Dieser Frame ist der psychologische Mechanismus. Ohne ihn fällt die Analyse in höfliche Risiko-Einschätzung zurück statt ehrlicher Scheiter-Erklärung. ### Schritt 2: Scheiter-Gründe generieren (das rohe Premortem) Führ das rohe Premortem als eine umfassende Analyse durch: "Dieser Plan ist [Zeithorizont] später gescheitert. Generiere jeden echten Grund, warum er gestorben sein könnte. Umfassend. Konkret. Jeden Grund in den echten Details des Plans verankert. Kein Auffüllen mit schwachen Gründen, kein zu frühes Aufhören, wenn es mehr gibt." Jeder Scheiter-Grund muss sein: - **Spezifisch für diesen Plan** (kein Allgemeinplatz, der auf alles passt) - **In echten Details verankert**, die der User gegeben hat - **Eine echte Bedrohung** (keine Kleinigkeit, kein extremer Edge-Case) Manche Pläne haben 4 echte Failure-Modes, andere 9. Die Zahl ist, was für diesen Plan real ist. Nicht auffüllen, nicht künstlich kürzen. **Optional zur Abdeckung (empfohlen bei komplexen Plänen):** geh die Gründe einmal durch diese Linsen, um blinde Flecken zu vermeiden. Nur Linsen behalten, die echte Failure-Modes liefern, nicht pro Linse einen erzwingen: Nachfrage / Markt · Ausführung / Operativ · Finanzen / Unit Economics · Menschen / Team · Timing / Reihenfolge · Wettbewerb / Alternativen · versteckte Annahme. ### Schritt 3: pro Scheiter-Grund tief gehen Jetzt geht jeder Grund einzeln in die Tiefe. **Mit Sub-Agent-Zugriff (Claude Code / Cowork): den ganzen Fan-out parallel.** Spawne pro Scheiter-Grund einen Sub-Agent, alle gleichzeitig. Jeder Agent bearbeitet seinen zugewiesenen Grund unabhängig. Das ist schneller und verhindert, dass frühe Antworten die späteren einfärben. **Ohne Sub-Agent-Zugriff (normaler Chat): Single-Context-Fallback.** Geh die Gründe der Reihe nach durch, jeder in einem eigenen, klar abgetrennten Block, mit derselben Tiefe. Behandle jeden Block, als wüsstest du von den anderen nichts, um Einfärbung zu vermeiden. **Prompt pro Grund (Template):** ``` Du bist Ermittler in einer Premortem-Analyse. Dir ist genau ein Scheiter-Grund zugewiesen. Der Plan: --- [voller Kontext: was es ist, für wen, wie Erfolg aussieht, plus relevanter Workspace-Kontext] --- PREMORTEM-RAHMEN: Es ist [Zeithorizont] später. Dieser Plan ist gescheitert. DEIN ZUGEWIESENER SCHEITER-GRUND: [der spezifische Grund aus Schritt 2] Deine Aufgabe: geh bei genau diesem einen Scheitern in die Tiefe. Schreib die Geschichte, wie es tatsächlich passierte. Konkret. Mit Details aus dem Plan. So real wie eine echte Fallstudie. Deine Ausgabe: 1. DIE SCHEITER-GESCHICHTE: 2 bis 3 Absätze, wie dieses Scheitern ablief. Details aus dem Plan. Benenn die konkreten Momente, an denen es kippte, und warum. 2. DIE ZUGRUNDELIEGENDE ANNAHME: Das eine, was der User für selbstverständlich hielt und was dieses Scheitern erst möglich machte. Ein Satz. 3. FRÜHWARNZEICHEN: 1 bis 2 konkrete, beobachtbare Signale, an denen der User erkennt, dass dieser Failure-Mode anläuft. Sichtbar oder messbar, keine vagen Gefühle. Maximal 300 Wörter. Direkt. Nicht relativieren. Nicht schönreden. ``` ### Schritt 4: der adversariale Gegen-Check ("Was haben wir übersehen?") Bevor du synthetisierst, ein zusätzlicher Durchlauf, dessen einziger Job ist, das Scheitern zu finden, das die anderen nicht gesehen haben. Das fängt oft den eigentlichen Killer. ``` Hier ist ein Plan und eine Liste von Scheiter-Gründen, die schon gefunden wurden. [Plan + bisherige Gründe] Deine Aufgabe: sei der Skeptiker der Skeptiker. Nenn den einen Failure-Mode, der in dieser Liste FEHLT und der den Plan am ehesten wirklich killt. Wenn die Liste vollständig ist, sag das ehrlich. Wenn nicht, beschreib den fehlenden Grund konkret und warum er übersehen wurde. ``` Findet der Gegen-Check einen echten neuen Grund, behandle ihn wie die anderen (Schritt 3). ### Schritt 5: Synthese Lies alle Deep-Dives und produziere die Synthese. Das ist das Produkt. Die meisten lesen die Synthese und überfliegen die einzelnen Karten. Mach sie konkret und umsetzbar. **PREMORTEM-REPORT** 1. **Der wahrscheinlichste Fail** — Welches Szenario ist am wahrscheinlichsten? Warum? Das zuerst angehen. 2. **Der gefährlichste Fail** — Welches Szenario würde den größten Schaden anrichten, selbst wenn es unwahrscheinlicher ist? Dagegen versichern. 3. **Likelihood x Impact** — Ordne jeden Failure-Mode grob in eine 2x2 ein (Wahrscheinlichkeit niedrig/hoch, Schaden niedrig/hoch). Was oben rechts landet (wahrscheinlich + hoher Schaden), hat Vorrang. 4. **Die versteckte Annahme** — Über alle Analysen hinweg: die eine größte Annahme, die der User wahrscheinlich nie hinterfragt hat. Hier lebt oft der eigentliche Wert des Premortems: das, was so selbstverständlich ist, dass man vergaß, dass es eine Annahme war. 5. **Der revidierte Plan** — Konkrete Änderungen, die den Plan robuster machen. Nicht "denk über dein Pricing nach", sondern "teste Pricing bei X mit 20 Leuten, bevor du dich öffentlich festlegst." Jede Revision mappt direkt auf ein Szenario. 6. **Kill-Kriterien** — 2 bis 3 vorab festgelegte Schwellen, ab denen du stoppst oder umlenkst. "Wenn bis [Datum] nicht [messbares Signal], dann [Stopp / Pivot]." Das macht aus Erkenntnis eine Entscheidungsregel, bevor die Emotion im Weg steht. 7. **Pre-Launch-Checkliste** — 3 bis 5 konkrete Dinge, die vor dem Start verifiziert, getestet oder aufgesetzt werden. Jedes verhindert oder erkennt einen der Failure-Modes. ### Schritt 6: den Report als Datei erzeugen Erzeug einen visuellen HTML-Report und speichere ihn im Workspace. **Datei:** `premortem-report-[timestamp].html` Eine einzelne, self-contained HTML-Datei mit inline-CSS. Design: - Dunkler Hintergrund (#0a0e1a oder ähnlich), klare Typo, gut scanbar - Die Synthese (wahrscheinlichster / gefährlichster Fail, Likelihood-x-Impact-2x2, versteckte Annahme, revidierter Plan, Kill-Kriterien, Checkliste) prominent oben, das lesen die meisten zuerst - Pro Scheiter-Grund eine Karte mit Grund als Header, Scheiter-Geschichte, zugrundeliegende Annahme, Frühwarnzeichen. Distinkte Akzentfarben pro Karte, damit scanbar - Ein sichtbarer Schwere-/Wahrscheinlichkeits-Indikator pro Failure-Mode - Übersicht: wie viele Ermittler liefen und was sie fanden, als Grid - Footer mit Timestamp und was premortemt wurde Öffne die Datei nach dem Erzeugen. ### Schritt 7: das Transkript speichern Speichere das volle Transkript als `premortem-transcript-[timestamp].md` am selben Ort: gesammelter Kontext (was, wer, Erfolgskriterium), rohe Scheiter-Gründe, alle Deep-Dives, der Gegen-Check, die volle Synthese. --- ## Output-Format Jede Session produziert zwei Dateien: ``` premortem-report-[timestamp].html # visueller Report zum Scannen premortem-transcript-[timestamp].md # volles Transkript zum Nachlesen ``` Zusätzlich eine knappe Zusammenfassung im Chat: der wahrscheinlichste Fail, die versteckte Annahme und die eine wichtigste Revision. Maximal drei Sätze. Die Details stehen im Report. (Im reinen Chat ohne Datei-Zugriff: Report + Synthese direkt in die Antwort, ohne Speichern.) --- ## Beispiel: Premortem für einen Produkt-Launch **User:** "premortem das: Ich launche einen 297-Euro-Live-Workshop zu Claude Cowork für Marketing-Teams. 50 Plätze. Zielgruppe: Marketing-Manager in Firmen mit 10 bis 50 Leuten." **Das rohe Premortem findet 6 Gründe:** 1. Marketing-Manager dieser Firmengröße brauchen eine Freigabe, um 297 Euro für Weiterbildung auszugeben. Diese Reibung ist nicht eingeplant. 2. "Claude Cowork fürs Marketing" ist ein tool-spezifischer Pitch in einem Markt, in dem die meisten Manager noch prüfen, ob AI für sie überhaupt relevant ist. 3. Die Zielgruppe, die tatsächlich kauft, sind vielleicht Solopreneure statt Team-Manager. Mismatch zwischen Inhalt und Teilnehmern. 4. Ein Workshop für Marketing-Teams braucht Demo-Umgebungen mit realistischen Daten und Multi-Seat-Setups. Das sind 5 Wochen Prep, nicht die eingeplanten 2. 5. Wenn 60 % Solopreneure sind, resonieren Reviews und Case-Studies nicht mit der Manager-Zielgruppe, die du für künftige Kohorten brauchst. 6. Bei 297 Euro und 50 Plätzen ist der Maximalumsatz 14.850 Euro, was den Prep-Aufwand gegen andere Umsatzquellen vielleicht nicht rechtfertigt. **6 Ermittler gehen unabhängig in die Tiefe** (Geschichte, Annahme, Frühwarnzeichen). **Der Gegen-Check** ergänzt: "Ihr habt die Freigabe-Reibung, aber nicht die Terminfindung. Bei 50 Managern quer durch Firmen ist der Live-Termin selbst der stille Killer der Auslastung." **Synthese:** Wahrscheinlichster Fail = Zielgruppen-Mismatch (du zielst auf Leute, die für 297 Euro eine Freigabe brauchen). Gefährlichster Fail = du ziehst Solopreneure statt Manager, dann passen Testimonials nicht zum eigentlichen Käufer künftiger Kohorten. Versteckte Annahme: "Marketing-Manager in 10-50-Personen-Firmen" ist eine erreichbare Zielgruppe, aber diese Leute identifizieren sich nicht so und hängen nicht am selben Ort rum. Revidierter Plan: erst eine 47-Euro-Pilot-Session für 20 Leute. Damit rausfinden, wer wirklich kauft, und den vollen Workshop für die bauen, die tatsächlich kommen. Kill-Kriterium: "Wenn der 47-Euro-Pilot in 2 Wochen nicht 20 Anmeldungen zieht, kein 297-Euro-Launch." --- ## Wichtige Hinweise - **Mit Sub-Agent-Zugriff immer parallel spawnen.** Sequenziell verschwendet Zeit und lässt frühe Antworten die späten einfärben. - **Immer den Frame explizit setzen.** "Das ist schon gescheitert" ist der Mechanismus, der das Ganze funktionieren lässt. Ohne ihn wird es höfliche Risiko-Einschätzung. - **Umfassend, aber nicht aufgefüllt.** Jeden echten Grund finden. Nicht bei 3 aufhören, wenn es 7 sind. Nicht 7 erzwingen, wenn es 3 sind. - **Die Synthese ist das Produkt.** Konkret und umsetzbar machen. - **Nicht schönreden.** Der ganze Sinn ist, dem User zu sagen, was er nicht hören will, bevor die Realität es tut. - **Der revidierte Plan muss konkret sein.** Jede Revision etwas, das der User diese Woche tun kann. - **Mindestschwelle respektieren.** Ein Premortem auf zu dünnem Kontext produziert generische Failures. Lieber eine Frage mehr als ein schlechtes Premortem. --- ## Abgrenzung zu llm-council und multi-persona-panel Das ist nicht das `llm-council` und nicht das `multi-persona-panel`. Die geben dir mehrere Perspektiven auf eine Entscheidung **jetzt**. Das Premortem schickt die AI in die **Zukunft**, wo die Entscheidung schon gescheitert ist, und arbeitet rückwärts, warum. Anderer psychologischer Mechanismus, anderer Output. Faustregel: Willst du **Perspektiven**, nimm Council (schnell) oder Panel (tief). Willst du wissen, **wie dein Plan stirbt**, nimm das Premortem. Zusammen sind sie ein Set: erst breit denken (Panel), dann härten (Premortem). --- *Made by the AInauten · https://www.ainauten.com · Methode: Gary Klein (HBR) / Daniel Kahneman. Diese Version haben wir für unsere eigenen Entscheidungen gebaut und dann für dich aufbereitet.*