Pre-mortem

What it is

A structured exercise run before a major launch or initiative, developed by cognitive psychologist Gary Klein and published as "Performing a Project Premortem" in the Harvard Business Review (September 2007). The team imagines a specific future moment at which the initiative has already failed completely, then works backwards to generate concrete, specific reasons why, rather than brainstorming generic risks in the abstract. Klein's technique exploits what he calls "prospective hindsight": people are measurably better at generating specific explanations for an outcome they are asked to treat as already having happened than for one framed as merely possible, because stating failure as a fact removes the social pressure to defend a plan the group has already invested in and bypasses the natural reluctance to voice doubt about something everyone has agreed to. The resulting risks are then ranked, assigned owners and mitigations, and rolled into an explicit go or no-go recommendation. This is a different tool from Win/Loss Analysis Framework, already in this knowledge base, which is a post-hoc diagnostic run after deals close; nothing else in the existing 54 entries covers structured, pre-launch failure-mode analysis, and it pairs naturally with the Launch Tier Framework already in this category: tiering decides how much process a launch warrants, and a pre-mortem is the specific pre-launch risk step a Tier 1 launch's process should include.

When to use it

• Ahead of a Tier 1 launch (per the Launch Tier Framework), where failure carries real revenue, reputational, or cross-functional cost, and the launch is significant enough to justify a dedicated risk session rather than an informal gut check.
• The team is confident, and no one has voiced doubts in planning meetings. Unbroken consensus on a major plan is itself a signal worth investigating; the pre-mortem's framing is specifically designed to surface doubts that groupthink or seniority bias would otherwise suppress.
• A previous launch failed, and its postmortem showed the failure mode was foreseeable but never raised beforehand. A pattern of "we all sort of knew but nobody said it" is the clearest possible case for adopting this exercise going forward.
• The team is launching into unfamiliar territory (a new segment, a new GTM motion, a new geography) where less pattern-matching experience exists to catch risks informally.
• A major, hard-to-reverse cross-functional commitment is coming up (a keynote, an analyst briefing tied to the launch, a partner-dependent rollout) where reputational stakes are high and a late course correction is expensive.

Ownership

At a scaled company with a specialised PMM team, PMM typically facilitates the pre-mortem for a launch it owns, but the actual failure scenarios should be sourced cross-functionally: engineering and product supply technical and delivery risk, sales supplies go-to-market and adoption risk, and support or customer success supplies customer-facing risk. If the session surfaces a severe, uncontrolled risk, the resulting go or no-go recommendation escalates to whoever owns the launch decision, typically the executive sponsor a Tier 1 launch already carries under the Launch Tier Framework, rather than PMM deciding unilaterally to proceed or delay. At a solo or founding-PMM stage, that person facilitates the session and often supplies most of the scenarios directly, pulling in the founder or an early engineer for a fast, informal version rather than a full cross-functional workshop.

How to apply it

1. Assemble the team actually running the launch, plus a few genuine sceptics. Include people with a stake in the launch going well, not just its most enthusiastic advocates; on a small or highly cohesive team where a natural sceptic is hard to find, explicitly assign someone the role of designated dissenter for the session.
2. State the premise as an already-happened fact, not a possibility. Say explicitly: "It is [three to six months] from now. This launch has failed completely." Not "might fail," already has; this exact framing is what produces Klein's prospective-hindsight effect and generates more specific, useful reasons than an open "what could go wrong?" prompt.
3. Have every participant write down failure reasons individually and silently first, as many as they can generate in five to ten minutes, before any group discussion begins. Independent brainstorming before discussion prevents the most senior or vocal person's first guess from anchoring everyone else's list.
4. Go around the group and have each person read one reason at a time in turn, recording every one without debate or dismissal in the moment, so quieter participants or lower-status voices get their scenario heard before the group has a chance to talk over it.
5. Cluster the raw list into five to ten distinct failure themes, removing duplicates but preserving the specific detail that made each one useful; over-abstracting into generic categories ("execution risk") loses exactly the concreteness the exercise was designed to produce.
6. Score each theme on severity and likelihood using a fast high/medium/low rating rather than a precise statistical model, and rank the resulting list; the goal is a usable priority order, not a rigorous forecast.
7. Assign a named owner and a specific, dated mitigation to every top-ranked risk. "Something we should watch" is not a mitigation; a mitigation has an owner and a deadline before launch.
8. Decide whether any single risk, or a combination, is severe and likely enough to warrant delaying, rescoping, or cancelling the launch, and escalate that recommendation explicitly to whoever owns the go or no-go decision, rather than quietly proceeding once the session ends.
9. Revisit the risk list briefly at the actual post-launch review. Note which risks materialised, which did not, and whether the exercise caught anything that would otherwise have been missed in production; use the answer to calibrate how seriously the team treats the next pre-mortem.