I did a number of premortems at SpotHero. For instance, when we were launching our oversized vehicle initiative, it required us to coordinate with account managers and operations because garages needed to know what was happening and how to change their behavior. Customer support had a lot of involvement, and it was complicated from an engineering perspective. The premortem we ran for this project was very effective in helping us identify a number of these risks early enough to make sure we were taking good care of our users.

I have a client who recently used a premortem as they were going from their beta to a GA launch; again this involved a number of different teams and having a clear picture of the risks was very helpful for them to prioritize what they paid attention to as the timeline neared.

I like to do premortems after engineering has begun, but not when it's too far down the line. It's helpful for engineers to have started unpacking what they're building and how, but we don't want to go so far that it feels like it's hard to pivot if you figure out something new. The product spec is actually a great document to bring in to frame the premortem conversation, as it gets everyone on the same page about the direction you're headed.

For a full premortem, I would say expect to allocate two hours minimum. Given the group size and the number of steps, an experienced facilitator can get it done faster. If you can get the pre-work done and reviewed by everyone, it could be done in an hour or hour and a half instead.

People are going to come up with ideas that are related to their own personal concerns, are highly unlikely, or perhaps express less of an understanding of a particular area of the product and launch than you have. But it's very important to support them and validate their concerns, even when they're unfounded. The best way to ruin a premortem is to make people nervous about sharing their thoughts.

While it's common in brainstorms for teams to group together related ideas, I find that it's generally faster in a premortem to discard ideas that are similar. Otherwise, there ends up being a discussion around how the ideas are similar-but-slightly-different and it adds to the time it takes to conduct the meeting.

Teams tend to worry too much about getting the likelihood right. It's much more about getting the gist of the likelihood right – is it more or less likely than a typo in an email, more or less likely than being struck by lightning. If you're trying to figure out if the likelihood is 45% or 48%, you're too far in the weeds.

Jenny Wanger

I have used this premortem format at SpotHero, the Linux Foundation, and with consulting clients to improve cross-functional coordination and de-risk complex product launches.

The Premortem Explainer for Software Development Teams

A premortem is a technique you use prior to a product launch to help anticipate any major issues and plan around them. The term was originally developed by cognitive researcher Gary Klein and the concept was launched by his article in the 

A premortem gets a bunch of people in a room together to hypothesize why a project, initiative, or launch might fail. They then prioritize the issues and create action plans to address the most critical ones.

I’ve used this meeting technique frequently to de-risk upcoming project launches and it is one of my favorite product management techniques. 

It’s best for initiatives where there's a lot of cross-functional work involved; if the feature release is minor and doesn’t require customer announcements or changes to sales processes then it probably isn’t going to be as helpful.

I've created a Figjam template that you can use to host your own premortem

Premortems create psychological safety, allowing everyone to express their concerns and worries in a safe environment. As Klein writes in his article:

Projects fail at a spectacular rate. One reason is that too many people are reluctant to speak up about their reservations during the all-important planning phase. By making it safe for dissenters who are knowledgeable about the undertaking and worried about its weaknesses to speak up, you can improve a project’s chances of success.

Launching products is hard and there are a lot of moving parts and dependencies. A premortem can help the team visualize and understand these dependencies, and increase empathy for the work that everyone across the company needs to do to make sure a product launch is successful.

Premortems work best when there’s a diverse, but not too large, group in the room. I always set a goal of between 8-12 people across as many departments as possible. I make sure to bring in people who are divergent thinkers and the worrywarts.

At a minimum, the group needs to include someone from each of the following departments:

If you have more than 12 people you want to involve, I suggest doing two sessions, each with a cross-functional group.

One person needs to be the facilitator. This is most frequently someone from the core product team itself.

The sweet spot for conducting premortems is after enough solutioning has been done that there’s a clear idea of what is being built, but not so late that it’s hard to make adjustments and changes to plans already in place. 

This means earlier for larger initiatives. No matter what, I would aim to do it no less than four weeks before target launch, and the sweet spot is probably more like eight weeks.

This assumes all the standard meeting preparation has happened; you have chosen your list of attendees, invited them at a specific time, sent out this explainer to them so they know what to expect, etc.

The meeting agenda should include links to any project plans, documentation, etc that define what the project is. Everyone coming into the room should already have a shared understanding of the initiative.

Optional: If you’d like to do a shorter meeting and your company has a culture of doing pre-work, ask everyone to do their brainstorming ahead of time and bring the list in. 

No matter what, invite people in the agenda to begin thinking about all the disaster scenarios.

We want you to be pessimistic about everything

We want you to think about unusual scenarios that might happen

Be supportive of your peers, no matter what

Remind everyone of the context of the project and what upcoming target dates and timeframes are. Make sure that everyone knows what the desired impact of the initiative is. Write that desired impact down.

Invite everyone to write their ideas down (if they haven’t already). It should be one idea per post-it note. Use the following prompt:

Imagine a future in which things have gone terribly wrong. What was the reason?

If people feel stuck, use the following list to help them come up with more ideas:

Why did we not have the desired outcomes?

Why are our internal teams unhappy with us?

What did we misunderstand about our customer?

What surprised us that we weren’t expecting to happen?

What external factors outside of our control influenced our failure?

Have each person share the ideas they came up with. Each idea needs to only be shared once, so encourage everyone to 

discard ideas once they hear a colleague mention it.

 The explanation of each idea should be brief, just enough to get everyone to understand what’s on the post-it.

As each idea gets shared, it should be placed on a 2x2 matrix.

Likelihood: How likely is this scenario to happen? A data center being hit by an asteroid is low likelihood. A bug affecting a particular segment of users where it’s a complicated part of the codebase is probably high likelihood.

How much of a problem would this be for the company if it happened? A typo in a marketing email is probably low impact; an issue causing a system-wide outage would be very high impact.

The whole group should try to agree on where within the 2x2 each of these ideas go. It doesn’t have to be precise; if everyone is debating whether this idea is more or less impactful than just that one other idea, just place them next to each other.

At the end of this, you should have a board of ideas grouped into four categories:

: These are the items that you want to try and mitigate as much as possible ahead of time. Make sure you have a plan in place for each of them.

High impact/low likelihood and Low impact/high likelihood

: These are the items that you will need to decide on a case-by-case basis whether you do anything about it. If it’s easy to defend against now, it’s probably something you should do. If it’s hard to defend against now, you should probably make sure there’s at least monitoring in place to know if it does happen and the outline of a strategy around what to do if it does occur.

For every item within the high impact/high likelihood there needs to be a plan of action. Bring up each concern with the group – there may be some items where someone in the room knows that a mitigation measure has already been put in place or has already been queued up. For any where there isn’t already a plan in place to address the issue, assign an owner, a due date for a plan to be in place, and a due date for the mitigation to be completed.

For instance, if the concern was “we will have more traffic than anticipated and it will take down our application”, a good lead on the issue might be an engineer or QA lead. They would be asked to develop a plan for load testing by next Tuesday, and the load testing would need to be completed one week before target launch. Note that they might need data from other teams – they might work with marketing to figure out what the range for anticipated traffic could be – but that individual owns the issue.

If there are items in this category where prevention isn’t an option, then instead of a mitigation strategy the assignment will be to have a playbook ready. An example of this would be a concern such as “an influencer launches a negative campaign about this product on social media”. The playbook is in place so the relevant teams can respond quickly and in a well thought-out manner with talking points, as opposed to having to do a last minute scramble.

High Impact/Low Likelihood and Low Impact/High Likelihood

Go through each of these issues one-by-one. As a group, do a quick cost/benefit analysis to decide how much effort you want to invest in risk prevention around each item. Decide which of them needs mitigation, which need monitoring, and which the group is deciding to ignore. For any that need monitoring or mitigation, assign an owner, a due date for a plan to be in place, and a due date for the mitigation or monitoring to be set up/completed.

Agree as a group that this category will be ignored, as the investment in this category would not be worth the payoff.

All of your notes from the meeting should be shared in an easy-to-find location, and the team should have a clear visualization of all the follow-ups from after the meeting. Whoever is filling the role of project manager on the team should be the one tracking all follow-up tasks and making sure they are completed.

It may be that a risk was identified during the meeting that is a total show-stopper. Use the outcome of the premortem to make sure everyone is agreed that the timeline should or should not continue as before. Sometimes something is identified that makes the team realize the project should not proceed at all or should not proceed as planned. While never ideal, it is always better to identify those issues earlier rather than later, and it is a sign that the premortem is serving its purpose.

How to Run a Premortem for Product Launches from Avenir Design

The Premortem Explainer for Software Development Teams

What is a premortem?

Why do a premortem?

Sign up to see more