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. For a blow-by-blow of one in action, see this premortem on a product launch that almost shipped broken.

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.

The 90/60/30 Premortem Cadence

Most premortem advice treats it as a one-shot meeting at the start of a project. That model leaks: risks identified at kickoff stop being tracked once execution starts, and risks that emerge mid-execution have no formal venue to surface. The 90/60/30 Cadence is a named alternative — three premortems scheduled at fixed pre-launch checkpoints, each with a deliberately different shape.

The rhythm:

Checkpoint	Meeting shape	What you're looking for	Output
90 days before launch	Broad risk surface — full team + 2 outside skeptics, 90 minutes, no constraints on what counts as a risk	Strategic and structural risks: wrong target customer, wrong scope, wrong timing, missing capabilities, unrealistic timeline	A long, messy list. 20-40 candidate risks clustered into 5-7 themes. Most of these never get acted on individually — but the clustering tells you what type of project this is.
60 days before launch	Narrowed list with mitigations — execution leads only, 60 minutes, focused on the 90-day output	Which of the 90-day risks are now real, which were noise, and which are still hypothetical	A list of 5-8 risks with a named owner and a specific mitigation each. The 60-day meeting is where the project plan actually changes.
30 days before launch	Final reality check + monitoring assignments — full team back, 45 minutes, tight agenda	Which risks are now mitigated, which are accepted (we'll live with them), which are still uncontrolled. Plus: anything that emerged in the last 30 days that nobody anticipated.	A go/no-go-conditioned launch checklist. Each remaining risk has a category: "mitigated", "accepted", "monitored", or "blocker". Blockers stop the launch.

Why three checkpoints, not two or four:

• One is the standard advice and fails for the reason above — the meeting becomes ceremonial
• Two (kickoff + pre-launch) miss the mid-execution drift where risks shift category
• Three matches the natural arc of a 90-day project: discovery (Day 1-30), execution (Day 31-60), final commit (Day 61-90). One premortem per phase forces the team to actually re-read its own analysis.
• Four or more becomes meeting overhead; the team starts defending instead of surfacing

What changes between the meetings:

• Attendance: full team → execution leads only → full team. The 60-day narrowing prevents social pressure from over-extending the list; the 90- and 30-day broadness prevents the execution leads from rationalizing.
• Time: 90 → 60 → 45 minutes. The shape of the meeting forces the appropriate level of detail at each stage.
• Question prompt: "what would make this fail?" → "of these, which are now real?" → "what hasn't been mitigated, and what's the plan?"

Tools and post-meeting protocol:

• The 90-day list goes into the project's risk tracking doc, organized by cluster
• The 60-day mitigations become explicit line items in the project plan, with owners
• The 30-day output becomes the launch checklist, with go/no-go authority for each blocker

For projects shorter than 90 days, compress proportionally: a 30-day project gets premortems at Day 1, Day 15, and Day 25. The shape — broad → narrow → final-check — stays the same.

For longer projects (multi-quarter initiatives), the Cadence runs at the start of each quarter rather than at fixed days. Most teams find that the 90/60/30 pattern transfers cleanly: a one-year initiative gets premortems at Q1-kickoff, Q2-narrowing, and Q3-final-check, with Q4 reserved for execution against an already-locked plan.

For when to choose this versus the lighter-weight cousin, see Reverse Brainstorming and Premortem vs Postmortem.

Related frameworks

• Premortem — catalog entry & template — the quick-reference worksheet for running one
• Cynefin Framework for PMP — premortems are the Complex-domain partner; Cynefin tells you when to reach for one
• Premortem vs Postmortem — when to run each in the project lifecycle
• Reverse Brainstorming — inversion-thinking cousin of the premortem; lighter, generates options not just risks
• 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
• Premortem for a SaaS launch — industry playbook applying the premortem to a product launch

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