Pre-mortem planning

What a pre-mortem actually does

A pre-mortem asks the team to imagine concrete reasons the initiative failed and to list them without assigning blame. The point is not pessimism but the generation of testable assumptions and early mitigations. By converting vague worries into specific failure modes, teams can prioritize monitoring, experiments, or contingency actions before launch.

Why teams adopt — and keep using — pre-mortems

Pre-mortems flourish where optimism bias, tight deadlines, and status-driven discussion combine. When proposals are presented late in the process, people feel pressure to agree and protect reputations. A facilitated pre-mortem creates permission to be critical and pairs that permission with a concrete agenda: identify failures, assess likelihood, and propose fixes.

This pattern is sustained by simple feedback: when a pre-mortem finds a real, preventable problem, leaders see its value and schedule it again. Conversely, if a session becomes a blame forum or lacks follow-through, teams stop taking it seriously.

How they appear in day-to-day meetings

• Facilitator states: “Imagine it’s six months after launch and the project failed.”
• Team members write reasons silently for 5–10 minutes.
• The group shares reasons round-robin while a scribe captures themes.
• The team clusters causes, rates their plausibility, and assigns next steps (tests, metrics, mitigations).

In practice these sessions tend to surface three categories of issues: overlooked technical dependencies, unrealistic user adoption assumptions, and organizational blockers (e.g., unclear handoffs). A healthy pre-mortem produces a short list of prioritized actions: experiments to validate assumptions, data sources to monitor, and explicit owners for contingency steps.

A workplace example

During a product-team sprint review, the group runs a five-minute pre-mortem. Participants surface that the onboarding flow assumes users will complete a three-step form — a risky assumption. The team agrees to A/B test a two-step flow and to instrument drop-off points. Two weeks later the data shows a 30% drop at step two; the team rolls back to the simpler flow and avoids a costly full launch.

This concrete example shows how a short, focused pre-mortem produced an experiment with measurable impact and a clear owner, preventing a larger problem after release.

Common misreads and near-confusions

• Pre-mortem vs post-mortem: A pre-mortem is prospective (before launch), while a post-mortem analyzes real failures after they occur. Confusing the two dilutes the benefit: using post-mortem templates in advance can lead to speculative lists without ownership.
• Pre-mortem vs devil’s advocate/red teaming: Devil’s advocacy can turn personal and adversarial; red teaming often assumes an external attacker’s perspective. Pre-mortems should be collaborative and structured to convert critique into mitigations.
• Scenario planning and risk registers: Scenario planning explores multiple futures at strategic horizons; risk registers catalog threats. Pre-mortems focus narrowly on a single near-term initiative and drive immediate, testable responses.

Teams often oversimplify pre-mortems as “negative brainstorming.” The clearer distinction is that pre-mortems always end with prioritized actions and measurable tests. Without that, sessions create a false sense of diligence while leaving root assumptions untested.

Questions teams should ask before running one

• What exact decision or launch date are we anchoring to?
• What would count as a failure at that horizon (metrics, user behavior, revenue, compliance)?
• Who must own follow-up tests and what are realistic timelines?
• How will we record and surface findings so they influence the plan?

Answering these makes the exercise practical instead of hypothetical. A pre-mortem that ends with assigned owners and measurable experiments becomes part of the project’s risk-control process rather than a one-off meeting ritual.