STRATEGY

Pre mortem on a plan

Use before committing to a plan, when you want the failure modes named while changes are still cheap.

strategy-premortem-session.md

Download .md

You are running a pre mortem. It is twelve months from now and the plan has failed. Explain how it failed, do not assess whether it might.

The plan: {{PLAN}}
What has to go right for it to work: {{KEY_ASSUMPTIONS}}
How we have failed before: {{PAST_FAILURES}}
Who does the work and what else they own: {{DELIVERY_TEAM}}

Produce:
1. Ten failure stories, one sentence each, written in the past tense as though they happened. Cover at least: an assumption in {{KEY_ASSUMPTIONS}} proving false, delivery slipping, a competitor move, a channel changing, and the plan being quietly abandoned.
2. A table with columns: Failure | How it starts | How long before it is visible | Damage | Early signal to watch | Cheap guard now.
3. Rank by damage multiplied by how late it becomes visible. Slow and invisible outranks loud and obvious.
4. Which failures in {{PAST_FAILURES}} are about to repeat, and what is genuinely different this time.
5. Capacity risk specific to {{DELIVERY_TEAM}}, including what gets dropped the week something urgent lands.
6. The three guards worth building before {{PLAN}} starts, with what each costs.

Constraints: no failure may be phrased as a general risk. Each needs an actor, a trigger and a consequence. Leave out failures nobody in the room could influence. No em dashes.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{PLAN}}
{{KEY_ASSUMPTIONS}}
{{PAST_FAILURES}}
{{DELIVERY_TEAM}}

Getting a better result

Run it before approval; afterwards people defend the plan instead of attacking it properly.
The quiet abandonment story is the one that actually happens, so do not let anyone cut it.
Put the early signals into a monthly check or the pre mortem becomes a document nobody reopens.

Questions about this prompt

When should I use this rather than a risk register?

Before the plan is approved, and in place of a register. A register lists risks in the abstract and everyone nods at it. This starts twelve months out with the plan already failed and asks how, which forces failures with an actor, a trigger and a consequence rather than a line reading delivery risk.

What do I need to run a useful pre mortem?

The plan, the assumptions it depends on, an honest account of how you have failed before, and who does the work plus what else they own. The past failures input is what stops the stories coming out generic, and the team detail is what makes the capacity risk concrete rather than theoretical.

What comes back, and how are the failures ranked?

Ten past tense failure stories covering a false assumption, slipped delivery, a competitor move, a channel change and quiet abandonment, a table with early signal and cheap guard, a ranking by damage times lateness, repeats of past failures, capacity risk, and three guards to build now. Slow and invisible outranks loud and obvious.

What is the mistake that makes a pre mortem toothless?

Running it after approval, when people defend the plan instead of attacking it properly. The other is cutting the quiet abandonment story because it is embarrassing, since that is the one that usually happens. Put the early signals into a monthly check or the whole thing becomes a document nobody reopens.