In this doc, we’ll look at the “what” and “how” of pre-mortems, along with a novel technique of using
to run effective pre-mortems. My aim here is to be as concrete as possible so that you can take the steps described here and run your very first pre-mortem this week.
So, what’s a
mortem, and what role does it play?
mortems, After Action Reviews (AARs), etc. are becoming standard process at many organizations, usually implemented after an outage, a failure, or even a fairly successful execution of a project.
-mortem—where you discuss what went wrong (and what you can learn from it)—
earlier in a project’s lifecycle
and ask the team to assume that the project has failed. And you prompt the team to come up with the reasons for the failure.
If you do a pre-mortem right, you won’t need a tough post-mortem.
The standard pre-mortem script
In Gary Klein’s
, standard pre-mortems are accomplished in four steps:
A facilitator informs attendees that the project has failed spectacularly.
Everyone in the room writes down why they thought the project failed, including reasons they wouldn’t normally mention for fear of being impolitic.
The facilitator asks each team member to read one reason for their list and records the reasons mentioned.
After the meeting, the facilitator reviews the list and looks for ways to make the plan more robust to failures.
A modified pre-mortem process
As background, my teams at
have routinely run a modified version of this pre-mortem script, particularly for major product launches. And while we haven’t been 100% mistake-free, pre-mortems have enabled “calm product launches” and have enhanced team productivity and morale.
Why modify the standard pre-mortem script?
In my experience, the standard pre-mortem meeting was very engaging
the team was in the room. But I frequently saw everyone forget about the progress made in the meeting, quickly reverting back to old patterns as soon as the meeting was finished.
So, I began looking for ways to change that. I wanted the team to:
Actively spot major problems, and
Surface those problems to other team members
throughout the lifecycle of the project
, not just at that one pre-mortem meeting.
What was missing, I realized, was an evocative, convenient lexicon that allowed people to talk about these things in a psychologically safe manner. Enter the metaphors: Tigers, Paper Tigers, and Elephants.
Tigers, Paper Tigers, and Elephants
The way I like to run pre-mortems now is to ask the team to list out their concerns about the project in three different categories:
- A clear threat that will hurt us if we don’t do something about it.
📃 Paper Tigers
- An ostensible threat that
are personally not worried about (but others might be).
- The thing that you’re concerned the team is not talking about.
So after your pre-mortem meeting, you’ll start hearing your teammates mention “the Tiger Bob flagged” or “that Elephant mentioned during yesterday’s standup” when communicating over Slack, email, meetings, and even 1 on 1s.
This lexicon for potential threats and problems creates more psychological safety for team members to raise their concerns throughout the project’s execution.
How to run a pre-mortem the right way
While you can organize your pre-mortem meeting just about any time, a good rule of thumb is to organize it one to three months prior to your launch. This timing gives your team sufficient context on possible Tigers, Paper Tigers, and Elephants for your project, while building in a window to respond to potential problems that are identified during the pre-mortem.
The meeting itself is a highly-structured one hour:
Context and prompt (10 min)
- Think of at least 2 Tigers and any Paper Tigers and Elephants.
Quiet time #1 (10 min)
- List out Tigers, Paper Tigers, and Elephants.
Quite time #2 (10 min)
- Review others’ inputs in a shared doc and +1 those you agree with (each team member is allocated five +1s).
Around-the-room sharing (20 min)
- Share reflections and what resonated most with the entire group.
Tentative top themes and next steps (10 min)
- The meeting leader shares emergent top themes and next steps.
That takes care of the meeting itself. The
part of the pre-mortem process comes after the meeting: the
post pre-mortem action plan
. If you are the meeting leader, you now need to prioritize the top 3-5 Tigers and Elephants that emerged from the pre-mortem meeting. This action plan should consist of:
Top themes coming from the pre-mortem meeting
Verbatim Tigers and Elephants people discussed during the meeting
Proposed actions for mitigating these Tigers and Elephants
A Directly Responsible Individual (DRI) for each theme
Use this Coda doc to run your pre-mortem process
To run my version of a pre-mortem,
and use the
page to run the actual meeting.
After the meeting, you (the meeting leader) can use the
page to list themes, share those themes with the team for feedback, and then put it in action to have a much smoother launch.
Watch Shreyas walk through this doc