How to Run a Pre-Mortem: Anticipate Failure Before It Happens

A pre-mortem is a risk identification technique where you imagine a project or decision has already failed, then work backwards to list the reasons why. Unlike a post-mortem, which analyzes failure after it occurs, a pre-mortem analysis surfaces potential problems while you can still prevent them. This prospective hindsight approach, developed by psychologist Gary Klein, overcomes the optimism bias that blinds teams to risks they don't want to see.

The core insight is psychological: once you assume failure has happened, your brain stops defending the plan and starts explaining the failure. This shift unlocks candid thinking that's difficult to access when everyone is invested in success. Pre-mortems work because they give people permission—even an obligation—to voice concerns they might otherwise suppress.

A pre-mortem is not a replacement for traditional risk assessment. It's a complement. Risk registers list known risks; pre-mortems surface the ones you haven't thought of yet. Run a pre-mortem before any major launch, strategic decision, or initiative where failure would be costly and reversing course would be difficult.

Running a pre-mortem takes 45–90 minutes and works best with 4–10 participants who have direct knowledge of the project. Here's how to facilitate one that produces actionable output rather than a list of worries.

Step 1: Set the scene. Gather your team and describe the decision or project in one sentence. Then say: 'Imagine it's [date 6–12 months from now]. We launched, and it failed badly. Not a minor setback—a clear failure. Your job is to explain why.' Give the team a moment to internalize this framing.

Step 2: Generate failure reasons individually. Give everyone 5–7 minutes of silent writing time to list reasons the project failed. Individual work prevents groupthink and ensures quieter team members contribute. Aim for at least 5 reasons per person.

Step 3: Share and cluster. Go around the room, with each person sharing one reason at a time. Record each on a whiteboard or shared doc. Continue until all unique reasons are captured. Then cluster similar reasons into themes—you'll typically see 5–8 clusters emerge.

Step 4: Score likelihood and impact. For each cluster, have the team estimate likelihood (1–5 scale: how plausible is this failure mode?) and impact (1–5 scale: how damaging if it happens?). Multiply to get a risk score. This prioritizes where to focus mitigation efforts.

Step 5: Identify mitigations. For the top 3–5 risks by score, brainstorm specific actions that would reduce likelihood or impact. Assign an owner and deadline to each mitigation. These become line items in your project plan, not just discussion points.

A pre-mortem, post-mortem, and risk register all deal with failure, but they serve different purposes at different times. Understanding when to use each prevents both over-engineering and blind spots in your risk management.

A pre-mortem happens before you commit. It's a one-time exercise to surface unknown risks by imagining failure. The output is a prioritized list of risks and mitigations that feeds into your plan. Pre-mortems excel at catching risks that aren't in any template because they tap into your team's tacit knowledge of what could go wrong.

A risk register is an ongoing artifact that tracks known risks throughout a project. Unlike a pre-mortem, it's updated continuously as new risks emerge or old ones are resolved. Risk registers are operational—they ensure nothing falls through the cracks. Pre-mortem findings often become the initial entries in a risk register.

A post-mortem happens after something ends—either a failure or a completed project. Its purpose is learning: what happened, why, and what to do differently next time. Post-mortems create organizational memory. If you run pre-mortems well, your post-mortems become less painful because you've already addressed the predictable failures. For deeper analysis of what caused a past failure, see root cause analysis.

Consider a SaaS company planning to launch a new Enterprise tier at $499/month (up from their current top tier at $199/month). The VP of Product gathers the cross-functional team—product, engineering, sales, marketing, and customer success—for a pre-mortem. Here's how it unfolds.

After the framing ('It's six months from now, the Enterprise tier launch failed'), the team generates 32 individual failure reasons. Clustered, these consolidate into seven themes: (1) price-value gap—customers don't see $300/month more value, (2) sales team unprepared—reps can't articulate the value proposition, (3) feature gaps—promised features ship late or buggy, (4) existing customer backlash—mid-tier customers feel nickel-and-dimed, (5) competitive response—a competitor undercuts or matches, (6) positioning confusion—unclear who Enterprise tier is for, (7) implementation complexity—onboarding takes too long.

The team scores each cluster. Price-value gap: likelihood 4, impact 5, score 20. Sales unprepared: likelihood 4, impact 4, score 16. Feature gaps: likelihood 3, impact 5, score 15. Existing customer backlash: likelihood 3, impact 4, score 12. Competitive response: likelihood 2, impact 4, score 8. Positioning confusion: likelihood 3, impact 3, score 9. Implementation complexity: likelihood 2, impact 3, score 6.

The top three risks get mitigations. For price-value gap (score 20): conduct 10 customer interviews with willingness-to-pay questions before finalizing price; create an ROI calculator showing $499 delivers 5x+ return. Owner: Product Marketing, deadline: 4 weeks before launch. For sales unprepared (score 16): develop Enterprise-specific battlecards and run two mock-pitch sessions per rep. Owner: Sales Enablement, deadline: 2 weeks before launch. For feature gaps (score 15): define a 'must-have vs. nice-to-have' feature list and create a contingency plan if must-haves slip. Owner: Engineering Lead, deadline: 6 weeks before launch. These mitigations become tracked items in the project plan, with status reviewed weekly.

Run a pre-mortem whenever you face a decision or launch where failure is costly and hard to reverse. The investment—an hour of team time—pays off disproportionately when the stakes are high. If failure would be cheap or easily corrected, skip the formality and move faster.

Classic pre-mortem moments include: launching a new product or major feature, entering a new market, making a significant pricing change, undertaking a reorganization, signing a large contract or partnership, and committing to an ambitious deadline. These share two traits: meaningful downside if wrong, and limited ability to course-correct once committed.

Pre-mortems also help when a team is overconfident. If everyone agrees the plan is solid and you're suspicious of the unanimity, a pre-mortem forces the dissent that groupthink suppresses. Conversely, if the team is already pessimistic and demoralized, a pre-mortem can pile on—consider whether the exercise will surface new concerns or just amplify existing ones. For more on writing clear objectives before committing, see how to write a problem statement.

The most common mistake is running a pre-mortem but not following through on mitigations. A list of risks without assigned owners and deadlines is just a worry list. The pre-mortem's value comes from what you do with the output, not from the catharsis of voicing concerns.

The second mistake is letting senior voices dominate. If the HiPPO (highest paid person's opinion) dismisses risks early, junior team members stop contributing. Enforce silent individual brainstorming and collect all inputs before discussing. Anonymous submission can help in hierarchical cultures.

The third mistake is being too abstract. 'Execution risk' isn't actionable. Push for specifics: Which part of execution? What exactly fails? The more concrete the failure reason, the more concrete the mitigation. If someone says 'we might not have enough resources,' ask 'which resources, for which tasks, and what happens when we run short?'

Finally, avoid running the pre-mortem too early or too late. Too early, and the plan is too vague to critique meaningfully. Too late, and there's no time to act on findings. The sweet spot is after the plan is concrete enough to evaluate, but with enough runway to implement mitigations—typically 4–8 weeks before a major launch.

How is a pre-mortem different from brainstorming risks? The framing makes the difference. Brainstorming risks asks 'what could go wrong?'—which invites optimistic dismissal. A pre-mortem says 'this failed, explain why'—which demands explanation. The psychological shift from prevention to explanation surfaces more candid and complete concerns.

How many people should participate in a pre-mortem? Aim for 4–10 participants with direct knowledge of the project. Fewer than four limits perspective diversity. More than ten makes facilitation unwieldy and reduces individual airtime. Include people who will implement the plan, not just those who designed it.

Can I run a pre-mortem alone? Yes, though it's less effective. Write down your failure reasons, score them, and identify mitigations. The technique still helps by forcing you to articulate concerns you've been avoiding. But the real power of a pre-mortem is aggregating diverse perspectives, so involve others when possible.

What do I do with risks I can't mitigate? Some risks are outside your control—economic downturns, regulatory changes, competitor moves. Acknowledge these as assumptions and monitor for early warning signs. If a non-mitigatable risk has high likelihood and high impact, it may be a reason to reconsider the project entirely. A decision matrix can help weigh whether to proceed despite uncontrollable risks.

How does a pre-mortem fit with hypothesis-driven problem solving? A pre-mortem generates hypotheses about what could go wrong. Each failure reason is a hypothesis ('customers won't see the value') that you can test before launch—through customer interviews, pilots, or other validation. The mitigations are your experiments. For more on structuring hypotheses, see hypothesis-driven problem solving.

A pre-mortem is one of the highest-return exercises in project planning because it converts hidden concerns into visible, addressable risks. The technique is simple enough to run in under an hour, yet powerful enough that organizations like the US Army and major consulting firms use it routinely.

To run your first pre-mortem, pick an upcoming decision or launch with real stakes. Gather your team, set the 'this has failed' framing, collect individual failure reasons, cluster and score them, and assign mitigations to the top risks. The output should be 3–5 specific actions with owners and deadlines—not a document that lives in a folder.

Razn is a workspace for structuring problems into issue trees, testing hypotheses, and writing answer-first recommendations. When your pre-mortem surfaces complex risks that need deeper analysis—understanding root causes, prioritizing across multiple dimensions, or building a business case for mitigation investment—Razn helps you structure that work. Start with the pre-mortem to surface what could go wrong, then use structured problem-solving to figure out what to do about it.