What it is
A pre-mortem is a meeting you hold before a project begins, in which the team is asked to imagine that the project has already failed — spectacularly — and to brainstorm the reasons why. The framework comes from research psychologist Gary Klein, who described it in a 2007 Harvard Business Review piece. The technique is a deliberate counter to optimism bias: people are much better at criticizing a plan when they're told to assume it's already broken than when asked to flag risks in the abstract.
It's prospective hindsight — borrowing the clarity that comes after a failure and applying it before launch, while you can still change things.
When to use it
A pre-mortem is most valuable on commitments large enough that failure would hurt, but small enough that you can still alter course. Reach for it when:
- Kicking off a quarter-plus initiative with multiple teams
- Greenlighting a product launch with a non-trivial budget
- Signing a long-term vendor or partnership contract
- Replatforming or migrating a core system
- Hiring for a senior role where a bad outcome takes a year to unwind
Skip it for small, reversible decisions — the overhead isn't worth it.
How to run it
- Get the full project team plus 1–2 outside skeptics in a room (or on a call) for 60–90 minutes.
- Set the scene: "It's 12 months from now. The project has been a complete failure. The launch missed every target. Take three minutes and write down, individually, every reason you can think of for why."
- Have each person write silently. Silent writing prevents the loudest voice from anchoring the room and gives introverts equal weight.
- Round-robin the reasons. Capture every one — don't debate yet.
- Cluster duplicates and group by theme (product, team, market, dependencies, execution).
- Vote on the top 5–7 most likely failure modes.
- For each, assign a specific mitigation, an owner, and a date to revisit.
- Save the list. Review it at the project's midpoint — a pre-mortem that's never reread is a pre-mortem that didn't happen.
Common pitfalls
The most common failure mode is running it as a checkbox. The team gathers, dutifully lists three generic risks ("scope creep," "communication issues," "resource constraints"), and goes back to work. A real pre-mortem produces specific failure stories with named actors: "the data engineer leaves in Q2 and nobody can debug the pipeline," not "key person risk."
Second pitfall: holding the pre-mortem too late. Once people have publicly committed to a plan, they'll defend it. Schedule the pre-mortem before the project gets a name and a kickoff deck.
Third: skipping the mitigation step. The point isn't catharsis; it's changing the plan. If the list of failure modes doesn't produce at least three concrete edits to the project plan, you've held a venting session.
Variations
A close relative is the Murder Board — a more adversarial review where outside reviewers actively try to dismantle the plan rather than imagining its eventual failure. Use a Murder Board when you have a polished proposal and want it stress-tested; use a Pre-mortem when the plan is still forming. For the difference between a premortem and a postmortem (the meeting you hold after failure has occurred), see Premortem vs Postmortem. Another adjacent technique is Red Teaming, common in security and defense, which assigns a sub-team to play the adversary continuously rather than in a single meeting. For most product and ops contexts, the one-hour pre-mortem is the right cost-to-value point — light enough to actually run, structured enough to produce changes.
Playbooks by industry
- Premortem for a SaaS launch — the premortem applied to a product launch, with launch-specific failure modes