How To Run A Pre-Mortem Before Your Next Big Bet Goes Wrong
Imagining that a launch has already failed is one of the cheapest ways to find the risks a team will not raise on its own. Here is the meeting format.
Most project reviews happen after the damage is done. A launch misses, a market entry stalls, a big hire does not work out, and the team gathers to work out what went wrong. The answers are often obvious in hindsight, and the people in the room often admit they had doubts at the start.
A pre-mortem moves that conversation to the beginning. Before committing to a major decision, the team assumes the project has already failed and works backward to explain why. The technique has been used in management and decision research for decades because it addresses a specific problem: people rarely volunteer concerns about a plan their leader is excited about.
Why the framing works
Asking a team what could go wrong invites polite, general answers. Telling them it already went wrong, and asking them to explain the failure, changes the social dynamics. Raising a risk is no longer a challenge to the plan. It is the assignment.
The format also pulls out specific failure stories instead of abstract risk categories. Execution risk is hard to act on. The integration partner delayed their API changes and our launch date slipped past the trade show is something a team can plan around.
When to use it
Save pre-mortems for decisions that are expensive to reverse. Entering a new market, a major pricing change, a large hire, a platform migration, a big marketing commitment, or signing a long contract with a key supplier all qualify. Running one on every small initiative wastes the format.
The best timing is after the plan is detailed enough to critique but before resources are committed. If the budget is already spent or the contract already signed, the session turns into a list of worries with nowhere to go.
Smaller teams can run a lighter version. A founder deciding whether to sign a large annual contract with a vendor can spend twenty minutes alone, or with a co-founder, writing the failure story before signing. The discipline is the same: assume it went wrong, and be specific about how.
How to run the meeting
Invite the people who will execute the plan, plus one or two people from adjacent teams who will feel its effects. Keep it to a group small enough that everyone speaks. Ninety minutes is usually enough.
Open by describing the decision and the plan in a few minutes. Then state the premise plainly: it is a year from now, the project failed, and it failed badly. Ask everyone to spend ten minutes writing, individually and in silence, every reason they can think of for that failure.
Writing first matters. It stops the most senior or most confident voices from shaping everyone else's answers.
Then go around the room and collect one reason per person per round, until the lists are exhausted. Record every item without debate. The leader of the project should speak last, and should thank people for the uncomfortable ones.
Turning the list into decisions
Group similar reasons together. For each cluster, ask two questions: how likely is this, and how bad would it be? Most items will be minor. A handful will stand out as both plausible and serious.
For each of those, assign an owner and one of three responses. Change the plan to remove the risk. Add an early warning sign that the team will watch, with an agreed response if it appears. Or accept the risk explicitly, in writing, so nobody is surprised later.
Expect some reasons to point at people rather than plans, such as a team lacking experience in a new market or a leader stretched across too many projects. Treat those the same way as the others. They are often the most useful items on the list, because they are the ones least likely to be said aloud in an ordinary planning meeting.
Occasionally a pre-mortem reveals that a plan should not go ahead at all. That is a success, not a failure of the process. It is far cheaper to learn this in a conference room than six months into execution.
What to do before your next major decision
Book the session before the commitment date, not after. Send the plan in advance. Use the silent writing round. Leave with a short list of named risks, owners and warning signs, and put that list in the project document where the team will see it every week. Then revisit it at the first milestone and check which of the imagined failures are starting to look real.
