Back to essays
Decision Tools · Operational

The Pre-Mortem

A 30-minute exercise that imagines your project has already failed, asks why, and gives your team permission to finally say the things they've been too polite to mention. Here's how to run one that actually works.

14min readTopicTeam facilitationLevelPractical

In 1989, a psychologist named Gary Klein was studying how experts make decisions under pressure — firefighters, nurses, military commanders — when he became fascinated by a quieter, more preventable kind of failure: the kind that happens in corporate meetings, where smart people sit around a table and commit to plans that everyone privately suspects will fail. The postmortem, he noticed, was already a well-established tool. Teams gather after something went wrong and diagnose the cause. Useful, but late. By the time you're running a postmortem, the money is spent, the product has shipped, the relationships are damaged.

So Klein asked: what if you did the postmortem first? What if, before committing to a plan, the team sat down and pretended it had already failed — spectacularly, publicly, a year from now — and worked backwards from that future to figure out why? He called it the pre-mortem, and in the thirty-five years since, it has become one of the most widely adopted decision tools in management, product design, and risk-heavy professions like medicine and the military.

This essay is about how to run one. Not the abstract theory — you can read Klein's Harvard Business Review article for that — but the tactical details that separate pre-mortems which actually surface risk from the kind that devolve into polite nodding. Because here's the truth most write-ups skip: most pre-mortems are bad. They're run without preparation, without the right people, without a clear output, and they produce a generic list of worries that nobody does anything about. Let's fix that.

What a pre-mortem actually is

A pre-mortem is a structured meeting, typically 30–60 minutes long, run shortly before a major decision or at the kickoff of a significant project. The facilitator asks participants to imagine that it's now some future date — usually 6 to 18 months out — and the project has failed catastrophically. Then the team generates, individually and then collectively, the reasons why it failed.

That's it. The whole thing fits on a napkin. The genius isn't in the mechanics; it's in the reframe.

Post-mortem vs. Pre-mortem: same question, different timingPOST-MORTEMKickoffProject fails"Why?"Lessons learned — but the money is gonePRE-MORTEM"Why did it fail?"(imagined)Project succeeds(or fails knowingly)
The post-mortem diagnoses after the funeral. The pre-mortem holds the funeral early — then walks back and changes what's about to happen.

The trick is that the question "why might this fail?" and the question "you are in the future and this did fail — why?" feel identical on paper but produce wildly different answers in practice. The first is hypothetical, speculative, easy to brush off. The second is concrete. You're already standing in the wreckage. You're not imagining a possible failure; you're explaining one that has, in the frame of the exercise, already happened. That shift — from prospective to retrospective — unlocks something in the human mind that the hypothetical framing never reaches.

Why it works: prospective hindsight

The psychological mechanism Klein identified has a name: prospective hindsight. In a 1989 study by Deborah Mitchell, Edward Russo, and Nancy Pennington, subjects were asked to imagine that an event had occurred and generate reasons for it. They produced about 30% more reasons, and more specific ones, than subjects asked to predict the same event in the standard forward way. The act of assuming the outcome is already true pulls the mind into a retrospective mode it can't access otherwise.

The research finding

Prospective hindsight increases the ability to identify reasons for future outcomes by approximately 30%. Asking "why did this fail?" (past tense) generates sharper, more specific answers than "why might this fail?" (conditional). The brain is better at retrospective analysis than prospective prediction.

There's a second mechanism at work, and it's social rather than cognitive. In a normal planning meeting, expressing doubt is costly. You look disloyal, unambitious, negative. The people who've been championing the project have social capital invested in it; the people who haven't don't want to be cast as obstructionists. So the doubts go unspoken, even when the room privately shares them. The pre-mortem solves this by making the expression of doubt the point of the meeting. Nobody gets in trouble for naming a failure mode — you're being asked to. The social cost of skepticism is inverted, and suddenly everyone has permission to say what they were already thinking.

This second effect is, in my experience facilitating them, the bigger of the two. The cognitive boost is real. The social unlocking is enormous.

When to run one

Pre-mortems cost time, so they don't belong on every decision. A useful rule: run a pre-mortem when the decision has at least two of these properties:

Pre-mortem triggers

Significant resources committed. Multiple people's time for months, material budget, or opportunity cost that matters.
Irreversible or expensive-to-reverse. You can't easily walk it back. Launching a product, signing a long contract, major hire, public announcement.
Team unified in optimism. Everyone seems to agree it's a good idea. This is a warning sign, not reassurance. Groupthink is what the pre-mortem is for.
Novel or high-uncertainty. You haven't done exactly this before. Historical base rates are thin.
Political or interpersonal stakes. People's reputations, careers, or relationships are tied to the outcome.

The timing within the decision cycle matters too. Run it after the plan is specific enough to critique but before it's so locked in that changes are politically impossible. Too early and the team hasn't formed the concrete version you need to attack. Too late and the exercise becomes performative — everyone nods gravely at the risks, nobody changes the plan. The sweet spot is usually just before kickoff: the plan is written, the team is assembled, the commitment is imminent but not yet made.

Who to invite

The composition of the room determines what you'll find. A pre-mortem with only the project's champions will surface only the risks those champions can already see — which is a small subset of the total. The goal is viewpoint diversity, not headcount.

A good pre-mortem has three groups in the room, in roughly equal number:

Who to invite: three voices you need1The buildersPeople doing the work• Know operational detail• Private reservations• Usually most useful• Often least heard2The adjacentAffected but not owning• Other teams downstream• Support, legal, ops• Know integration risks• Fresh perspective3The outsiderUnrelated but experienced• Different team or domain• No political stake• Sees pattern matches• Spots blind spotsRoughly equal numbers. Six to ten people total is the sweet spot.
Viewpoint diversity is the lever. A room of champions will find champion-sized risks. A mixed room finds the ones the champions can't see.

A few practical notes on the guest list. Invite the most senior decision-maker, but have them speak last — if the VP goes first and says "this is a great plan," everyone else's concerns evaporate. Anchoring is powerful; protect against it by changing the order of speakers. Keep the room small enough to hear everyone: six to ten is ideal. Larger groups fragment into quieter sub-audiences. Include at least one person who opposed the project if such a person exists — their silence in the normal meeting is often where the real signal is hiding.

The 45-minute agenda

Here's the structure I use. It's modified from Klein's original — slightly longer, more structured around the output — and it reliably produces a usable artifact by the end of the session.

Pre-mortem agenda · 45 minutes

0–5
min
Frame the exercise

State the plan being evaluated in one sentence. Define the failure frame: "Imagine it's [specific future date]. This project has failed disastrously. We are gathered to figure out why." Emphasize that the failure is assumed, not predicted — arguing whether failure is likely is off-topic.

5–15
min
Silent individual writing

Each participant writes, privately, as many reasons for the failure as they can. No discussion. This step is critical: if people discuss before writing, the first speaker anchors everyone's list and you lose most of the diversity. Use sticky notes, a shared doc with hidden cells, or simple paper — anything that prevents cross-contamination.

15–30
min
Round-robin sharing

Go around the room. Each person reads ONE reason at a time. Continue going around until everyone has read all their reasons or passes. Cluster similar items on a whiteboard or shared surface as you go. The round-robin format prevents dominant voices from burying quieter ones.

30–40
min
Prioritize and assign

As a group, rank the top 5–7 risks by a combination of likelihood and severity. For each top risk, ask: (a) what specific change to the plan would mitigate this? (b) who owns that change? (c) what's the deadline? This is where most pre-mortems collapse — keep pushing past "we should be aware of this" to concrete action with a name attached.

40–45
min
Close and document

Summarize the mitigations assigned. Confirm the date of a follow-up check (typically 30–60 days out) to review whether mitigations have been implemented. Send the document out within 24 hours while memory is fresh.

A few facilitation notes that matter more than they should:

Opening script

"Thanks for being here. We're running a pre-mortem on [project X]. The rules are simple: imagine it's [date], and this project has failed badly. We're not debating whether that's likely — for the next 45 minutes, it's a given. We're figuring out why. Everything you raise is in service of making the plan stronger. Nothing said here is disloyal; the opposite — staying silent about risks you see is the thing that would hurt us."

Reading this aloud at the start reliably shifts the emotional tone of the room. You're giving explicit permission to be skeptical, which most meetings spend their entire duration implicitly withholding.

A failure-mode taxonomy

One problem with open-ended pre-mortems is that people tend to gravitate toward a narrow range of failure types — usually the technical or execution ones they're most familiar with. To get a broader sweep, I sometimes give participants a taxonomy of failure categories as a prompt. It dramatically widens the coverage.

Six categories of failure to probeTechnicalSystem fails under load,integration breaks, coreassumption wrongPeopleKey person leaves, skillsgap, team burnout, hiringtakes longer than plannedMarketCustomer demand wrong,competitor moves first,conditions shiftOrganizationalPriorities shift, execsupport evaporates,reorg disrupts teamFinancialCost overrun, revenueshortfall, funding cut,ROI assumption wrongExternalRegulation changes, legalissue, vendor fails,macro event disruptsFACILITATOR PROMPT"Imagine the failure. Now go category by category:what's at least one way this project failed in each of these six areas?"
Structured prompting broadens coverage. Without it, engineering teams produce six technical risks; with it, they produce one or two in each category and catch the org failure they would have missed.

You don't have to hand every participant this taxonomy — sometimes it's better to let them go first, then ask at the end "which categories did we undercover?" and run a second short pass on the weak ones. The point is to ensure the output covers all six zones, not to prescribe the method.

What to do with the output

Here's where most pre-mortems fail: they produce an excellent list of risks and then… nothing happens. The list goes into a document. The document goes into a folder. The project proceeds exactly as planned. Two months later, one of the risks materializes, and someone says "huh, didn't we talk about that?"

The output of a pre-mortem is not the list. The output is changes to the plan. For each of the top-ranked risks, you should leave the room with at least one of four concrete responses:

The four responses

What to do with each top risk

Mitigate. Change the plan so the risk is less likely. If "key person leaves" is a top risk, mitigation might be documenting their knowledge, assigning a backup, or restructuring the critical path to not depend on one person.

Monitor. Define a specific signal you'll watch for. If "customer demand is lower than expected" is a risk, define the revenue threshold below which you'll pause and reassess — and who will be watching that number.

Transfer. Move the risk to someone else. Insurance, contracts, vendor SLAs, hiring contractors for uncertain work — all ways of making the risk someone else's problem by design.

Accept. Consciously decide the risk is worth taking as-is. This is legitimate — not every risk can or should be mitigated — but it must be named and agreed rather than quietly tolerated. "We accept that regulation may change; if it does, we'll reassess in Q3" is a decision. Silence is not.

The facilitator's job in the final ten minutes is to force one of these four verbs onto each top risk, with an owner's name and a date attached. If you leave the room with a list of risks that haven't been categorized this way, you haven't run a pre-mortem — you've run a venting session.

Common mistakes

Having facilitated a lot of these, I've watched the same pre-mortem failure modes repeat with almost comical regularity. Here are the ones worth naming so you can watch for them.

Mistake 1
Letting the champion go first

The project sponsor opens with "I think the main risk is..." and anchors every subsequent contribution. Fix: enforce silent writing before any sharing. If the champion must speak, have them go last.

Mistake 2
Treating it as a debate

Someone names a risk; the champion argues why it won't happen; the room moves on. This defeats the exercise. The frame is "this did fail; explain how" — not "is this risk real?" Debating specific risks during the surfacing phase kills the flow. Capture everything; triage later.

Mistake 3
Stopping at the list

You generate 40 great risks and call the meeting a success. But without the prioritization and assignment steps, the risks go nowhere. A pre-mortem that doesn't change the plan didn't work, regardless of how insightful the list was.

Mistake 4
Running it too late

If the decision is already politically committed, the pre-mortem becomes performative — participants can feel it, and contributions stay shallow. Run it when changes are still possible. If you're holding a pre-mortem on a decision that's already announced externally, you're doing theatre.

Mistake 5
Inviting only the inner circle

The project team alone will produce a narrow list of risks they already half-knew. The value comes from outsiders and skeptics. If your guest list is entirely people who've already been working on this, redo the guest list.

Mistake 6
No follow-up check

Mitigations get assigned and then drift. Without a scheduled review 30–60 days out, the pre-mortem's impact decays rapidly. Book the follow-up meeting before leaving the original meeting.

A pre-mortem isn't about predicting the future. It's about giving your team permission to say the things they already know but haven't been able to say.

Variants worth knowing

Once you've mastered the basic pre-mortem, three variants expand the toolkit for specific situations.

The Kill-the-Company Exercise

Popularized by Lisa Bodell, this is a pre-mortem at strategic scale. Instead of asking "why will this project fail?", the exercise asks: "How would a competitor, an activist, or a malicious insider destroy this company?" Teams spend a day generating attack vectors — pricing plays, talent poaching, regulatory challenges, brand attacks — and then use the list to identify the company's real structural vulnerabilities. It's a pre-mortem for the whole enterprise, and it surfaces the kind of strategic risk that project-level pre-mortems can't reach.

The Pre-Parade

The mirror image of the pre-mortem, and a useful complement: imagine that in 18 months, this project has been a spectacular success. What did we do right? This isn't just cheerleading — done rigorously, it surfaces the critical success factors that weren't in the plan. Often the ingredients of "outrageous success" are different from the ingredients of "not failure," and running both exercises back-to-back produces a fuller picture than either alone.

The Red Team

Where the pre-mortem uses the team's own imagination to surface risks, a red team assigns a separate group the full-time job of trying to break the plan. This is standard practice in security engineering and military planning, and it scales for high-stakes decisions that justify the investment. A red team will find things a pre-mortem can't — because they have days or weeks to dig, not 45 minutes — but pre-mortems are dramatically cheaper and can be run routinely.

The principle, restated

Before committing to a consequential plan, hold its funeral. Spend 45 minutes in the future, explain why the project died, and bring the reasons back to the present — where you can still do something about them. The meeting is cheap. The failure it prevents is not.

The pre-mortem is not a complicated tool. You can learn to run one in an hour and get reasonably good at it in a month. What makes it powerful isn't the mechanics — which are simple — but the emotional permission it grants a team to say what they already know. In most organizations, doubt is the expensive commodity. Certainty is cheap; everyone performs it in meetings to stay in the tribe. A pre-mortem flips that economy for 45 minutes and lets the quiet knowledge in the room finally speak.

That's the whole trick. Imagine the funeral. Walk back. Change what you can. Then proceed, not with false confidence, but with eyes open — which is the only kind of confidence worth having.