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.
Frequently asked questions
Are premortem and postmortem really the same technique?
They share the same psychological move — working backwards from a stated failure to find its causes — but they apply at opposite ends of a project. A premortem asks 'imagine this failed in 6 months; what went wrong?' before work starts, to surface risks while they're cheap to address. A postmortem asks 'this failed; what caused it?' after work ends, to extract lessons for next time. Same technique, different timing, different value.
Why is the premortem more effective than a standard risk register?
Standard risk registers list risks abstractly ('integration delays', 'scope creep') which the team has heard before and tunes out. A premortem forces the team to imagine the actual failure in concrete detail — 'we shipped on time but no one used the feature' — which produces specific, addressable risks. The framing flip ('it failed; why?') reliably surfaces concerns people would hedge if asked 'what could go wrong?'.
Should postmortems be blameless?
Yes — blameless postmortems are now the industry standard. The goal is to extract systemic lessons, which requires people to volunteer what they actually did and decided. If naming individuals carries consequences, the answers get sanitized and the lessons are lost. Blameless does not mean accountability-free at the organizational level — it means the postmortem itself is not the venue for personal consequences.
When do you not need a premortem?
Skip premortems for low-stakes reversible decisions where the cost of being wrong is small. They're worth the 60–90 minutes when the decision is hard to reverse, expensive to redo, or surfaces strong but unsaid disagreement on the team. A weekly status meeting doesn't need a premortem; a major launch, acquisition, or org change does.