mickzijdel Premortem
A premortem is the opposite of a postmortem: imagine the plan has already failed, then work backwards to find out why — before you've spent anything. It surfaces failure modes and hidden assumptions that optimism hides. This is destructive stress-testing; use [[brainstorming]] when you instead need to generate options.
Procedure
- State the plan and a horizon. One or two sentences, plus a date ("in 6 months").
- Assert the failure. "It is now 6 months later and this was a clear, costly failure." Write from that future as fact, not possibility — this licenses honesty that "what could go wrong?" suppresses.
- Brainstorm causes across categories. Force coverage, don't just list the obvious:
- Technical — it didn't scale, broke under load, the approach didn't fit the problem
- Scope/effort — far bigger than estimated, never finished, gold-plated the wrong part
- Dependencies — an external API/library/team/data source failed or changed
- Ops/people — nobody maintained it, the one person who understood it left, no one adopted it
- Data — wrong/missing/dirty data, migration corrupted state
- Security/safety — a hole, a permission, a destructive action with no guard
- Rank by likelihood × impact. Sort so the few that matter rise to the top.
- Surface hidden assumptions. For each top risk, name the belief it depends on ("assumes the API stays stable", "assumes one repo per agent"). These are the load-bearing guesses.
- Revise. Produce a changed plan that defuses the top risks, plus early-warning signals to watch so you catch the failure early if it starts.
Output
- Plan & horizon
- Top failure modes (ranked, with likelihood × impact)
- Hidden assumptions behind each
- Revised plan + early-warning signals to monitor
Common mistakes
- Listing vague risks ("it might be hard") instead of specific, mechanism-level failures.
- Only covering the technical category — most real failures are scope, people, or dependency.
- Stopping at the risk list. The value is the revised plan and the signals to watch.
- Treating it as theater — if every risk is "low likelihood", you're not being honest about the failure.