Pre-mortems

A post-mortem asks why the failure happened. A pre-mortem asks why the failure will happen, before the project starts. The difference is whether the learning is free or expensive. Pre-mortems are one of the highest-leverage, lowest-cost tools in the operator toolkit. They take an hour. They save quarters.

The exercise

Before you commit to a significant initiative, run a 60-minute meeting. Whiteboard at the front. The facilitator opens:

"It's 12 months from now. We launched this initiative. It failed completely. The board is asking what happened. Take 10 minutes, by yourself, and write down every reason you can imagine for why it failed."

Silent individual writing first, critical. Then round-robin, each person reads one item. Build the list on the board. Discussion after. Resist the urge to defend or dismiss.

Why this works

• Reframes the question. "What could go wrong?" gets defensive answers. "Why did this fail?", assumed past tense, gets more honest answers.
• Permissions dissent. Saying "I think this will fail because X" in a kickoff meeting is socially expensive. Saying "one way this could have failed is X" in a pre-mortem is expected.
• Surfaces assumptions. The most dangerous risks are the ones nobody questioned. Pre-mortems force them into the open.
• Generates mitigations. Every failure mode is an opportunity to add a guardrail, an early warning, or a kill criterion.

Clustering the failure modes

After the brainstorm, group the items into categories. Typical buckets:

• Market, customers didn't want it; the segment was wrong; competitors moved first
• Execution, we shipped too late; scope ballooned; team wasn't strong enough
• Technical, foundational tech decision wrong; scaling broke; integrations failed
• Organizational, leadership didn't support it; teams didn't align; ownership unclear
• Financial, ran out of runway; unit economics didn't work at scale
• External, regulation changed; macro conditions changed; platform changed

From failure mode to action

The most likely + most damaging failure modes each get:

1. An early warning signal. What metric or event would tell us this is happening?
2. A prevention. What can we do now to reduce the probability?
3. A mitigation. If it happens anyway, what do we do to limit damage?
4. A decision-maker. Who has authority to pull the plug or change course?

Example.
Failure mode: "We built the wrong thing, customers didn't actually want it."
Early warning: Design partners can't articulate value after 30 days.
Prevention: 5 paid LOIs signed before engineering starts.
Mitigation: Month-3 kill review; 50% pivot budget reserved.
Decision-maker: CEO + product lead jointly.

When to run a pre-mortem

• Before any initiative with > 3 months runway or > 2 FTE committed
• Before any irreversible decision (M&A, hiring a senior exec, major platform switch)
• Before entering a new market
• Before a major pricing change

Not for every sprint. You'd drown in pre-mortems. For the decisions that matter.

The common mistake

Running the pre-mortem, filing the notes, then never referencing them. The output has to feed somewhere, into the project's kill criteria, the WBR dashboard, the quarterly risk review. Otherwise you had a cathartic exercise that generated no durable value.

What good looks like

• Every major initiative has a pre-mortem in its kickoff packet
• The top 3 failure modes each have an owner, an early warning, and a mitigation
• Pre-mortem outputs feed the decision log and the risk register
• Teams bring up "we said this might happen in the pre-mortem" unprompted when it does happen

Related: Decision frameworks · What to kill · Risk management