Premortems are a marvelously powerful tool for teams trying to shift their product culture. They naturally move teams towards shipping smaller and more frequently, increase cross-departmental communication, and encourage good user research hygiene. Paired with retros, they become the foundation of how I help product development teams evolve.
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 hope you enjoy it as much as I do. If you have questions before running your next premortem, drop me a line.
What is a premortem?
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 Harvard Business Review.
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.
To help you along with this, I’ve created a Figjam Template that you can use to host your own premortem.
Why do premortems?
It’s a great way to build more cross-departmental collaboration into your product culture.
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. Premortems 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.
Who should be involved in a premortem?
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 worrywarts.
At a minimum, the group needs to include someone from each of the following departments:
- Product
- Design
- Engineering
- QA
- Sales
- Marketing
- Customer support
- Operations
If you have more than 12 people you want to involve, I suggest doing two sessions, each with a cross-functional group. Sometimes engineering teams will also run a technical premortem of their own.
One person needs to be the facilitator. This is most frequently someone from the core product team itself.
When should you do premortems?
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.
How do you run a premortem?
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.
Open the meeting
Set the ground rules –
- More ideas are better than good ideas
- 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.
Ideation
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 miss the target timelines?
- Why did we not hit our metrics?
- Why did we not have the desired outcomes?
- Why are our customers unhappy with us?
- Why are our internal teams unhappy with us?
- What technical issues caused problems?
- What design issues caused problems?
- What did we build incorrectly?
- What did we misunderstand about our customer?
- Were there issues around communication?
- What surprised us that we weren’t expecting to happen?
- What external factors outside of our control influenced our failure?
Sharing
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.
Categorization
As each idea gets shared, it should be placed on a 2×2 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.
- Impact: 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 2×2 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:
- High impact/high likelihood: 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.
- Low impact/low likelihood: Ignore this category.
Work through the categories
High Impact/High Likelihood
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 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.
Low Impact/Low Likelihood
Agree as a group that this category will be ignored, as the investment in this category would not be worth the payoff.
What do you do after the premortem?
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 agrees 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 shutting down an initiative is a sign that premortems are serving their purpose.