Pre Mortem

---
name: pre-mortem
description: Imagine the plan has already failed, then work backwards to why. Runs Gary Klein's pre-mortem on a project, launch, strategy, hire, investment or personal decision - vivid failure stories from several angles, ranked by likelihood and impact, early-warning signals, prevention, contingencies, tripwires (kill criteria) and the assumptions to test this week. Can also produce a facilitation script for running a pre-mortem with a team. Use when the user asks what could go wrong, wants to stress-test or de-risk a plan, is about to commit to something big, or says pre-mortem, risk review, 事前验尸, 风险评估, 复盘前置, 这个计划有什么坑.
license: MIT
metadata:
  author: MbappeWU
  version: "1.1.0"
---

# Pre-mortem

A post-mortem explains why something died. A pre-mortem does it while there's still time to change the outcome. Research on "prospective hindsight" (Mitchell, Russo & Pennington, 1989) found that imagining an event *has already happened* raises the ability to identify reasons for it by about 30%. Gary Klein turned that into the pre-mortem.

Your job: make the failure feel real enough that the user can see it coming, then turn it into concrete defenses.

## Rules

1. **Assume failure is certain.** Never debate *whether* it fails. It has failed. The only question is why.
2. **Stories, not risk registers.** Each failure is told as a short, specific story with a cause, a sequence and a moment when someone could have noticed.
3. **Specific to this plan.** Generic risks ("scope creep", "lack of communication") are banned unless tied to a concrete mechanism in *this* plan.
4. **Find the silent killers.** The deadliest failures are slow and invisible: morale drain, a key person quietly disengaging, a metric that looks fine while the real one decays.
5. **Every top risk ends in an action** with an owner and a date, or it's just worry.
6. **Mirror the user's language.** 用户用中文，就全程中文。
7. **Don't invent facts** about their organization. Ask, or state the assumption explicitly.

## Workflow

### 1. Frame (ask at most three questions, in one message)
- **The plan:** what exactly is being done (or read the doc/files if you can).
- **Success:** what does success look like, concretely, and by when?
- **Horizon:** when would we know it failed? (Default: the success date.)

Also useful if cheap to get: budget, team, key dependencies, what the user is most worried about.

### 2. Time-travel
Open with one line that sets the scene, dated at the horizon:
> *"It's [date]. [Plan] has failed, and not narrowly. Here is what happened."*

### 3. Failure stories
Write 6–10 failure stories, each from a different angle. Pick the angles that fit:

- **Execution:** the plan was right but the doing broke (capacity, dependencies, sequencing).
- **Customer / market:** they didn't want it, didn't switch, or wanted something else.
- **People & org:** key person left, incentives misaligned, the team never bought in, a stakeholder quietly blocked it.
- **Tech / operations:** it didn't scale, broke in production, integration hell.
- **Money:** cost overrun, revenue later than planned, funding pulled.
- **Competition & external:** a competitor moved, regulation changed, the economy turned.
- **Self-deception:** the assumption everyone believed and nobody checked.
- **Success disaster:** it worked too well and something else broke.

Each story, in this shape:

> **📰 Headline:** a short, newspaper-style headline of the failure
> **What happened:** 2–4 sentences with a concrete causal chain.
> **First visible signal:** the earliest moment someone *could* have noticed, and what they would have seen.
> **Likelihood** 1–5 · **Impact** 1–5

### 4. Rank and pick the top 3–5
Rank by Likelihood × Impact, and flag any **silent killer** (hard to see until too late) as top priority even if its score is lower.

### 5. Defenses for each top risk
- **Prevent:** what to change in the plan *now* to make this less likely.
- **Detect:** the leading indicator to watch, with a threshold ("weekly active pilots < 3 by week 4").
- **Respond:** the contingency if it happens anyway.
- **Owner and date.**

### 6. Tripwires (kill criteria)
Write 2–4 pre-committed decision rules, set now while heads are cool:
> "If [measurable condition] by [date], we [stop / pivot / cut scope / escalate]."

These protect against the sunk-cost fallacy later.

### 7. Assumptions to test this week
List the 3–5 assumptions the plan depends on most, the cheapest test for each (a call, a prototype, a data pull), and what result would change the plan.

### 8. Verdict
End with one paragraph: is the plan **Go**, **Go with changes** (list them) or **Rethink**? Say which single change most improves its odds.

If you can write files, save the result as `pre-mortem-<topic>-<YYYY-MM-DD>.md`.

## Team mode

If the user wants to run a pre-mortem *with their team*, produce a facilitation kit instead of (or in addition to) the analysis:

1. **Invite text** (2–3 sentences): purpose, 45 minutes, psychological-safety framing ("we're not criticizing the plan; we're protecting it").
2. **Agenda** (45 min): brief the plan (5) → "it failed; write why, alone, in silence" (8) → round-robin, one reason per person per round, no debate (15) → cluster and vote (7) → defenses for the top 3 (10).
3. **Facilitator lines** for the tricky moments: the senior person going first (don't let them), people defending the plan ("park it, we're in failure-land"), vague reasons ("what exactly happened, and when?").
4. **Template** for capturing the output (the table from steps 3–6).

## Personal decisions

For personal plans (a career move, a big purchase, a move abroad), use the same method with personal angles: money, relationships, health and energy, identity ("I stopped enjoying it"), opportunity cost, and reversibility. Be direct but humane.