Premortem vs postmortem: opposite directions, complementary tools
A premortem imagines failure before it happens. A postmortem investigates failure after. Same psychological technique (working backwards from failure), different timing — and different teams use them for different reasons.
The word similarity hides important differences. Both work backwards from failure; the difference is whether the failure has happened yet.
At a glance
| Premortem | Postmortem | |
|---|---|---|
| When | Before the project ships | After a failure has occurred |
| Question | "Imagine the project failed — what caused it?" | "It failed. What actually caused it?" |
| Output | Risk mitigation plan | Root-cause analysis + action items |
| Time budget | 45–60 minutes | 60–90 minutes |
| Emotional load | Low (hypothetical) | High (real consequences) |
| Origin | Gary Klein, 2007 | Engineering / aviation / medicine for decades |
When to use a premortem
You're about to make a decision or ship something that's hard to reverse. The team has been working forward for weeks/months and is emotionally invested. A premortem inverts the perspective to surface risks that forward planning misses.
Typical uses:
- 1 week before a product launch
- Start of a multi-quarter initiative
- After a strategy decision but before the budget locks
- Late-stage M&A diligence
When to use a postmortem
Something has gone wrong. The team needs to understand what happened, name root causes, and decide what to change so the same failure doesn't recur. Postmortems are also called "incident retros" or "after-action reviews".
Typical uses:
- After a production outage
- After a launch that missed targets badly
- After a hire that didn't work out
- After a quarter where OKRs missed by >50%
The relationship
A team running both produces a tight learning loop:
- Premortem surfaces predicted failure modes → produces mitigations
- Project ships → some predicted failures avoided, others materialize
- Postmortem identifies what actually happened
- Compare: which premortem predictions were right? Which were wrong? Which failures were unpredicted?
Teams that do this loop consistently get progressively better at premortems — they learn which categories of risk they tend to underweight.
Both share one critical mechanic
Both use the same psychological move: make the abstract risk concrete by imagining (or recovering) the failure state.
Forward-only planning surfaces optimistic risks ("we might be slightly late") because the unconscious bias is to defend the plan. Backward thinking from failure surfaces specific risks ("user data was corrupted in week 2 because nobody had run the migration script on production volumes") because the unconscious bias flips — once failure is the frame, the mind searches for plausible causes.
This is why a premortem and a postmortem feel similar to participate in. Both ask "given that this failed, what happened?". The premortem is hypothetical, but the cognitive mechanism is identical.
Common failure mode (in both)
The same one: the project owner refuses to engage with the conclusions. In a premortem, the owner defends against every imagined failure ("that won't happen"). In a postmortem, the owner deflects blame to external factors.
Both are signs the team doesn't have the psychological safety to do the exercise honestly. Fixing that is upstream of any framework.
Which to do first?
A new team running both for the first time should do a premortem before the next major project ships, then commit to a postmortem after. The comparison is where the learning compounds.
Open the premortem worksheet → or read the Academy guide. For postmortem, the catalog entry has the standard template.