How to Prompt AI for a Pre-Mortem on Your Project Plan

A pre-mortem asks AI to imagine your project has already failed, months from now, and then work backward to explain why, a framing that surfaces risks a forward-looking "what could go wrong" question tends to miss. The technique predates AI by decades (it comes from decision research on how to counter overconfidence in plans), and it works unusually well as a prompt because forcing the model to commit to a specific failure story, rather than list generic risks, produces sharper, more specific answers.

Why "imagine it already failed" beats "what could go wrong"

Asked directly what could go wrong with a plan, both people and models tend to produce a generic, hedged list, security issues, scope creep, the usual suspects, restated for whatever the plan happens to be. Asked instead to imagine a specific failure has already happened and explain how it happened, the prompt forces commitment to one coherent causal story instead of a menu of possibilities, and coherent stories surface specific, plan-relevant risks that a generic checklist does not.

The prompt

It is six months from now. [Describe the project/plan in 2-4
sentences] has failed. It did not launch, or it launched and was
a clear failure. Write a short, specific account of what happened,
as if explaining it to a colleague after the fact: what the
first sign of trouble was, what decision or assumption turned out
to be wrong, and why nobody caught it in time. Be concrete, not
generic, name the specific mechanism of failure rather than a
category like "poor planning."

Then, separately, list the 3 warning signs from that story that
would have been visible earlier if someone had been watching for
them, and one concrete check I could put in place now for each.

The second half is what turns the exercise into something actionable rather than just an interesting story. Without it, a pre-mortem is a creative-writing prompt, with it, it is a checklist you can actually use before you ship.

A worked example

For a small business launching a paid feature behind a subscription paywall, a pre-mortem might surface a failure story centered on existing free users churning en masse at the paywall date because the migration email undersold what they would keep access to, rather than the more commonly assumed risk of the feature itself being unwanted. That specific mechanism, a communication failure at the transition point rather than a product failure, would not typically appear on a generic "risks of adding a paywall" list, and it points to a concrete fix: test the migration email's clarity before launch, not just the feature.

What to do with a genuinely unconvincing pre-mortem

• If the failure story it generates feels generic or interchangeable with any other project's, that itself is useful information: it usually means the plan description you gave was too vague for the model to reason about specifically. Add real constraints, numbers, and stakes to your input and try again.

• If it surfaces a risk you already knew about and had a plan for, that is a legitimate outcome, not a failure of the exercise, it confirms the risk is real enough that an outside pass finds it independently.

• Run it more than once with slightly different framing (six months out versus one year out, a quiet failure versus a public one) if the plan is high-stakes enough to warrant it, different framings surface different failure mechanisms.

How this differs from a postmortem

A pre-mortem runs before you ship, on a plan that has not happened yet, and its output is a set of warning signs to watch for. A postmortem runs after something has already happened, on real events, and its output is a factual account plus concrete fixes. They share a structure, imagined or real cause-and-effect leading to a bad outcome, but a pre-mortem is a planning tool and a postmortem is an incident-response tool, do not use one where the other belongs.

If the plan involves code specifically, pair this with a targeted pass using how to prompt AI to review your code before you ship it, a pre-mortem catches planning and process risks, a code review catches implementation risks, and a serious launch benefits from both. For a more exhaustive pre-launch pass once the pre-mortem's warning signs are addressed, see how to prompt AI to write a test plan.

For a narrower version of this exercise that looks for one specific bet rather than many failure scenarios, see how to prompt AI to find a business plan's blind spot.

Frequently asked questions

Does this only work for technical projects?

No, the technique works on any plan with a real outcome at stake: a product launch, a pricing change, a hire, a marketing campaign. The prompt template above is intentionally generic for this reason, describe whatever plan you have.

How far in the future should the failure be set?

Far enough that the failure has had time to fully play out and be recognized as a failure, not just an early stumble. Six months to a year works well for most product and business plans; a shorter window suits something with a near-term, clearly defined outcome, like a single launch event.

Should I do this alone or share the output with my team?

Share it. A pre-mortem's real value often comes from the discussion it starts, someone on the team may recognize a warning sign as already happening, or disagree with the failure story in a way that surfaces an assumption worth resolving before launch rather than after.

Is this the same as a risk register?

Related but not the same. A risk register is typically a flat list of possible risks rated by likelihood and impact. A pre-mortem produces one coherent failure narrative, which tends to surface the specific mechanism and sequence of events a risk register's flat list can miss, the two work well as complements rather than substitutes.