Draft for Ashley’s editorial review. Examples are illustrative unless otherwise attributed.

Optimism hides risks

When a team commits to a plan, it naturally starts looking for reasons the plan will work. Concerns get softened or left unsaid because nobody wants to be the person slowing things down. The risks are still there. They are just harder to see.

A pre-mortem uses reverse engineering on failure. Instead of asking “what could go wrong?”, which invites polite hedging, you assume the worst has already happened and ask the team to explain it.

Set the scene

Gather the people involved in the project. Describe a specific date after launch and say: “It is that date. The project did not achieve its outcome. It was a clear disappointment. Take five minutes and write down every reason you can think of for why it failed.”

Writing independently first is important. It keeps the loudest voice from setting the agenda and gives quieter people room to name what they have noticed.

Imagine it failed. Now you can see what to protect.

Collect and cluster the reasons

Go around the room and collect one reason at a time until the lists are exhausted. Group similar reasons together. Typical clusters include customers not understanding the offer, the experience breaking at a specific step, the team running out of capacity, a dependency arriving late, and the outcome being measured in a way that hid the problem.

Notice which reasons appear on several lists. Shared concerns are often the most important ones, and they are frequently things everyone had privately worried about.

Turn failure stories into safeguards

For each important cluster, ask two questions. What early signal would tell us this failure is starting? What can we do now to make it less likely or less damaging? The answers become guardrails, checkpoints, and small changes to the plan.

Not every risk needs a fix. Some are acceptable, and naming them openly is valuable in itself. The goal is a plan that has looked its weaknesses in the eye.

Pair it with your finish line

A pre-mortem works best alongside a clear description of success. Reverse engineering the outcome shows the path. Reverse engineering failure shows where that path is fragile. Together they give you a plan with both a direction and a set of warning lights.

Keep the list. After launch, check it against what actually happened. Over time, that comparison teaches your team which risks it tends to underestimate.