How to run a premortem (and why every team should)

A premortem is a structured pre-launch exercise where you assume the project has failed and work backwards to identify what would have caused the failure. The premise sounds gimmicky and the execution takes 45 minutes; the output regularly catches problems that would otherwise surface six months in, when they're 10× harder to fix.

The technique was popularized by Gary Klein in a 2007 Harvard Business Review article. Research Klein cited at the time suggested that the act of imagining a future event has happened ("prospective hindsight") increased the team's ability to identify causes by roughly 30%. The mechanism is simple: when you ask "what could go wrong," people stay diplomatically optimistic; when you ask "given that we failed, what happened," people get specific.

When to run one

The window for a premortem is after a plan is concrete enough to fail and before the team has emotionally committed to executing it. Specific moments:

• A week before launching a new product, feature, or marketing campaign
• At the start of a multi-quarter initiative, before the kickoff meeting
• When a partnership or acquisition is in the late stages of due diligence
• After a strategy decision is made but before the budget is locked
• Before a hire who will shape a function (head of sales, first PM)

Skip premortems for reversible decisions or routine work — the overhead is wasted. Save them for the bets where the cost of failure is high and the timeline is long.

How to run one in 45 minutes

1. Set the frame, then stop talking (5 min). Open with: "It is 12 months from now. Our project has failed. We are doing the postmortem. Spend the next 10 minutes writing down, individually, everything that went wrong." Then stop. Do not soften, do not list examples — every example you give narrows what people are willing to imagine.
2. Silent writing (10 min). Everyone writes their own list. No talking. The silence matters: it removes the social pressure to converge on the loudest opinion, which is the failure mode of an open brainstorm. Senior people should write fewest examples first, junior people loudest, to counter the seniority bias.
3. Round-robin readout (15 min). Each person reads one item from their list. Capture each on a sticky note or doc. Loop until everyone has read everything. Don't debate yet.
4. Cluster and prioritize (10 min). Group sticky notes by underlying cause. Three or four clusters will dominate — those are the real risks. The clusters often surprise even the people who wrote the notes, because no individual person wrote the cluster, the group did.
5. Decide what to do (5 min). For each top cluster: do we mitigate now, monitor with a tripwire, or accept and document the risk? Assign an owner to each.

The total exercise should never exceed 60 minutes. If the team can't surface real risks in 45 minutes, the problem isn't the time — it's that the team isn't safe enough to be honest, and fixing that is upstream of any framework.

What makes a premortem actually work

Psychological safety is the precondition. If the team can't say "the founders disagreed about strategy and the team felt it," the premortem will surface only safe risks (the build will be late) and miss the real ones (the founders disagree about strategy and the team feels it). A premortem in a team without safety is theater.

The facilitator should not contribute. If the facilitator writes their own risks, the team anchors on those. The facilitator's only job is to keep the silence, run the readout, and refuse to soften what's said.

Write down the dissent. Even if a risk doesn't make the top cluster, save it. Six months from now, when one of those bottom-of-list risks becomes the actual failure mode, you'll want the record.

Common failure modes

• The facilitator leads with examples. Killed the exercise before it started — every subsequent answer is a variant of the example.
• One senior person dominates the readout. Switch to a written round-robin to neutralize.
• The output is filed and forgotten. Add the top 3 clusters to the project's weekly review until they're either resolved or accepted.
• The team treats it as a vote of no-confidence. Frame the exercise as "the project will succeed because we ran this," not "we're checking whether to cancel."

When a premortem isn't enough

Premortems surface known unknowns — risks the team can imagine. They don't surface unknown unknowns. For genuinely novel work (new market, new technology), pair the premortem with a pre-parade (the imagined-success counterpart) and a red team review to widen the aperture.

If you find the same risks every time you run a premortem on every project, the team has a systemic problem upstream of any single project — fix that first.

Related frameworks

• SWOT analysis — broader strategic surface for the same question
• FMEA — heavier-weight industrial cousin of the premortem
• Risk matrix — for ranking the premortem's output by likelihood × impact
• Inversion — the mental model underneath premortems

Want to run one right now? Open the premortem tool → and start writing.