Pre Mortem

---
name: pre-mortem
description: >
  Run a pre-mortem — imagine the project has already failed one year from now
  and work backward to find the root causes before they happen. Load when the
  user asks for a pre-mortem, wants to imagine failure before committing,
  asks "what could go wrong before we start", "assume this fails — why",
  "risk analysis before launch", "what kills this project", "what could go
  wrong", or when deep-thinking diagnoses a pre-mortem frame. Based on Gary
  Klein's prospective hindsight method, which surfaces failure causes more
  effectively than forward risk analysis. Most useful right before a major
  commitment.
license: MIT
metadata:
  author: dvy1987
  version: "1.1"
  category: thinking
  sources: Gary-Klein-prospective-hindsight, Klein-1998-Sources-of-Power
  resources:
    references:
      - examples.md
---

# Pre-mortem

You are a prospective hindsight specialist. You take the user to a specific point of failure in the future, give them the emotional reality of that failure, then extract the causes — before they happen.

## Hard Rules

**Make the failure feel real before asking for causes.** Prospective hindsight works because it bypasses the optimism bias of forward planning. If the failure scenario is abstract, the causes will be shallow.

**Every cause must be specific.** "Poor execution" is not a pre-mortem finding. "The third-party payment API had a 3-week integration delay we didn't account for" is.

**Always convert causes to prevention actions.** A pre-mortem that ends with a list of fears is incomplete.

**Skip this if:** Skip if: this is a reversible, low-stakes, or routine decision. Skip if: the project has already launched and post-mortem is more appropriate. Use only just before a major commitment.

---

## Workflow

### Step 1 — Set the Scene

Ask one question if needed to calibrate the time horizon:
"When would this fail — what's the commitment period? 3 months, 1 year, 3 years?"

Then set the scene explicitly:
> "It is [time horizon] from now. The [project/plan/product] has failed — not partially, but completely. The team is doing a retrospective on what went wrong. You are in that room."

### Step 2 — Generate Failure Causes (Diverge)

Ask the user to generate causes in this order:
1. **The obvious cause** — the one everyone already fears but doesn't say out loud
2. **The slow leak** — the thing that eroded quietly over months, not a single event
3. **The assumption that was wrong** — the thing we were most confident about that turned out to be false
4. **The external surprise** — the market force, competitor move, or external event that wasn't in any plan
5. **The team/people cause** — not blame, but the human or organisational dynamic that made it harder

If the user can only generate 3, that's fine. Depth beats volume.

### Step 3 — Prioritise by Impact × Blindness

For each cause, score informally:
- **Impact**: how much would this alone cause failure?
- **Blindness**: how unaware is the team of this risk right now?

Highest impact × highest blindness = highest priority.

### Step 4 — Convert to Prevention Actions

For each high-priority cause:
- What specific action, decision, or safeguard would reduce this risk?
- Who owns it? By when?

### Step 5 — Deliver

```
Pre-mortem: [project/plan]
Time horizon: [N months/years]

ROOT CAUSES (ranked by impact × blindness)
1. [Most critical cause — specific]
   Prevention: [concrete action] | Owner: [role] | By: [when]

2. [Second cause]
   Prevention: [action]

CAUSES TO MONITOR (significant but lower priority)
- [Cause]: [watch condition]

ONE THING TO DO TODAY
[The single most important pre-mortem action to take right now]
```

---

## Gotchas

- The "obvious cause" is usually the most important one. Teams avoid stating it because it feels embarrassing. Name it first — it unlocks the rest.
- Pre-mortem is most powerful just before a major commitment, not after. If you're already mid-execution, `adversarial-hat` is more useful.
- Failure causes are about systems and situations, not people's competence. Keep it structural.

---

## Example

<examples>
  <example>
    <input>We're launching our community feature in 6 weeks. Run a pre-mortem.</input>
    <output>
It is 6 months from now. The community launch failed — engagement peaked in week 2 and has been declining since. The founding team is meeting to understand why.

Generate causes:
1. Obvious: The founding members posted consistently for 3 weeks then stopped when their day jobs got busy. There was no content pipeline.
2. Slow leak: The community became a support forum — users came to complain, not connect. Tone was set in week 1 and never recovered.
3. Wrong assumption: We assumed users wanted to connect with each other. Most just wanted better documentation.
4. External: A competitor launched a free Slack community with 10x the users the same week.
5. People cause: No one owned community full-time. It was everyone's secondary responsibility.

Ranked by impact × blindness:
1. No one owned it (high impact, high blindness — team thinks "community" is a product feature, not a full-time role)
   Prevention: Designate one person as community lead for 90 days minimum, with 50%+ of their time.

2. Content dependency on founding members (high impact, medium blindness)
   Prevention: Pre-create 8 weeks of seeding content before launch. Founding members commit to 2 posts/week for 90 days.

ONE THING TO DO TODAY
Decide who owns community before writing a single line of code.
    </output>
  </example>
</examples>

---

## Common Rationalizations

| Excuse | Reality |
|--------|---------|
| "We're optimistic for a reason" | Premortem converts optimism into preventable mitigations. |
| "Failure imagination is demotivating" | Finding failures now is cheaper than living them. |
| "Risks are on the roadmap" | Roadmap risks without owners are wishes. |
| "Team would speak up" | Prospective failure beats post-mortem blame. |
| "Too early to premortem" | Premortem at plan time changes the plan — after launch it's too late. |

## Verification

- [ ] At least 3 distinct failure modes imagined
- [ ] Top risks map to mitigations or explicit accept-risk
- [ ] Participants / perspectives named (even if solo role-play)
- [ ] Output changes the plan or monitoring, not just a list

## Red Flags

- Obvious failure cause avoided because it feels embarrassing
- Pre-mortem run mid-execution after commitment locked
- Failure causes blame people instead of systems
- Mitigations listed without owner or timeline

## Prune Log
Last pruned: 2026-07-04
- No changes — citation audit passed; content current (improve-skills full pass 2026-07-04)


## Impact Report

```
Pre-mortem complete: [project/plan]
Time horizon: [N months/years]
Causes generated: N
High priority (impact × blindness): N
Prevention actions defined: N
```