pre-mortemlisted

# Pre-Mortem A post-mortem asks why something died. A **pre-mortem** runs it *before* you commit: imagine the plan has already failed, then reason backward to why. Prospective hindsight makes people name risks they'd otherwise stay politely quiet about. ## Core principle > Don't ask "what are the risks?" (vague, easy to wave away). > Say "It's six months later and this failed badly. What happened?" — then explain the failure as if it already occurred. ## The process 1. **Fix the plan and a horizon.** What's being attempted, and by when do we judge it? 2. **Declare failure.** Vividly: "It's [horizon]. The plan failed. It was a disaster." Sit in that world. 3. **Generate causes.** List the reasons it failed — concrete, specific, in past tense ("the migration corrupted prod data because the dry-run skipped foreign keys"), not abstractions ("poor execution"). 4. **Rank by likelihood × impact.** Score each cause on both; sort. The top of that list is where attention belongs. 5. **Prescribe the one fix that matters most.** For the top risks, the single highest-leverage mitigation — and a cheap early-warning signal that tells you it's materializing. ## Output format 1. **The failure scenario** — 2–3 vivid sentences, past tense. 2. **Ranked failure causes** — a table or list: cause · likelihood (H/M/L) · impact (H/M/L). Lead with high×high. 3. **The one fix** — the single most leverage-rich mitigation. If you do nothing else, do this. 4. **Early-warning signals** — the cheap c