The 30-second version
A premortem is a planning exercise in which a team, before committing to a decision, imagines that the plan has already failed completely and works backward to list every plausible reason why. Cognitive psychologist Gary Klein described the technique in a 2007 Harvard Business Review article, "Performing a Project Premortem," built on earlier academic research into what is called prospective hindsight: a 1989 study by Deborah Mitchell, J. Edward Russo, and Nancy Pennington found that asking people to explain an outcome as though it had definitely already happened produced roughly 30% more correct, specific reasons than asking them to simply forecast what might happen. The premortem borrows that same trick for teams: assuming failure is certain removes the social cost of criticizing a plan everyone has just agreed to, because naming a flaw no longer feels like betting against the group — it feels like explaining history. A later study by Klein, Veinott, and Wiggins (2010) found that premortems reduced participants' overconfidence in a plan significantly more than standard critique or risk-review methods did. The result isn't a longer list of worries; it's a shorter list of the specific, well-reasoned failure modes a team actually acts on before it is too late to change course.
Mental Model Compass
Where Premortem Analysis sits next to three other models already in this collection about planning, forecasting, and misplaced confidence. Click a dot to see why it sits where it does.
Click or focus a dot to read why it sits where it does.
Build the idea, one step at a time
Gary Klein, a cognitive psychologist associated with the naturalistic decision-making movement, described the premortem in a short 2007 Harvard Business Review piece, "Performing a Project Premortem" (Vol. 85, No. 9, pp. 18–19). His contrast is medical: a standard pre-launch critique asks a doctor what might go wrong with a patient, which tends to produce a cautious, hedged list, since no one wants to seem overly negative about a plan the team has already agreed to pursue. A premortem instead tells the team the patient has died, and asks everyone to explain why. The framing is deliberately fictional and immediate — not a hedge about what could happen, but a flat statement that it already did — and that single change in verb tense is what does the psychological work.
Klein's technique formalizes an older research finding called prospective hindsight. In a 1989 study, "Back to the Future: Temporal Perspective in the Explanation of Events" (Journal of Behavioral Decision Making), Deborah Mitchell, J. Edward Russo, and Nancy Pennington found that people asked to explain an outcome they were told had definitely already occurred generated about 30% more specific, correct reasons for it than people asked to simply forecast whether it might occur. Treating an outcome as settled fact, rather than an open possibility, appears to free people to reason about causes more concretely — the same shift in mental stance a premortem asks a whole team to make together about a plan that hasn't happened yet.
In practice, a premortem follows a fairly specific sequence, and the sequence matters. First, the team is briefed on the actual plan: goals, scope, budget, and timeline, so everyone is reasoning about the same concrete thing. Second, everyone is told to assume the plan has already failed. Third — and this is the step most often skipped — each person spends a few minutes writing down their own reasons for the failure alone and in silence, before anyone speaks, so early or senior voices don't anchor everyone else's answers. Fourth, the group shares reasons round-robin, often with the leader going first to model candor, while someone records every answer without debate. Fifth, the team reviews the list and ranks items by likelihood and severity, since a medium-sized project's list of plausible failures can easily run past ten items and not all of them deserve equal attention. Sixth, the team builds specific mitigations, owners, and follow-up checks for the risks that rank highest — a premortem that stops at the list, with nothing acted on, has skipped the step that actually changes the outcome.
Klein's own explanation for why the technique works is less about the information it surfaces and more about the social permission it creates. Once a plan has momentum and the team feels early enthusiasm, raising a doubt in an ordinary meeting can feel disloyal, and people with real concerns often stay quiet to protect the group's harmony or their own standing. A premortem reframes the same doubt as simply explaining an already-settled fact, which removes the sense that the speaker is betting against the team or the plan. A 2010 study by Klein, Veinott, and Wiggins, presented at the International Information Systems for Crisis Response and Management conference, found that this structure reduced participants' overconfidence in their plans by significantly more than other standard critique and risk-review methods tested alongside it.
What it looks like in different fields
Before a system migration, a software rollout, or a facility move, a project lead gathers the team, states the go-live date as if it already happened and failed badly, and collects independent reasons before anyone discusses them aloud. The risks that surface are often organizational rather than technical — a missing sign-off, an under-resourced support rotation, a vendor dependency nobody double-checked — precisely the kind of risk a purely technical checklist tends to miss.
Before a product launch or a major strategic bet, a premortem run with marketing, engineering, support, and finance in the room together surfaces risks that a single department's own review would miss: a competitor response the strategy team didn't model, a support-ticket volume the product team didn't plan for, or a pricing assumption finance never actually validated with real customers.
Before extending an offer for a senior or hard-to-reverse hire, a hiring panel can run a short premortem: assume the hire has already failed by month six, and have each panelist independently write why. Disagreements that never surfaced in the interview debrief — mismatched expectations about scope, a skills gap everyone privately noticed but didn't say — often appear immediately once failure is assumed rather than merely risked.
Before a major personal commitment — a cross-country move, a large purchase, a career change — the same exercise works solo: write down, as though it already happened, every reason the decision turned out to be a mistake a year later. The exercise tends to surface the one or two real worries hiding underneath a long list of vague anxieties, which is usually more useful than either blind optimism or generalized dread.
Worked application: running a premortem before a product launch
- Brief everyone on the real plan first. State the actual launch date, scope, budget, and success metric, so the exercise is grounded in the specific plan rather than a generic worry session.
- Declare the failure as settled fact, not a risk. Say plainly: "It's six months from now, and this launch has failed." Avoid softer language like "might fail," which lets the old, hedged critique mode creep back in.
- Have everyone write independently and silently for two to three minutes before anyone speaks. This is the step most often skipped under time pressure, and skipping it is what lets the most senior or vocal person's answer anchor everyone else's.
- Collect every reason round-robin, with the leader going first. Record each one on a shared board without debating it in the moment; debate comes after the list is complete, not during.
- Rank the list by likelihood and severity. For a mid-sized launch, aim to narrow a long list down to the roughly ten risks that most deserve a mitigation plan, rather than trying to act on everything.
- Assign an owner and a mitigation or a concrete test to each top risk, with a date to check back. A premortem that produces a list but no owners and no follow-up has done the diagnosis and skipped the treatment.
Common mistakes
Skipping the independent, silent-writing step
Going straight to open discussion lets the most senior or most confident voice anchor everyone else's answers, which quietly recreates the groupthink the exercise exists to avoid.
Running it with too narrow a group
A premortem limited to one department tends to surface only that department's familiar risks. Cross-functional participation is what catches the risk nobody in the room would have thought of alone.
Listing risks without ranking or acting on them
A long, unranked list with no owners and no follow-up date is a workshop exercise, not a risk-management step — the value comes from what changes in the plan afterward, not from the list itself.
Confusing it with a postmortem
A premortem runs before commitment, to change the plan while there's still time. A postmortem runs after an outcome, to learn from it. Running one in place of the other misses the point of either.
When not to use it
- After the outcome has already happened — that is a postmortem's job, which looks backward at what actually occurred rather than forward at what plausibly could.
- For low-stakes, easily reversible decisions, where the time cost of a structured team exercise outweighs the benefit of catching a rare bad outcome early.
- As a one-time substitute for ongoing risk management — a premortem surfaces risks a team hadn't yet named; it doesn't track or update known risks over the life of a project the way a risk register does.
- In a group that doesn't feel safe being candid with leadership — if people still fear real consequences for naming a flaw, imagining failure as settled fact helps, but it won't fully substitute for addressing the deeper trust problem.
Try It Yourself: build your own prompt
Answer three quick questions and get a ready-to-use prompt for running a premortem on your own plan.
Your prompt:
Save as Skill
A portable summary of Premortem Analysis you can hand to an AI assistant, a teammate, or your future self, so the technique gets run the same careful way every time.
Preview