How long does a pre-mortem exercise take?

The solo writing step takes a few minutes. The time goes into reading every reason aloud, one per person per turn, until the lists are empty, then scoring. More people means more reasons, so team size sets the length. One person working through the template alone can finish it in a single sitting.

Who should be in the room for a pre-mortem?

Everyone who has to make the decision work, plus at least one person who was not part of building the plan. Include whoever touches delivery and whoever talks to customers. Keep it small enough that everyone reads a reason every round. If the owner is in the room, have the owner read last so the list does not bend toward the boss's view.

What do you do with the pre-mortem list afterward?

Keep the top three causes and change the plan for each one, with a name and a date on every change. Give every cause you did not fix a tripwire: the early signal that says it is starting. Put the tripwires where someone will actually see them, and rerun the template when a tripwire fires or the decision changes shape.

Pre-Mortem Template: Twelve Questions Before You Commit

This pre-mortem template is a one-page exercise for a business decision you have not made yet: a hire, a price change, a new offer, a large client. You assume the decision failed, write the story of how, sort the causes into five buckets, and fix the top three before you commit.

The method is Gary Klein’s, published as “Performing a Project Premortem” in Harvard Business Review, September 2007. The business premortem guide covers why it works. This page is the paper.

The pre-mortem template

Copy the block. One sheet per decision. Fields 1 to 3 get filled before anyone in the room says a word about the plan.

PRE-MORTEM: [decision name]
Date run:                      Owner of the decision:
In the room:

1. THE DECISION  (one sentence, with a date)
   We will ...

2. THE FAILURE DATE
   It is [date]. The decision failed badly enough that we reversed it.

3. THE FAILURE STORY  (each person writes alone, one paragraph)
   Here is what happened ...

4. CAUSES, SORTED
   Revenue:
   Delivery:
   People:
   Market:
   Owner:

5. SCORE  (1 to 3 each)
   Cause | Likelihood | Damage | Score (L x D) | Cost to fix now (low / med / high)

6. TOP THREE, WITH A CHANGE TO THE PLAN
   Cause | Change to the plan | Who | By when

7. TRIPWIRES  (the early signal that says a cause is starting)
   Cause | Signal | Who checks it | How often

Two rules keep it honest. The failure is stated as a fact, never as a risk. And field 3 is written alone, in silence, before any discussion. Klein’s reason for both: people hold back reservations that sound impolitic. A declared failure plus a private first draft is what gets those reservations onto the page.

Twelve questions that surface the real causes

Use these when a failure story comes back thin. Each one maps to a bucket in field 4.

Revenue

Which client, channel or product has to keep performing for this to work, and what happens to the plan if it stops?
What does this decision do to cash in the months before it pays back?
Which price or margin assumption did we carry over from last year without checking it?

Delivery

What does this require us to deliver that we have never delivered at this volume?
Where does work pass between two people or two systems, and who notices if it drops?

People

Who has to change how they work for this to succeed, and have they actually agreed?
Who is quietly against this, and what will they say when it fails?

Market

What does a competitor do in the first month after we move?
Which customers end up worse off, and how would we find out?
What has to stay true outside the business, such as a platform rule or a supplier, for this to hold?

Owner

Which part of this only works if the owner is personally in the room?
What does the owner want to be true here badly enough to stop checking it?

Ask questions 7 and 12 during the silent writing step, never out loud first. They ask for exactly the reservations Klein found people keep to themselves during planning.

A filled example: a conference booking flow

This example is filled in from a public case study: an adversarial pressure-test on a live conference booking site. The causes are the real findings. The failure story is written backward from them.

1. The decision. Replace the third-party booking platform with a custom Stripe-direct checkout before tickets go on sale.

2. The failure date. The first weeks of ticket sales.

3. The failure story. A customer asks for a refund. The money goes back to their card, but the seat stays held, so capacity the conference believes it is selling is not actually for sale. Later that day the same customer gets a “you’re confirmed” email, because Stripe retried a webhook and the handler processed it again, re-confirming a refunded order. Meanwhile, buyers who reach the cart by clicking through the site see a cart that looks normal and does nothing.

4. Causes, sorted.

Bucket	Cause
Revenue	Refunds release the money but not the seat. The status string the refund function wrote was rejected by a database constraint, silently.
Delivery	Webhook retries were processed as new events: duplicate confirmations, refunded orders walked back to confirmed.
Delivery	Cart code ran once on a full page load. Soft navigation between pages left it inert.
People	Nothing surfaced.
Market	Nothing surfaced.
Owner (of the decision)	The person who built the flow also tested it, and every test followed the happy path. Every one of them passed.

What happened. All three failures were found before launch and fixed in a single commit on May 6. The same pass caught two more: slug mismatches returning 404s on two evening event pages, and customer names rendered as raw HTML on the success page.

Two lessons carry over to any business decision. First, the damage clustered at handoffs: in two of the three causes, Stripe was fine, the database was fine, and the customer was not. Second, the owner bucket was not empty. The person who built the plan tested it the way they expected it to work. If your owner bucket comes back empty, ask question 12 again with the owner out of the room.

Scoring what you found

Score every cause in field 5 on two 1-to-3 scales:

Likelihood: 1 means it needs bad luck, 2 means it is plausible, 3 means it is already partly happening.
Damage: 1 means annoying, 2 means it costs a quarter, 3 means it reverses the decision.

Multiply them. Anything scoring 6 or 9 gets a change to the plan before you commit. When two causes tie, fix the one with the lower cost to fix now first. Keep the list to three changes. Everything below the line goes to field 7 as a tripwire, not onto the to-do list.

The scale is coarse on purpose. The job is a ranking, and a 1-to-3 scale keeps the room arguing about causes instead of decimals.

When a team template is not enough

A template standardizes the exercise. It does not add a perspective the room does not already have. Every cause on the sheet is one somebody present was able to imagine, and a team that built the business together tends to imagine the same things.

Structural causes deserve a separate check: revenue concentrated in a few clients, a business that stops when the owner stops. The Revenue Concentration Risk Radar and the Owner Dependency Score check both for free.

For the part a room cannot do alone, describe the decision on the free analysis. It reads the same decision through one adversarial lens and returns results instantly. The Structural Read runs twelve adversarial personas against it across six rounds, $97 founding rate, full report in 4 hours. The methodology page explains how the personas are built to disagree. The premortem analysis page compares a team premortem with an AI one.