Premortem

Assume the plan failed. Find out why before it does.

October 7, 2026 6 min read

The plan passed review. The owner was clear, the milestones were credible, and every known dependency had a line beside it. Six weeks later, the launch slipped because an approval nobody named arrived too late, a customer workflow behaved differently than the specification, and the person who understood the migration was already committed elsewhere.

None of those failures was impossible to imagine. They were simply harder to say while the room was discussing why the plan would work.

A premortem changes the question. Instead of asking whether a plan looks sound, assume it has already failed and ask what caused the failure. The imagined outcome gives people permission to name risks without first winning an argument about whether the project is good.

Start with the failure, not the probability

A risk review that starts from a proposed concern immediately turns into a debate about likelihood.

Will security review really take three weeks? The team handled it quickly last time. Will the integration break? The API is documented. Will customers resist the workflow? The design tested well.

Each response may be reasonable. Together they make the review depend on proving a future event before anyone will prepare for it.

A premortem temporarily removes that burden. Set a specific future scene: it is six weeks after the intended launch, the project missed its goal, and the team now understands why. Ask each participant to write down the causes independently before discussing them.

The exercise is not a prediction that the work will fail. It is a search for explanations that would look obvious in retrospect.

Ask for causes, not categories

"Technical risk" is not useful. Neither is "stakeholder alignment" or "scope creep." These labels name an area without identifying an event the team can observe or change.

A useful failure statement is concrete:

• The billing migration needs finance approval, but no approver has accepted the review date.
• The launch depends on an undocumented field in a partner API.
• The support workflow was tested with administrators, while daily users have different permissions.
• The only engineer who has reversed this migration is unavailable during launch week.

Each statement names a mechanism. That makes it possible to decide whether to prevent it, detect it early, reduce its effect, or accept it explicitly.

This is also where Blast Radius matters. Two failures with the same probability deserve different treatment when one delays an internal experiment and the other corrupts a customer workflow. A premortem should rank causes by the damage they can create, not by how dramatic they sound in the room.

Look for evidence already present

The best premortem findings are often facts the organization already holds in separate places.

The approval delay may be visible in three older Linear issues. The partner API limitation may have appeared in a Slack thread. The customer-permission mismatch may be sitting in a support ticket that nobody connected to the specification. The unavailable expert may be obvious on a planning calendar.

An agent can help assemble these signals, but only if it can connect the current plan to prior outcomes, decisions, and current ownership. Otherwise it produces a generic risk list that could apply to any project.

The Outside View supplies a useful starting point. Comparable outcomes show where work like this has failed before. The premortem then asks how those failure mechanisms could appear in this particular plan. One grounds the forecast in history; the other turns possible failure into something the team can inspect now.

Convert each warning into a signal

A risk register becomes stale when it records concerns without saying what would change the team's behavior.

For every important premortem finding, name four things:

1. Cause: the specific event or missing condition that creates the failure.
2. Signal: the earliest observable evidence that the cause is appearing.
3. Owner: the person responsible for watching or removing it.
4. Response: what the team will do if the signal appears.

Suppose the concern is a late legal review. The signal might be that no reviewer has accepted the request by October 12. The owner is the launch lead. The response is to remove the disputed claim from the first release rather than wait until launch week to discover that the whole page is blocked.

The date, owner, and response matter more than a red-yellow-green label. They turn an imagined failure into a decision rule.

Preserve disagreement

A premortem is weak when the facilitator collects ten ideas and compresses them into three polite themes. The sharpest warning is often the one that does not fit the consensus.

Keep each cause in the language of the person who raised it. Record which evidence supports it and which assumption would make it false. If the team decides not to act, record that choice too.

This prevents Decision Debt from forming before the project even begins. When a signal later appears, the team can see whether the risk was unknown, judged acceptable, or simply ignored. That distinction is useful for the current response and for the next plan.

Stop when the plan can react

The goal is not to imagine every possible disaster. An endless premortem becomes another form of avoidance.

Stop when the highest-impact failure paths have an owner, an observable signal, and a response. Some causes will be prevented before work starts. Some will be monitored. Some will remain accepted bets because reducing them costs more than the exposure justifies.

That is a real Stop Condition: the review is complete when the plan can react to the failures worth preparing for, not when nobody can think of another bad thing.

Before approving the next confident plan, move the calendar forward and state the outcome plainly: this failed. What happened?

Frequently asked questions

Is a premortem just pessimism? No. Pessimism predicts a bad outcome. A premortem temporarily assumes one so the team can identify preventable causes and make the plan more resilient.

When should a team run one? Run it after a plan is concrete enough to challenge but before commitments become expensive to change. It is especially useful before launches, migrations, irreversible decisions, and work that crosses several teams.

Who should participate? Include the people executing the plan and people who will inherit its effects. Independent answers before group discussion help prevent the most senior voice from defining the risk list.

Can an AI agent run the premortem? It can gather prior failures, identify missing owners, and propose concrete signals. It should not replace the people who understand local constraints or decide which risks the organization is willing to accept.