We have caught ourselves nodding along with our own recommendation more times than we would like to admit. Everyone in the room already agreed with the plan, because agreeing was how the room produced the plan in the first place.
So we added a step. Before a recommendation becomes a plan, we hand it to someone who was not in the room and ask one question: assume this already failed, now tell me why.
A pre-mortem is one question you ask before committing to a plan. Imagine it has already gone wrong, then write down every reason why. It takes one colleague, and it catches the mistake before the mistake costs anything.
The exercise itself is not new. A 2007 Harvard Business Review article described the same premise: assume the project has failed, then explain why. Ours differs in one way: the reviewer was never in the room.
Why the room agrees with itself
Maybe the plan is a push into search visibility or a shift in where the ad budget goes. Whatever it is, the people who built it spent hours convincing themselves it would work. That effort does not disappear once the plan is finished. It turns into a mild resistance to hearing that the plan might be wrong, right when hearing that would help the most.
The mistake a pre-mortem catches is usually a good idea built on an assumption that went stale without anyone noticing, like a channel that used to convert. The plan can be well built and still fail, because the ground under it moved before anyone checked. The check is simple: ask what has changed since the argument for the plan was first made. If the answer is nothing, the plan probably still holds.
A pre-mortem works because it changes the question, and because the objections arrive before you have defended the plan out loud. Instead of asking whether the plan will work, which invites everyone to defend the plan they already like, it asks what went wrong. That question gives people permission to criticize a plan without criticizing whoever wrote it. Nobody has to admit they were wrong. They just have to imagine a future where the plan failed and describe it.
How to run one with a colleague
A pre-mortem
-
Write the plan in one sentence
Not the deck version. The one sentence you would say if someone stopped you in the hallway.
-
Hand it to someone who was not in the room
A colleague who has not heard the reasoning yet gives an honest first reaction, not a rehearsed one.
-
Ask them to assume it went wrong
Six months from now, the plan did not work. Ask them to write down why, in as much detail as they can.
-
Read the whole list before you argue with any of it
The point is coverage, not correctness.
-
Fix the reasons that would happen
Most of the list will be speculation. Find the few reasons that would really happen, fix those, and let the rest go.
The list only helps if you read it before you defend the plan to the colleague who wrote it. Once you have defended a plan in front of someone, you tend to stop hearing objections to it. Notice when the same objection turns up again in different words. That repetition usually means the plan has a real weak point.
Assume this already failed. Now tell me why.
The reviewer needs no stake in the plan
We run this at the point where a recommendation is about to become a plan. The same principle runs this blog: before a post like this one publishes, someone who did not draft it reviews it.
Our reviewer, the one in the callout above, is an AI assistant with no memory of the draft. The sign off is a person's.
Run it even on plans you feel good about, especially on those. Confidence is not evidence that a plan will work. Most of the time, it is evidence that we already talked ourselves into it, which is exactly the condition this exercise exists to catch.
The next time a plan is ready to leave your desk, skip the question of whether it is good. Ask someone with no stake in it to assume the plan went wrong, and listen to what they say happened. If the plan survives that conversation, sign off. If it does not, you just found out what would otherwise have cost a great deal more.
This post was drafted with AI tools from our own project records, anonymized, and checked by us before it published. Read our editorial standards.
