Most business projects begin with a confident slide. The launch date is set, the budget is approved, and everyone in the room can picture the announcement going out. What rarely appears on that slide is a candid list of the ways the launch could go wrong. A pre-mortem is a simple technique for producing that list. This explainer defines the term in plain language, shows how a small team can use it before releasing a new product or service, and points out where it tends to go astray.<\/p>\n
You already know the post-mortem: after something fails, the team meets to work out why. A pre-mortem swaps the order. Before the work is finished, the team assumes it has failed and asks, “What was the most likely cause?” The imagined failure is the starting point, and the reasons are written as though they were already history.<\/p>\n
The reversal matters because of how people behave in planning meetings. Raising a concern can feel like criticising a colleague or doubting the plan. When the premise is that failure has already happened, concern becomes a contribution rather than an objection. People who stayed quiet in the planning stage often produce the most useful items.<\/p>\n
Optimism is useful for starting things and unreliable for checking them. A team that has worked on a plan for weeks sees the steps that are present and overlooks the ones that are missing. The pre-mortem adds a deliberate pause to look for the missing steps while changing them is still inexpensive. A fix in the planning week might cost a conversation. The same fix after launch might cost customers.<\/p>\n
Imagine a small company about to open a new online ordering service. The team is excited, and the plan covers the website, the payment page and the marketing email. A pre-mortem would proceed in four short steps.<\/p>\n
The notes from that ordering-service example might include: customers could not find the order button on a phone; the payment provider flagged early transactions for review; support staff were never told about the new service; and the one developer who understood the checkout was on holiday during launch week. None of these is a technical marvel. All are ordinary, and all are preventable.<\/p>\n
Across different industries, the imagined failures fall into a handful of familiar families. It can help to keep the list in front of the team to prompt memory.<\/p>\n
For any team that ships software, one imagined failure deserves particular space on the wall: the release itself. Code travels through a build and delivery chain before it reaches users, and that chain can break or be misused. DevSecOps Now<\/a> is a DevSecOps site whose blog is largely about securing CI\/CD pipelines, which makes it a handy reading list for teams wanting vocabulary for this part of the pre-mortem.<\/p>\n You do not need to become a security specialist to benefit. Ask the plain question: “If the release failed, which step in our delivery chain would we suspect first, and who would notice?” The answer often reveals an unowned step.<\/p>\n Teams that build a growth plan can use the same frame on each major bet. If your plan relies on bringing customers in through the product itself, then the assumptions underneath it are worth testing. A discussion of building growth around the product experience<\/a> lays out the logic of that approach, and a pre-mortem is the natural companion: assume the bet did not pay off and ask which assumption was wrong.<\/p>\nTurning a business plan into a pre-mortem prompt<\/h2>\n