Key takeaways
- →A pre-mortem asks the team to explain a failure you have already declared, which removes the social cost of being the pessimist in the room.
- →Run it two to four weeks before launch - late enough that the plan is real, early enough that you can still change it.
- →Generate causes in silence for eight minutes before anyone speaks, or the first confident voice sets the agenda for everyone else.
- →Rank by plausibility rather than severity, because every launch has a catastrophic tail nobody can act on.
- →The session only counts if each of the top five causes leaves the room with a named owner and a date, not a shared document.
- →Six to twelve people is the working range; above fifteen, run parallel groups and merge the lists rather than losing half the room to silence.
A pre-mortem is a session you run two to four weeks before a launch in which you tell the team the launch has already failed badly, and ask them to write down why. That single change of framing is the whole technique: nobody is raising a concern any more, which is socially expensive, they are explaining an outcome you have handed them as fact, which is just analysis.
The output is not a warm feeling that the team has thought about risk. It is a ranked list of specific failure causes, and for the top five, a named owner, a mitigation and a date, folded back into the plan before the plan is locked. For six to twelve people it takes ninety minutes.
This guide covers the exact prompt wording, the run sheet with timings, how to rank causes without the loudest person deciding, how to run it when half the team is remote, and the four ways a pre-mortem quietly degrades into a status meeting with a gloomier name.
Why a pre-mortem beats asking people about risks
Ask a room what could go wrong and you will get four answers, all from the same three people, all of them things already in the plan. Ask the same room to explain why the launch failed and you get twenty answers, several of which nobody has said out loud before. The question has not changed. The permission has.
There are two reasons this works. The first is that explaining a stated outcome is a far easier cognitive task than predicting an unstated one - people are fluent at producing causes for events they believe happened, and vague about probabilities for events they are imagining. The second is social. In a team that has spent three months building something, the person who volunteers a risk is positioning themselves against the group, and most people quietly decline that role. The literature on psychological safety describes exactly this cost, and the pre-mortem sidesteps it by making pessimism the assignment rather than a personal stance.
It is also the cheapest available defence against a group talking itself into a decision none of its members individually support - the pattern the Abilene paradox describes. If four people privately think the migration script is under-tested and each assumes the others are comfortable, no ordinary status meeting will surface that. A prompt that requires everyone to write an explanation for failure will.
When to run it and who should be there
Two to four weeks before the launch date is the sweet spot. Earlier than that and the plan is still abstract, so the causes people generate are generic - integration issues, scope creep, the usual furniture. Later than two weeks and you have bought yourself a list of things you cannot act on, which is worse than not knowing, because the team now carries the anxiety without the remedy.
Invite everyone with a hand on the launch and at least two people who inherit it afterwards. Support and on-call engineers produce a category of cause that the build team structurally cannot see: what happens at 2am when the runbook link is dead. A sales engineer will tell you which customer will try the one flow you deprioritised. These are the highest-value seats in the room and they are the ones most often left empty.
The launch owner should attend and should not facilitate. Their job in the room is to answer factual questions and otherwise stay quiet. The moment they begin explaining why a cause is already handled, everyone recalibrates on what is acceptable to write down, and the remaining forty minutes produce nothing you did not already know. If you have no neutral facilitator available, borrow one from another team - it takes ten minutes of briefing.
The five phases at a glance
The shape below is what you are protecting. Every pre-mortem that fails does so by collapsing two of these phases into one - usually generation and discussion, which is the same as not running a pre-mortem at all.
Declare the failure
State the date, the outcome and the severity in one sentence. Make it specific and slightly worse than you fear.
Write in silence
Eight minutes, everyone individually, anonymous submissions. No discussion, no clarifying questions until the timer ends.
Read every cause aloud
The facilitator reads each one without commentary. Authors stay anonymous. Duplicates get merged as you go.
Rank by plausibility
Three votes each on the causes people think are most likely to actually happen, not the most catastrophic.
Assign owners and dates
Top five causes only. Each leaves the room with one named person and a date inside the next fortnight.
The 90-minute run sheet
0-10 min: frame and declare the failure
Explain the format in two minutes so nobody spends the silent phase wondering what is expected. Then read the failure statement aloud, slowly, and put it on the screen where it stays for the whole session. Something like: it is the 14th of next month, we shipped on time, and by Friday we had rolled back, three enterprise customers had escalated, and the team spent the weekend firefighting. Do not soften it. A hedged failure statement produces hedged causes.
10-20 min: silent, anonymous generation
Eight minutes on a visible countdown. Everyone writes as many distinct causes as they can, one per submission, in plain language. Ask for mechanisms rather than categories: not 'poor testing' but 'the migration was only ever run against a copy of staging, which has a tenth of the row count'. Expect five to eight causes per person from a warmed-up group, and expect the last two minutes to produce the best ones - people exhaust the obvious first.
20-40 min: read everything aloud
The facilitator reads each cause with no editorial. No 'we have already covered that'. Merge exact duplicates as you go and leave near-duplicates alone, because the difference between them is usually where the real disagreement lives. Allow clarifying questions of the room, not of the author - anonymity holds until the mitigation phase. Twenty minutes is enough for around forty causes at reading pace.
40-55 min: cluster and rank by plausibility
Group causes into six to ten themes on the fly, then give everyone three votes and ask a specific question: which of these do you genuinely expect to happen. Plausibility, not severity. Ranking by severity always surfaces the same untouchable tail - a data breach, a regional outage - and produces no action. Plausibility surfaces the untested rollback and the support team that has not been briefed.
55-80 min: mitigations and owners for the top five
Take the top five clusters only and go one at a time. For each, ask two questions: what would make this less likely, and what would make it cheaper if it happens anyway. Names go on the board as you speak, out loud, with a date. This is the phase people try to defer to a follow-up document and it is the only phase that changes anything.
80-90 min: read the commitments back
Read the five owners and dates aloud to the room. It takes ninety seconds and it is the difference between a list and a set of commitments. Then say what happens to the causes that did not make the top five - they go in the launch doc as known and accepted, which is a real decision, not a filing action.
Writing the prompt so people can answer it
The prompt does most of the work. A weak one - 'imagine the launch went badly, what happened?' - gets you generic causes because the failure it describes is generic. A strong one is dated, specific, and describes consequences that are recognisably bad for the people in the room.
Three elements make a prompt land. Give it a date, so people reason about a real calendar with real holidays and real on-call rotations. Give it a visible consequence, so the causes have to be big enough to produce it. And make it slightly worse than what anyone privately fears, because a prompt that matches the team's existing worry just returns that worry.
It is worth varying the failure across sessions if you run these regularly. A prompt about a rollback produces engineering causes. A prompt about a launch that shipped fine but nobody used produces positioning, enablement and pricing causes. A prompt about a launch that worked and then broke six weeks later produces the operational debt nobody owns. If you have time for two eight-minute rounds, run two different failures rather than one longer round on the same one.
What changes when the prompt gets sharper
✗ Weak prompt, weak causes
- •What are the risks with this launch?
- •Causes come back as categories: testing, scope, comms
- •Three senior voices produce all the answers
- •Everything raised is already on the plan
- •Session ends with 'good discussion' and no owners
✓ Declared failure, specific causes
- •It is 14 March. We rolled back within 48 hours. Why?
- •Causes name systems, people, dates and thresholds
- •Anonymous writing gets the quiet half of the room in
- •At least four causes nobody had said out loud
- •Top five leave with a named owner and a date
Ranking without letting the loudest person decide
The ranking phase is where a pre-mortem is most often quietly overturned. Someone senior says 'realistically the only one that matters is the migration' and the room converges, not because they agree but because arguing costs more than acquiescing. Vote first, discuss second - always in that order.
Structured voting after silent generation is the nominal group technique in its plainest form, and it exists precisely because unstructured group discussion under-weights minority views. Give everyone the same number of votes, run the vote simultaneously rather than round-robin, and hide the running tally until everyone has submitted. A visible tally turns the last few voters into followers.
Watch for the split cluster. If two near-identical causes each get four votes while a single unified cluster gets seven, the split pair is the room's real priority and your clustering hid it. Before you move on, read the top eight raw causes rather than only the theme labels, and give the room one chance to say that a merge was wrong.
A pre-mortem does not tell you what will go wrong. It tells you what your team already believes will go wrong and has not been able to say.
Running a pre-mortem with a distributed team
Remote is not a downgrade for this format - it is arguably better, because the silent generation phase is native to it and nobody has to read a wall of handwriting. What you lose is the ambient signal that everyone is still working, so timers have to be visible and you have to narrate progress: 'twenty-two causes in, three minutes left'.
Use an anonymous open-text activity for the generation round, projected on shared screen so people can see submissions accumulating as a count rather than as content. Seeing the number climb keeps late writers going; seeing the content early anchors them on what has already been said. Session Flo handles this split directly - the count is public while responses stay hidden until you reveal them.
For the ranking round, run a live vote with the tally hidden and reveal it once. For the mitigation round, switch responses to named. Announce that switch out loud so nobody is caught out: the collection was anonymous, the commitments are not. In a hybrid room, have the in-person attendees submit on their phones like everyone else rather than shouting causes across the table, or the remote half will contribute a third of what they otherwise would.
The four ways a pre-mortem fails
Top Tips
- It becomes a status meeting. Someone answers each cause as it is read - 'that is already covered by the canary deploy' - and generation turns into review. Fix it by banning responses during the read-aloud phase entirely, and telling the room at the start that you will interrupt anyone who does it, including the sponsor.
- The causes stay abstract. A board covered in 'communication', 'timeline pressure' and 'unclear ownership' is a board you can do nothing with. Fix it live: when you read an abstract cause, ask the room to convert it into a mechanism with a system and a person in it, and write the converted version underneath.
- Ranking by severity instead of plausibility. Every launch has a catastrophic tail that no fortnight of work can address, and if you rank by how bad it would be, that tail wins every time and the session produces nothing actionable. Ask explicitly: which of these do you expect to happen, not which would hurt most.
- No owner leaves the room. The commitments get captured in a document, the document gets shared, and nothing moves. Fix it by refusing to close the session until five names have been said aloud, and by putting the five owners and dates in the recap that goes out within the hour, while people still recognise their own commitment.
The week after: what actually has to happen
Send the recap the same day, and keep it to one screen: the failure statement you used, the top five causes in ranked order, the owner and date for each, and a single line naming the causes the room chose to accept without action. That last line is the part people forget, and it is what stops the same cause reappearing as a surprise three weeks later.
Put a fifteen-minute check on the calendar for one week later with the five owners only. Not the whole group - a fifteen-minute call with five people who each have to say done or not done is a far stronger commitment device than a status column in a document nobody opens. If two of the five are not done, that is your real signal about capacity before launch, and it arrives while you can still act on it.
Then keep the list. After the launch, whether it went well or badly, read the ranked causes alongside what actually happened. Teams that do this get noticeably better at the technique within three or four cycles: they learn which of their instincts are calibrated and which categories they systematically under-weight. It also makes the post-launch retrospective faster, because half the analysis is already written down and dated.
Frequently asked questions
How long should a pre-mortem take?
Ninety minutes for a group of six to twelve, and you can compress it to sixty if the launch plan is already well understood by everyone attending. The shape matters more than the total: roughly ten minutes of framing, eight to ten minutes of silent writing, twenty minutes of reading causes out, fifteen minutes of clustering and ranking, and the remaining time on mitigations and owners. If you find yourself cutting anything, cut the discussion of causes nobody ranked, never the assignment of owners at the end.
How is a pre-mortem different from a risk register?
A risk register is a list you maintain; a pre-mortem is an hour of directed imagination that produces one. The difference is psychological. Adding an item to a register means asserting that something might go wrong, which reads as scepticism about a project your colleagues are invested in. A pre-mortem hands everyone the failure as an established fact and asks only for the explanation, so the same concern arrives as analysis rather than doubt. You will hear things in a pre-mortem that have been sitting unsaid in someone's head for a month.
Who should be in the room for a pre-mortem?
Everyone with a hand on the launch and at least two people who will have to live with it afterwards - support, sales engineering, on-call. Six to twelve is the productive range. The person who owns the launch should be there but should not facilitate, because the moment they start defending decisions the session ends in substance if not in fact. If you need more than fifteen people, split into two or three groups with the same prompt and merge the ranked lists at the end.
Should a pre-mortem be anonymous?
Make the generation phase anonymous and the mitigation phase named. Anonymous writing gets you the causes involving a specific team being under-resourced or a dependency nobody trusts, which people rarely put their name to in front of the sponsor. Once causes are on the board and ranked, ownership has to be public - an anonymous mitigation is an unowned one. Session Flo lets you run the collection anonymously and then switch to named responses for the commitments, which is exactly the split you want.
What if the team has already committed to the launch date?
That is the normal case, and it does not make the session pointless - it changes what you are looking for. With a fixed date you are hunting for causes you can defuse without moving anything: a rollback path you have never tested, a runbook that lives in one person's head, a support team that has not seen the feature. Ask explicitly for causes that could be mitigated in under a week. If the top-ranked cause genuinely cannot be defused in the time available, that finding is the most valuable thing the session will produce and it belongs in front of whoever owns the date.
Can you run a pre-mortem for something other than a launch?
Yes, and it works best when there is a discrete event with a date attached: a migration, a conference talk, a reorganisation announcement, a customer pilot. It works poorly for ongoing work with no obvious failure moment, because the prompt loses its force - explaining why a continuous programme failed produces vague answers about culture and prioritisation. If you want the technique for ongoing work, pick a milestone six weeks out and pre-mortem that instead.
Keep reading
- running a retrospective that changes something — The mirror image of a pre-mortem, run after the event rather than before it.
- silent generation before discussion — Why the eight minutes of writing produce better causes than open discussion.
- how consensus hides disagreement — The failure mode a pre-mortem is designed to defeat.
- dot voting to rank the causes — A fast way to turn thirty causes into the five you will act on.
- Session Flo plans — Anonymous collection and named commitments in the same session.