Execution

The pre-mortem: the meeting that saves projects

Post-mortems explain why things went wrong. Pre-mortems prevent it. The two-hour exercise that changes project outcomes.

A post-mortem happens after the project has already failed. A pre-mortem happens before it starts. The exercise is simple and uncomfortably effective: assume the project has failed catastrophically six months from now, and the team has gathered to write its obituary. What killed it?

The technique comes from decision psychology (Gary Klein's research on prospective hindsight, popularised by Kahneman), and the underlying finding is striking: imagining an event as having already happened makes people meaningfully better at generating specific reasons for it than asking "what might go wrong" ever does. The framing does the work. "What could fail?" invites diplomacy; "it failed, explain it" invites detail.

Why imagined failure beats predicted failure

People are bad at predicting risks because predicting risk feels like pessimism, and pessimism is socially expensive on a new project. Imagining a failure that has already happened gives permission to surface the risks that would otherwise stay unsaid. The team uncovers in two hours what would have taken months of bad results to learn.

The permission structure matters most for the people with the most information: the engineer who suspects the integration is shakier than the plan assumes, the junior teammate who watched the last project die the same way, the salesperson who knows the customer commitment behind the deadline is softer than leadership thinks. In a planning meeting, each of them stays quiet, because dissent against fresh enthusiasm is expensive. In an obituary-writing exercise, the same knowledge comes out as narrative, and narrative is safe.

How to run it

Frame the scenario: "It is six months from now. The project has been declared a failure. We are writing the post-mortem. What happened?" Have everyone write their version silently for ten minutes, then share. Cluster the themes. The biggest cluster is the biggest risk. Build the project plan to mitigate the top two or three clusters.

Three facilitation details protect the output. Silence first is non-negotiable: the moment discussion starts before writing ends, the room converges on the loudest person's failure story and the diversity that makes the exercise work is gone. Read the scenarios verbatim rather than summarising, and cluster on a wall or doc where everyone can see the weight of each theme. Then convert: every top cluster gets one owner, one mitigation, and one tripwire, the observable early signal that this failure has started happening, with a pre-agreed response. The tripwire is what most teams skip, and it is the difference between a cathartic meeting and a protected project.

When to use it

At the start of any project where failure would be costly. Before a launch. Before signing a contract that locks you in. The exercise feels like overkill until you have done it once and discovered the risk that would have killed you.

Two failure modes of the exercise itself: running it so often that it becomes ritual theatre (a pre-mortem on every two-week task teaches people to phone it in; reserve it for the projects that deserve two hours), and running it without ever revisiting the output. The mitigations and tripwires belong in the project's living plan, checked at each milestone, and the eventual post-mortem should open by re-reading the pre-mortem. Teams that close that loop discover something motivating: most real failures were named in the room, months earlier, by someone. The discipline is arranging to have listened.

Takeaways

What to do with this

Related

Keep reading

Put the playbook to work.

Cafiyn Lens tells you which market is worth the effort, and Cafiyn FlyWheel runs the acquisition loop against it. Two products, one shared Blueprint, from $14.99/mo.