Conduct a "Post-Mortem" Before the Meeting: How a Five-Minute Pre-Mortem Can Save Projects

Last week, I helped a friend conduct a retrospective on a product redesign. Two weeks after the new version launched, the core conversion rate dropped by 11%. The team’s immediate reaction was to blame external factors: "Users have changed," or "The overall market is down." After three meetings, they still hadn’t identified the culprit. Then, a colleague asked, "If I told you right now that this redesign has completely failed, what would be the most likely reason?" The room fell silent for three seconds. Then, seven people wrote down nine reasons. Two of these were based on the flawed assumption that "users would intuitively understand the new navigation"—which turned out to be the direct cause of the drop in conversion. In hindsight, if they had spent five minutes conducting a pre-mortem before launch, these two assumptions would have been caught and addressed immediately.

The One-Sentence Rule

**Before committing resources, assume the project has already failed. Spend five minutes writing down "how it died," and treat each point as a risk to be validated.**

Note the sequence: Default to "failure," then identify the causes. This is not ordinary brainstorming; it forcibly lowers our natural optimism bias.

Specific Use Cases

**1. Before major launches or redesigns.** This applies to new feature releases, pricing adjustments, or site-wide overhauls. Start with this fixed opening line: "Assume it is three weeks from now, and this redesign has failed. Why?" Each person independently writes down three reasons, then the group merges and deduplicates them. Focus specifically on items where "we didn’t realize we were making an assumption." Failures almost always stem from hidden assumptions.

**2. Before making important commitments.** Whether promising a client delivery in three days or assuring leadership of a month-end launch, ask first: "Under what circumstances would I fail to deliver?" Potential answers include insufficient resources, delays from dependencies, scope creep, or overestimating your own speed. Address the most likely scenario today, rather than waiting for it to happen.

**3. Before writing your first long-form article or proposal.** The biggest pitfall of long-form content isn’t "poor writing," but rather "writing for the wrong audience" or "starting with false premises." Assume that three months from now, no one has shared your article, or your proposal has been rejected. What is the most likely reason? If you can’t answer this, don’t start writing yet.

**4. When taking over an unfamiliar system for the first major change.** Before modifying legacy code or old configurations, write down "how this change could cause an incident." Which components depend on it? How many steps are required for a rollback? Who needs to be notified? Those who cannot map out the accident chain often haven’t truly understood the system.

When You Don’t Need a Pre-Mortem

- **Trivial tasks completable in under three minutes:** Replying to a message, fixing a typo, or deploying a hotfix that changes a single constant. The overhead of a pre-mortem exceeds the cost of the potential error, making it a pure waste of time.

- **Scenarios with extremely high immediate risk:** Production data is currently being lost, or a security incident is actively occurring. The priority here is stopping the bleeding and rolling back, not sitting down to discuss why it failed.

- **When you have already completed three similar projects with mastered processes:** The value of a pre-mortem lies in exposing the unknown. In repetitive projects handled by experts, it yields only clichés. It is far more valuable to bring a novice along to participate.

Five-Minute Execution Checklist

- [ ] The opening statement must be "Assume it has already failed," not "What risks do you see?" (The latter yields polite, standard answers.)

- [ ] Everyone writes **independently**. No discussion while writing—people tend to rationalize their thoughts and dull sharp suspicions during group discussion.

- [ ] After writing down each risk, add: "**How do we verify this doesn’t exist?**" A risk that cannot be verified is effectively a confirmed threat.

- [ ] After merging, select only the **top 2–3 most likely risks** to address. Do not aim to list every possible scenario.

- [ ] Assign an owner and a check-in date for these 2–3 items, and add them to your task list. A risk list without owners is worthless paper.

Common Pitfalls

**Pitfall 1: Turning the pre-mortem into a blame game.** As soon as someone starts looking for "who wrote this terrible requirement," everyone else will fall silent. Discussing failure beforehand is safe; discussing it afterward is dangerous. If the facilitator sees sparks flying, pull it back immediately: "Focus on the issue, not the person. We are discussing hypothetical failure."

**Pitfall 2: Only listing risks deemed "unlikely to happen."** People habitually list familiar, controllable risks (server outage, staff shortage), nod in agreement ("Oh, we have a plan for that"), and end the meeting. The truly valuable answers are those that make people pause and forget to argue—probe deeper into these.

**Pitfall 3: Using it indefinitely for all risk prevention.** Conducting a pre-mortem for every decision adds a 20-second delay to every action, causing teams to eventually skip or敷衍 (go through the motions of) the process. Reserve it for decisions with "high reversal costs and broad impact." Handle smaller decisions as usual.

Conclusion

The output of a pre-mortem is not the list itself, but the two or three causes of death caught and prevented by that list. Next time you are about to launch, make a commitment, or modify a legacy system, start by asking, "Assume it has already failed." Five minutes exchanged for the luck of never needing a retrospective.