It was 3.10pm on a sunny afternoon in Spotify’s new Stockholm office.

The heat in the tiny room was stifling. People were packed in — sitting, standing, squatting — avoiding eye contact at all costs. The meeting was late to start but no one wanted to speak up.

The dreaded post-mortem had begun.

If you’ve ever sat through one of these retrospectives you can probably relate. Post-mortems are part and parcel of agile development. They were introduced to help teams course correct at the end of a project. The idea being that when you look back, you’ll be able to see what went well and what went wrong. So the goal is to stop teams from making the same mistakes again in the future. Pain plus reflection equals progress.

Sitting in that post-mortem meeting, I was surrounded by some of the most talented designers, engineers and researchers I’d ever worked with. We’d spent months working tirelessly on a project, doing our utmost to ship a break-out product. Ultimately though a lot of things had gone wrong and the final offering was just OK. The team was burned out. Stakeholder relationships were frayed. Customers weren’t that enthused about what we’d launched.

After an hour of heated debate, we’d identified the root causes of failure. Someone took minutes and action points were assigned. It was time to move on. Although we agreed to do things differently next time, it was still demoralising. Failing is never easy. It felt more like pain than progress.

If you think about it, post-mortems are a hugely expensive way to get learnings. You have to wait until there’s a dead body. Only then can you gain any insights from the autopsy. You’re also unlikely to make any timely changes as the post-mortem comes at the end of the process. The opportunity to make improvements has already passed.

What is a pre-mortem?

In contrast, pre-mortems are a way to prospectively gain hindsight. That means you can spot the potential pitfalls before you encounter them. Not after you’ve stepped on the landmine.

Instead of waiting until the end, a pre-mortem can be carried out when you kick off a new project. You can sit down with your team and raise any collective concerns. For product development, this helps you avoid building the wrong thing in the wrong way.

It’s also an empowering way to build trust amongst your peers. No arguments, no finger pointing — just a clear sense of what you need to change upfront to give your product the best chance of success.

A psychologist by the name of Gary Klein invented the pre-mortem technique. The framework is built on research carried out by Deborah J. Mitchell who found that prospective hindsight can vastly increase the odds of success for any project. Imagining that an event has already occurred increases the ability to correctly identify reasons for future outcomes by 30%.

Nobel prize-winner Danny Kahneman became so impressed by the pre-mortem that he labelled it his favourite de-biasing approach for making better decisions. In addition to helping teams plan more accurately, it can also encourage constructive criticism. Any project that gets closer to completion will be prone to optimism bias, confirmation bias and sunk cost effects.

What the pre-mortem does, which I think is beautiful, is that is legitimises dissent. Actually it turns things around, it rewards people for being imaginative and finding flaws in the current plan.

How do you run a pre-mortem in practice?

As part of the Product Buffs course, we share techniques on how to run an effective pre-mortem. We tend to focus on the product discovery process but the pre-mortem can be applied to any part of product development (or any project for that matter).

They’re relatively easy to set-up with just six main steps which I’ve set out below:

📓 Step 1 - Prepare before the meeting

Typically, you’ll want to book off at least an hour to run this meeting properly. You should extend the invite to the wider group who’ll be involved in getting the product to market. This might include founders, product managers, engineers, designers, researchers, business teams and customer support. Each role will bring a slightly different context to the meeting. This could prove invaluable when assessing the risks together. Diversity of thought is a huge bonus when running a pre-mortem.

Assuming that you’ll be running this meeting remotely, you’ll want to draft up two artefacts in advance.

Firstly, you should create a whiteboard which covers the main themes of the exercise. This whiteboard will include the worst case scenario, the reasons for failure and any action points. Some other questions you might want to address include:

Why would this project slip?
What does this project need that we don’t have?
What lessons have you learned from past projects?
What are you worried about?
What’s in our control vs out of our control?

To help save you some time, I’ve created a template whiteboard below.

You can access and copy the original pre-mortem template 👉 here 👈

Next, you’ll want to create an agenda and minutes for the meeting so you can synthesise all the learnings into one document. This can be easily shared around after the pre-mortem to group attendees and to any other interested parties. The written minutes will be easier to read through than the whiteboard so it’s worth investing in this.

🔮 Step 2 - Start by imagining the fiasco

When it’s time for the pre-mortem, the first thing you want to do is have a facilitator talk through the worst case scenario (eg the “fiasco”). In my experience, people are surprisingly good at being pessimists when they’re given the space to do that. This is a chance for your imagination to run wild — what’s the worst that could happen?

For a product discovery process, the fiasco might go something like this:


Picture this scenario - after 4 months of toil, you're attending a final customer interview session. You see the same pattern emerge in the first 5 minutes. You realise that the prototype is fundamentally broken. Your customers don't know how to use it and they can't see the value anyway. The new product is supposed to go live in a month but you now need to start over or admit defeat and bin it. Team morale is at an all time low. The leadership team have run out of patience.

✍️ Step 3 - Write down what could have caused this

Once the facilitator has explained the fiasco, you then give each attendee 15 minutes to write down all the reasons that they can think of that might have led to this situation. It’s best if this is done individually so that everyone has a chance to bring their own interpretation to the table.

It’s also worth reminding attendees that there’s no right or wrong answers. Any potential cause should be written down. You can even give out a prize to the most outlandish proposal. Remember that pessimism is to be rewarded.

📍 Step 4 - Group similar ideas together to form themes

Next you go around the room and have each attendee present back the various causes they come up with for the impending failure.

This is a refreshing exercise as new information always comes to light. You might find out that one of the key engineers doesn’t believe in the product direction. You may realise that you just don’t have the resources needed to deliver on time. You could even learn the team isn’t set up for success — perhaps there’s fundamental gaps that need to be plugged.

It usually takes 20 minutes to go through all the insights and map them together as a group. Afterwards, you’ll usually see four or five main themes emerge.

🎯 Step 5 - Discuss and identify the main threats

Not all risks are going to be show stoppers. So it’s worth spending 10 minutes going through the insights and identifying the most likely blockers.

When I’ve run pre-mortems in the past, the biggest threats are usually related to internal issues (aka people problems 😅). It’s rare that an external threat will pose as the largest risk. It tends to be some staffing mismatch or a misalignment around priorities and/or expectations.

After you’ve listed out the main threats and ranked them, you can move from problem mode into solution mode.

🚀 Step 6 - Assign action items and share the learnings

The last part of the meeting is about taking action.

You want a clear owner and a proposed remediation date to fix each issue. In my experience, the type of issue will dictate who the best owner might be. If it’s a feasibility issue then one of the engineers should own it. If it’s a desirability issue, then one of the researchers should put their hand up. If it’s a viability issue then the product owner is probably best placed to fix it.

The final act is to share that minutes back with the group. You can also share it more widely with other stakeholders. The more inclusive you are at this stage, the more likely it is that you’ll avoid the risks identified. Being proactive could save your product from dying. As Gary Klein summed up in his HBR article:

In the end, a pre-mortem may be the best way to circumvent any need for a painful postmortem.

Conclusion

The other huge benefit that you get from running a pre-mortem is the cathartic effect it has on a team. Amy Edmonson has written about the problems that arise from ‘teaming’ with low psychological safety amongst colleagues. This is even more apparent in a pandemic world of hybrid and remote working teams.

A pre-mortem can act as an antidote to these problems. It increases trust and helps teams bond over a shared desire to avoid catastrophe. It can even be fun if you run it the right way.

If you’d like to take the template and try if for yourself, just copy it here. If you’ve got any questions or feedback, please feel free to reach out 🤙

Cheers,

Craig.

Craig's Newsletter

How to Avoid Product Autopsies