My product management toolkit (24): ‘pre-mortem’

6 min readOct 16, 2017

As helpful as ‘post-mortem’ sessions can be, how often do you find yourself wondering: “if I’d only thought about that beforehand!” In a medical environment, a post-mortem creates the opportunity for health professionals and the family to establish the patient’s cause of death. With digital products, a post-mortem typically happens at the end of a project or after a big product release. It’s similar to Agile retrospectives which often take place more regularly; the goal is to reflect on areas for improvement and related actions.

With a pre-mortem, the idea is to think about a project or a piece of work before commencing it. A pre-mortem can be done either as a group or as an individual exercise, and participants need to imagine the product or project to have failed (see Fig. 1 below).

For example:

“This product has failed because nobody wanted to pay for it”

“The product was never released in the end because the regulator refused to approve the product and its underlying business model”

“The product has failed because many of its users complained about its poor user experience”

“The product failed because we the design & build project had to be rushed in the end to get it over the line?”

A pre-mortem thus enables you to start working backwards, and look at the individual factors that could lead to failure as well as the actions to take in order to pre-empt failure. Once you’ve identified these factors, you can start thinking about how to best avoid or mitigate these risks from occurring.

Naturally, it’s up to you to figure out how to best structure your pre-mortem, but these are some aspects that you might want to consider:

The product has bombed — Rather than consider the possible failure of a product or a project, in the pre-mortem the product is assumed to have failed. Similarly, if you’re doing a pre-mortem at the start of a project, it’s really helpful if all the participants in the pre-mortem think of any reason why the project could fail dramatically.
Categorise failures — When getting people to think about the reasons for failure, I always find it helpful to think about failures in specific areas, dependent on your product, market or organisation (see Fig. 2 below).
Does this mean that nothing will go wrong!? — Of course, things will not go according to plan and unexpected things will still happen. However, right from the get go, you’re creating an environment that allows people to think about and continuously talk about risk. You’re effectively creating an environment where people can speak freely about potential risk scenarios, without fear of being seen as impolite or difficult.
Identify threats and risks — There are a number of ways to elicit risks and threats from the pre-mortem. You could do a simple ‘brain dump’ for example. Alternatively, you could try a more structured approach whereby people need to come up with risks within certain areas (see “Categorise failures” above).
Analyse likelihood — Once you’ve collated threats and risks, you can use a simple scale ranging from “highly unlikely” to “highly likely” to assess likelihood of a specific risk or threat materialising. I’ve found that the activity of placing risks against the aforementioned scale, helps creating a shared understanding of the biggest risks. It also focuses the mind on the actions that need to be taken or things that need to be in place to mitigate risk.
Are the right people in the room? — When running a pre-mortem session with a number of people, it’s important to make sure you’ve got the right people in the room. For example, if you’re looking to work on a digital product, it’s important to have developers and designers present. Similarly, if you’re working in a highly regulated industry, having a compliance person brainstorming upfront about potential risks will go a long way.
Brainstorm and assess preventative actions — Once you’ve collectively established your highest risks, you can start thinking about ways to mitigate these risks. Realistically, you might not be able to stop all risks from happening (think about a garden party being impacted by a sudden rain downpour …). In these scenarios, you can still figure out how to best reduce the impact of a risk happening and come up with a ‘plan B’. For example, if the heavens open during your garden party, people could always seek shelter in the tent that you put up ‘just in case’.
Not a one off exercise! — The risks and actions that you identify during your pre-mortem are something that you can use as ongoing reference point. “How are we doing we against risk X?” or “We can see risk Y materialising soon, how can best pre-empt things?” A regular product retrospective offers a great opportunity to take a step back from the day-to-day and look at the risks involved with your project or product.

Fig. 1 — Pre-Mortem by Dave Gray — Taken from: http://gamestorming.com/pre-mortem/

Fig. 2 — Possible failure categories to consider:

Marketing — Think upfront about what could go wrong with your product’s go-to-market strategy and the marketing channels that you’re looking to use. For example, what would be the impact be if product messaging fails to resonate with your target audience?
Customer — What if customers don’t want to pay for our product? What if we’re addressing the wrong customer segment? What if we’ve got customer needs wrong?
Technology — The chosen technology implementation doesn’t work, what do we do? The technology isn’t scalable!? At this stage, it’s very valuable to explore the complexities or unknowns related to the technical implementation. As a group, you might agree on running discovery sprints to test certain technologies or non-happy path scenarios to deal with some of the ‘unknown unknowns’ being discovered early on.
Stakeholders — I know some people like stakeholder mapping, but the pre-mortem can also help in figuring out who the relevant stakeholders are and how they’d need to be communicated with. Also, when look at the different risk areas, it can be very helpful which stakeholders have the most knowledge in a particular domain.
Cost — What if our budget gets slashed halfway through the project? What if costs spiral because we failed to budget properly? What if the technology we’ve chosen turns out to be far too expensive or complex to implement?
Compliance — Compliance and regulatory aspects are easy ones to forget at the start of a project. However, compliance can have a massive impact on a product or a project. For instance, I was involved in a project where we only found out halfway through that launching in China would be very tricky from an internal compliance and external regulation point of view. This proved to be a major stumbling block and it would have been good if we could have identified this as a major project risk beforehand.
Competition — What if your direct competitor launcheds the same product as yours, but just a bit quicker? Or we imagine a situation where the product has failed because the competitor lowered its product price. Do we need a plan B for when this scenario happens? If so, what should this plan look like?

Main learning point: Running a pre-mortem isn’t a substitute for fully planning projects upfront. You can do the best pre-mortem possible but things will still happen, and to which you’ll need to adapt. A good pre-mortem, however, will get people to think and be open about risk. It will help significantly in identifying and addressing risk early and often.

Related links for further learning:

My product management toolkit (24): ‘pre-mortem’

Written by MAA1