What is a product pre-mortem?

A product pre-mortem is a structured brainstorm where the team imagines a hypothesis or project has already failed, then works backwards to identify which assumptions were false. Unlike a risk assessment, a pre-mortem accepts failure as a given and asks what must have been false — bypassing optimism bias and surfacing more specific, actionable risks.

When should you run a pre-mortem in product development?

Run it after forming a hypothesis but before investing significant resources in validation or build. It is most valuable when the team is aligned on a direction but has not explicitly articulated what must be true for it to work, or when a stakeholder is pushing hard for something and the team senses unspoken concerns.

How is a pre-mortem different from a risk register?

A risk register lists risks in the abstract. A pre-mortem produces testable assumptions — specific, positive claims that must be true — which can be directly handed off to data mining or customer research. Risk registers tend to stay in decks; pre-mortem assumptions become active validation work.

Playbook

Pre-mortem

Run Pre-mortem

Pre-mortem experiment that surfaces hidden assumptions in a hypothesis. Simulates failure, identifies testable claims across risk dimensions, and produces an experiment report.

Use when

•Before committing to build something, to surface risks the team has not articulated
•After forming a hypothesis, before running data mining or customer interviews
•When a stakeholder is overconfident about a bet and you want a structured way to surface concerns
•During quarterly planning, to stress-test which bets are actually well-founded

What You Get

Assumption
Testable claims — each with a risk type and risk level — that must hold for the hypothesis to succeed. These become the input for data mining and customer validation experiments.
Experiment Report
A structured risk profile: total assumption count by risk type, mandatory assumptions highlighted, overall risk assessment, and recommended next steps.

How It Works

1
Imagine failure
Project six months into the future and assume the hypothesis was proven wrong. The idea shipped but did not move the needle. Work backwards from that premise.
2
Brainstorm failure causes across four risk dimensions
For each of Cagan's four risk dimensions — value, usability, feasibility, and viability — ask what failure would have looked like in that category.
3
Distill into testable assumptions
Convert each failure mode into a positive, specific, testable claim that must be true for the hypothesis to succeed. Aim for ten to twenty assumptions.
4
Classify risk levels and save the report
Assess each assumption as mandatory, high, medium, or low risk. Record the full risk profile and highlight mandatory assumptions — these are the first to validate.

Why pre-mortems surface what retrospectives miss

Retrospectives look backwards at what went wrong. Pre-mortems look forwards — imagining failure before it happens so the team can address risks while there is still time to change course. The technique forces you to bypass optimism bias by accepting failure as a premise, then reasoning backwards: if this failed, what would have been false? Each failure mode becomes a testable assumption that can be validated, monitored, or designed around before a single line of code is written.

Who it's for

Run before committing to significant discovery or delivery investment. The output feeds directly into data-mining experiments — the mandatory assumptions from the pre-mortem are the ones to test first.

Product Manager

Founder

Product Strategist

Frequently asked questions

What is a product pre-mortem?: A product pre-mortem is a structured brainstorm where the team imagines a hypothesis or project has already failed, then works backwards to identify which assumptions were false. Unlike a risk assessment, a pre-mortem accepts failure as a given and asks what must have been false — bypassing optimism bias and surfacing more specific, actionable risks.
When should you run a pre-mortem in product development?: Run it after forming a hypothesis but before investing significant resources in validation or build. It is most valuable when the team is aligned on a direction but has not explicitly articulated what must be true for it to work, or when a stakeholder is pushing hard for something and the team senses unspoken concerns.
How is a pre-mortem different from a risk register?: A risk register lists risks in the abstract. A pre-mortem produces testable assumptions — specific, positive claims that must be true — which can be directly handed off to data mining or customer research. Risk registers tend to stay in decks; pre-mortem assumptions become active validation work.