You know what a post-mortem is: after a project crashes, the team gathers to ask what killed it? Useful — but it’s an autopsy. The patient is already on the table. Everything you learn arrives too late to save this project.
Now apply the flip you learned last lesson to the timing itself. What if you ran the autopsy before the project started — while the patient is still healthy and every cause of death is still preventable? That’s the pre-mortem, and it’s the single highest-leverage way to use inversion in real life.
What a pre-mortem is
A pre-mortem is a planning technique, popularised by psychologist Gary Klein, that works like this: at the start of a project, before any work begins, you gather the team and say —
“Imagine it’s a year from now. The project has failed. It was a complete, embarrassing disaster. Now: write down exactly why.”
That’s it. You assume failure as a settled fact and reason backward to its causes. Instead of asking the optimistic forward question — “how will this go well?” — you ask the inverted one — “it went terribly; what did it?” And because you’re now imagining a failure that has already happened, people produce reasons that are startlingly specific and honest.
Pre-mortem vs. post-mortem
A post-mortem dissects a failure after it happens — too late to help the deceased. A pre-mortem dissects an imagined failure before you start — early enough to prevent every cause it surfaces. Same autopsy, moved to where it can still save a life.
Why imagining failure beats listing risks
“But we already do a risk assessment,” you might say. Here’s the subtle, powerful difference. A normal risk meeting asks: “what could go wrong?” — a hypothetical, and our optimism quietly files most answers under “unlikely, won’t happen to us.” The pre-mortem asks something psychologically different: “it HAS gone wrong — why?” By treating failure as a certainty that already occurred, it gives people permission to be pessimistic and defeats two biases at once:
- Optimism bias — our tendency to assume things will go well. Hard to sustain when the prompt insists the project is already a smoking ruin.
- Groupthink / the silent doubter — in a hopeful kickoff, the person with a nagging worry stays quiet to avoid being “the negative one.” The pre-mortem makes voicing doom the assignment, so the quiet doubt finally gets said out loud — often the doubt that would have sunk the thing.
This second effect is the secret weapon. Klein’s insight was that somebody on the team usually already senses the fatal flaw — they just have no socially safe way to raise it. The pre-mortem is that safe way.
Before you read — take a guess
A team is thrilled about a new launch. One engineer privately suspects the timeline is impossible but says nothing. Which prompt is most likely to get that doubt onto the table?
How to run one — the five steps
The pre-mortem is a repeatable drill, not a mood:
- Set the scene. Gather the people who’ll do the work. State the plan, then declare: “It’s [future date]. This project has failed completely.”
- Everyone writes failures silently, first. Each person independently lists why it failed — silent and solo so the loudest voice or the boss’s opinion can’t anchor the room.
- Collect every cause out loud. Go around and gather them all, no debating yet. You want the widest net, including the awkward ones.
- Cluster and rank. Group similar causes and sort by likelihood × damage. A failure that’s both probable and fatal jumps the queue.
- Turn the top causes into safeguards. For each serious cause, decide a concrete action now: a check, an owner, a change to the plan. This is the negate-into-a-safeguard step from lesson 2, applied to a whole project.
The plan: Ship a new mobile app in three months.
The scene: “It’s a year later. The app launched and flopped. Why?”
Causes the team writes down (silent, then collected):
- Onboarding was so confusing that most users quit on the first screen.
- A key feature depended on a third-party service that throttled us at launch.
- We built features nobody asked for and skipped the one thing reviewers wanted.
- The app crashed on older phones we never tested.
- Marketing peaked a week before the app was actually in the stores.
Rank by likelihood × damage, then convert the top ones to safeguards now:
- Confusing onboarding (likely + fatal) → run five usability tests on the first-run flow before launch; assign an owner.
- Third-party throttling (medium + fatal) → confirm rate limits in writing and build a fallback; owner + deadline.
- Crashes on old phones (likely + damaging) → add the three most common old devices to the test matrix.
You haven’t built anything yet — and you’ve already defused the three things most likely to kill the launch. That is inversion paying rent.
Complete the core move of a pre-mortem.
Pick the right option for each blank, then check.
A pre-mortem asks the team to imagine the project has and then explain . Because failure is treated as a fact that already happened, people give reasons that are unusually .
The same flip, scaled up
Notice the pre-mortem is literally the lesson-2 recipe applied to a whole project across time:
| Flip recipe (lesson 2) | Pre-mortem (this lesson) |
|---|---|
| State the goal | State the project plan |
| Invert to the opposite | ”Imagine it has completely failed” |
| List the failure paths | Everyone writes why it failed |
| Negate each into a safeguard | Convert top causes into actions now |
| Act on the avoid-list | Build the project with mines pre-cleared |
Same engine — ask how it fails, then prevent that — just aimed at a plan instead of a single decision. That’s what makes inversion a model rather than a one-off trick: the identical move rescales from “how do I word this email” to “how do we run a year-long programme.”
Imagine it already failed
Pre-mortem flips for three common plans
Each card is a hopeful plan. Flip it to the pre-mortem question — “it failed; why?” — and the safeguard that surfaces:
A pitfall: the pre-mortem that becomes a panic attack
Inversion has a shadow side, and the pre-mortem is where it first shows up. If you list failure modes and then keep listing them forever, you don’t get a safer project — you get paralysis. A team that surfaces forty doom scenarios and treats all forty as equally urgent will never start, drowning in defensive busywork against risks that were never going to happen.
The fix is the rank step, and it’s not optional. You are not trying to prevent every conceivable failure — you’re trying to prevent the few that are both likely and damaging. A meteor could hit the office; you do not need a meteor contingency. Triage by likelihood × impact, fund the top few, and consciously accept the long tail of trivial risks. Inversion surfaces the list; judgment decides which items earn a response.
Surface, then triage — don't drown
A pre-mortem that ends with “here are 40 ways we could fail” and no ranking has failed at its own job. The point isn’t to fear everything; it’s to find the two or three failure modes worth real effort and let the rest go. Inversion finds the candidates; triage picks the targets.
During a pre-mortem for a product launch, sort each surfaced failure: does it deserve a real safeguard, or is it a low-priority risk you note and move past?
Place each item in the right group.
- A typo in the footer copyright year
- The payment provider rejects cards at launch, blocking all sales
- Onboarding so confusing most new users quit on day one
- The app crashes on the three most common older phones
- A simultaneous global internet outage on launch morning
- A meteor strikes the office during the launch party
Recap
Big picture
The pre-mortem at a glance
- Pre-mortem
- The move
- “Imagine it already failed — why?”
- Inversion aimed at a plan
- Why it works
- Defeats optimism bias
- Frees the silent doubter to speak
- The five steps
- Scene → silent lists → collect → rank → safeguards
- The pitfall
- Listing every risk → paralysis
- Fix: triage by likelihood × damage
- The move
Pre-mortem drill
What is the defining prompt of a pre-mortem?
Check your answer to continue.
Where this goes next
You’ve now scaled the flip from a single decision up to an entire project, and met the pitfall — over-listing leads to paralysis, so you triage. So far we’ve used inversion to prevent specific failures.
The next lesson zooms out to a bigger, almost philosophical claim from Charlie Munger: across whole fields and whole careers, you often win more by avoiding stupidity than by seeking brilliance. We’ll see why eliminating dumb mistakes beats chasing genius moves — and run the famous “how to make a team utterly miserable” flip to turn the idea into management advice.