Why it matters

You have a plan you believe in — a launch date, a reorg, a new pricing page — and you are about to commit. This is exactly the moment when doubts go quiet. Once a team has converged on a course of action, raising an objection feels like disloyalty or like being the one negative voice in a confident room, so the people who can see the weak point say nothing. A pre-mortem flips the room’s incentives: it asks everyone to assume the plan has already failed, a year from now, and to explain what killed it. Stating a doubt is no longer pessimism — it is just answering the question on the table.

For example: a team is a week from launching a redesigned pricing page — three tiers, an annual discount, a new hero. Asked “what are the risks?”, they list the usual vague worries and move on. Asked instead “it’s a month from now and the launch was a disaster — write the story of what happened”, the same team gets specific fast: the checkout system still pointed at the old price IDs, so annual plans charged the wrong amount and nobody caught it for two days; existing subscribers saw features they used to have moved behind a higher tier and revolted; there was no rollback threshold, so by the time anyone agreed the drop was real, two days of revenue were gone. Each of those is a concrete cause they can now defuse before Tuesday — wire an end-to-end payment test, pre-stage a one-click rollback, brief support with the exact new pricing table. Same plan, a week earlier, but now the failure modes are on the whiteboard instead of in the postmortem.

  • What it reveals. The specific, plan-level reasons this plan could fail — the actual decision points and assumptions that would break — surfaced while you can still act on them, rather than the generic risk list that everyone nods at and no one fixes.
  • How it changes the read. You stop asking “what might go wrong?” — a question optimism quietly deflects — and start asking “it failed; what killed it?” — a question that demands a concrete cause and gives doubters cover to speak.
  • When to foreground it. A specific plan, decision, or launch that is structured enough to fail in particular ways but not yet locked in — the narrow window where naming a failure mode still buys you time to defuse it.
  • What you’d miss without it. The failure that everyone half-saw and no one said. Confident teams systematically under-weight the ways their own plan breaks; the pre-mortem is the device that drags those suppressed doubts into the open and converts them into mitigations.
  • Where it misleads. It is a tool for plans you can change, not a license for fatalism — run it after the decision is irreversible and it just demoralizes. And it works on action plans; for the structural fragility of a system or design, or for tracing a failure that has already happened, a different tool fits.

Realtime examples

See real, dated analyses where this mode pre-mortemed a plan in the news and surfaced what could kill it → Pre-Mortem (Action Plan) on Main Street Independent

How to invoke it in Ora

You have a plan, decision, or launch on the table, and before you commit you want a sober walk through what could kill it — not a vague risk list, but the specific failures this plan could produce.

Describe the plan in concrete terms and ask:

“Pre-mortem this plan: we’re launching [the plan] next [date]. Imagine it’s six months from now and it failed — what killed it?”

The phrases pre-mortem this plan, imagine it failed, and prospective hindsight are what route you here. Give the mode a plan, not a goal: milestones, decision points, and what success would look like all make the failure narratives sharper. “We’re launching a new pricing page” works, but “three tiers, annual discount, redesigned hero, live next Tuesday, success is checkout-start rate holding flat” is far better, because every detail is something the analysis can imagine breaking.

One boundary worth knowing. This mode is for an action plan that could fail in execution. If your real worry is the structural fragility of a system or design — where the tail risk and the hidden coupling live, not a plan’s rollout — that is the pre-mortem-fragility mode, and it is the right tool. The disambiguating question is simple: is this about an action plan that could fail, or about a system or design with structural fragilities?

How it works

The method comes from the psychologist Gary Klein, who noticed something backwards about how teams assess their own plans. Asked up front “what could go wrong here?”, a committed team tends to under-deliver: the question invites a few hedged worries, optimism files them under “manageable”, and the meeting moves on. The plan ships, and the genuinely fatal flaw — the one a couple of people privately suspected — only gets named at the postmortem, when it is too late to matter. Klein’s fix was a small but powerful change of grammar. Instead of “what might go wrong”, you say: it is a year from now, and this plan has failed completely. Write the story of what happened. The failure is now a given. The only task is to explain it.

That single move does two things at once. First, it gives doubt a socially safe channel. In a confident room, raising an objection costs you something — you become the naysayer betting against the team. But when the premise is that the plan already failed, naming a cause is no longer disloyalty; it is just completing the assignment. The quiet engineer who suspected the billing integration finally says it out loud. Second — and this is the part Klein leaned on — it engages a different mental gear. There is a body of decision research, going back to a 1989 study by Mitchell, Russo, and Pennington called “Back to the future”, showing that asking people to explain an outcome that has already occurred (“prospective hindsight”) makes them generate noticeably more, and more specific, reasons for it than asking whether it could occur. A future possibility is easy to wave away; a past event demands a concrete cause. By pretending the failure is already real, the pre-mortem borrows the explanatory power of hindsight and aims it forward, before the commitment is locked.

Picture the pricing-page team again. Run the optimistic version — “any risks before Tuesday?” — and you get “we should keep an eye on conversion” and a shared sense that it’s basically fine. Run the pre-mortem — “it’s a month out and the launch cratered; what happened?” — and the room produces a story: the checkout pointed at the old price IDs and silently overcharged annual buyers; existing subscribers found paywalls on features they used to have and churned; ad campaigns still showed the old layout, so paid traffic hit a jarring mismatch at the moment of highest intent; and with no rollback threshold defined, two days passed before anyone agreed the drop was even real. The pre-mortem’s payoff is the next step: every imagined cause becomes a pre-commitment fix. Old price IDs → run a live end-to-end payment test. Subscriber backlash → grandfather the existing features. No rollback → pre-stage a one-click revert with a defined trigger. The plan that goes live on Tuesday is the same plan, now hardened at exactly the points where the team’s imagination said it would snap.

What makes the discipline work is staying honestly in the past tense. The failures have to be this plan’s failures — “the checkout charged the wrong amount because the price IDs were stale”, not the generic “execution risk” that fits any project and helps with none. The cure for over-optimism is to keep imagining the catastrophe in concrete, past-tense detail until the specific mechanisms surface — and then to refuse to let them slide back into reassuring abstractions before they have been turned into something you can actually do before you commit.

Framework & implementation

This section uses Ora’s own terms for the parts of an analysis, so that if you open the actual mode file they line up. Each is glossed in plain language on first use.

Pipeline execution

Pre-Mortem (Action Plan) is an atomic mode in the future-exploration territory — a single forward pass, not a composite of sub-analyses. It runs at Gear 4, Ora’s most thorough setting: a Depth analyst and a Breadth analyst work the plan in parallel and then critique each other (cross-adversarial evaluation) before a consolidator integrates the result. The breadth pass guards against the inventory clustering in one kind of failure; the depth pass drives each failure down to its specific mechanism.

The pass holds one discipline above all: stance integrity. The narrative stays in the past tense — “the plan failed because the assumption proved false”, not “this might fail if the assumption is wrong” — because forward-conditional grammar is the optimism the method exists to defeat, and the mode reshapes any slippage back into prospective hindsight. Two guards keep it honest. Failures are checked against Klein’s failure-class taxonomy — each is tagged execution, assumption, context-shift, interaction, or motivational, and an inventory that is all one class when others were plausible gets widened. And an optimism-residue flag fires when the failure list reads shorter than the plan’s complexity warrants — a sign the analyst’s prior on success is bleeding through and the pre-mortem stance has not actually held.

The mode’s reasoning tools ride in its ANALYTICAL PERSPECTIVES block — the lenses it loads as it works. The klein-pre-mortem lens is required: it supplies the prospective-hindsight frame and the failure-class taxonomy. Two ride along when the plan calls for them — the kahneman-planning-fallacy lens (the corrective for optimistic timelines, drawn from the research on why plans systematically run long) when schedule is central, and the tetlock-superforecasting lens when the failure pathways need probabilistic estimation rather than narrative.

Output contract

The deliverable is a fixed set of sections, so the analysis is auditable rather than a loose narrative. Imagined Failure Narrative (the past-tense story of how the plan failed, written as if from the future). Failure Mode Inventory (each failure named with its Klein class and its plan-specific mechanism, not a generic trope). Causal Pathways to Failure (for each, the breakage point → immediate consequence → cascade → surfaced failure). Leading Indicators per Failure Mode (the observable, pre-failure signals the team could catch — with signal-acquisition cost and lead time — never the lagging signs visible only at postmortem). Pre-Commitment Mitigations (actions that can be locked in before commitment, each tied to the failure modes it addresses and its cost to implement; an action only available once failure has begun is removed as post-hoc conflation). Residual Unmitigated Risks (the risks the mitigations cannot reach, and whether they warrant rethinking the plan) — these are the load-bearing finding, the part that should weigh most on the commit decision. When the artifact turns out to be system-shaped rather than plan-shaped, the deliverable opens with a route note pointing at pre-mortem-fragility rather than forcing a misaligned pre-mortem.

Origin and evidence

The mode descends directly from Gary Klein’s pre-mortem technique, set out for a general audience in his 2007 Harvard Business Review article “Performing a Project Premortem” and grounded in the naturalistic-decision-making research of his Sources of Power: How People Make Decisions (1999). Daniel Kahneman gave the method its prominent endorsement, describing the pre-mortem in Thinking, Fast and Slow (2011) as a rare, practical antidote to the overconfidence and groupthink that afflict committed teams. The cognitive engine underneath it — that explaining an outcome assumed to have already happened produces more and better reasons than assessing whether it might happen — was demonstrated by Deborah Mitchell, J. Edward Russo, and Nancy Pennington in “Back to the future: Temporal perspective in the explanation of events” (1989), the study that gives “prospective hindsight” its evidentiary footing. The mode pairs that engine with Klein’s failure-class taxonomy to keep the imagined failures both plentiful and balanced.

Applications and common uses

  • Product and feature launches. The native use: a dated launch with concrete components, pre-mortemed for the specific ways it could crater — billing, rendering, messaging, rollout — before ship day.
  • Major organizational decisions. Reorgs, mergers, consolidations, and pricing or compensation changes, where the failure is rarely the headline move and usually a second-order reaction nobody modeled.
  • Project and program kickoffs. A plan with milestones and dependencies, walked through its own failure to surface the assumptions and couplings that would break it, while the schedule can still absorb the fixes.
  • Policy and rollout planning. Public-sector or large-scale operational rollouts (a district-wide mandate, a multi-campus system change), where prospective hindsight catches the on-the-ground failures a top-down plan tends to miss.
  • High-stakes irreversible commitments. Any decision where the cost of being wrong is large and the window to harden the plan is closing — exactly where the pre-mortem’s leverage is highest.

Failure modes and when not to use it

  • Stance slippage into the conditional. The whole method rests on the past tense; let the narrative drift into “this could go wrong if…” and you are back to the optimistic risk list the pre-mortem was meant to replace. The mode reshapes conditional grammar back into prospective hindsight.
  • Generic-failure-trope residue. “Scope creep”, “communication breakdown”, “stakeholder misalignment” with no plan-specific mechanism fit every project and fix none. The mode demands the actual decision point or coupling in this plan.
  • Optimism residue. A failure list shorter than the plan’s complexity warrants is a tell that the analyst’s confidence is leaking through. The mode flags a thin inventory and widens it rather than declaring the plan robust by default.
  • Post-hoc conflation in the mitigations. An action that is only available after failure has started is not a pre-commitment mitigation; mistaking damage control for prevention is a category error the mode strips out.

When not to reach for it. When the worry is the structural fragility of a system or design — tail risk, hidden coupling, what breaks under stress rather than what a rollout gets wrong — route to pre-mortem-fragility, the sibling mode built on the same Klein lens for system-shaped artifacts. When you want a neutral forward cascade — the likely first-, second-, and third-order consequences of a move, not an adversarial failure walk — route to consequences-and-sequel. When the failure has already happened and the task is to trace it backward to its cause, that is root-cause-analysis, not a forward pre-mortem. And when the plan is irreversibly committed, the pre-mortem has missed its window — it hardens plans you can still change, and only demoralizes the ones you cannot.

  • Pre-Mortem (Fragility) — the sibling parsed from the same Klein lens, applied not to an action plan but to a system or design: when the question is structural fragility and tail risk rather than a rollout that could fail, this is where it hands off.
  • Scenario Planning — the depth-thorough neighbor for when the future is uncertain across several directions at once and you want a set of coherent narratives rather than a single failure walk.
  • Consequences & Sequels — the neutral-forward complement: the likely cascade of effects from a decision, traced without the adversarial “assume it failed” framing.
  • Planning Fallacy — the lens this mode loads when timelines are central: the well-documented tendency for plans to run long and over-promise, and the corrective the pre-mortem applies against it.