Most plans fail for reasons that were visible in advance, yet nobody wanted to say them out loud. A “pre-mortem” flips the usual question. Instead of asking “will this work?”, you assume the project has already failed and ask “what went wrong?” The technique was popularized in a 2007 Harvard Business Review article by the psychologist Gary Klein, who described it as a way to overcome the overconfidence that sets in once a team has committed to a plan. An AI model is a convenient partner for it: it has no stake in your plan, no social cost for being blunt and can generate a long list of failure modes in seconds.

The prompt

Copy this template, fill in the brackets and paste it into any capable chat model:

You are a seasoned project risk reviewer. I will describe a plan.
Assume it is twelve months from now and the plan has failed badly.

Plan:
[Describe the goal, the timeline, the people and budget involved,
and the key assumptions you are relying on.]

Do the following:
1. Write five plausible, specific stories of how it failed.
   Each should name a root cause, not a symptom.
2. For each story, list one early warning sign I could watch for in
   the first 30 days.
3. Rank the five by likelihood x impact and explain the ranking in one sentence each.
4. For the top two, suggest one concrete change to the plan that would prevent it.
5. List the three assumptions in my plan that, if wrong, would hurt most,
   and say how I could test each cheaply.

Be direct. Do not soften criticism. If my description is too vague
to judge, ask me up to three clarifying questions first.

Why the prompt is built this way

“Assume it has failed.” Klein’s research idea is that imagining a failure as already happened makes it easier to identify reasons than asking whether one might happen. The same reframing helps a language model: it moves the model from reassurance toward concrete causes.

“Root cause, not symptom.” Without this instruction, models tend to list generic risks such as “lack of communication.” Asking for causes pushes toward specifics, like “the only engineer who understood the billing system left in month four.”

Early warning signs. A risk list is only useful if you can act on it. Signals you can observe in the first 30 days turn worry into monitoring.

Ranking and fixes. Without a ranking, the list is a pile; asking for likelihood times impact forces a priority order, and the “one concrete change” step ends with an action.

Permission to ask questions. Vague input produces vague output. Inviting clarifying questions lets the model flag what it does not know instead of inventing details.

A worked example

Suppose you plan to launch a paid newsletter in 90 days with a budget of $2,000 and two part-time writers. You fill in the plan with your target audience, pricing and promotion channels. A strong response will typically include failure stories like these (illustrative; the model’s actual output will depend on your details):

  • Audience never converts from free to paid. Warning sign: fewer than 2% of free subscribers click the paid offer in the first month. Fix: test a paid tier with 50 existing readers before building the full launch.
  • Writers burn out by week eight. Warning sign: missed drafts or rising edit time. Fix: build a four-week buffer of finished posts before launch.
  • Promotion relies on one social platform whose reach drops. Warning sign: referral share from that platform exceeds 70%. Fix: add one owned channel such as a referral program.

The value is not in treating these as predictions. It is in using them as a checklist that makes your assumptions visible.

Tips for better results

  • Give real numbers and constraints. Budget, dates, team size and dependencies make the failure stories specific.
  • Run it twice. Models produce different lists on different runs, a point we explain in our article on temperature and sampling. Merge the unique items.
  • Challenge the answer. Follow up with “Which of these is least likely, and why?” or “What did you miss?”
  • Check facts independently. If the model cites statistics or industry norms, verify them before relying on them.
  • Use it with people. Share the AI’s list with your team and ask them to add their own failure stories. The model is a starting point, not a replacement for people who know the context.

Variations

  • Personal decisions: replace “plan” with “decision,” such as moving cities or changing jobs.
  • Product launches: ask for failure stories from the customer’s perspective.
  • Safer by design: add “assume a regulator reviewed this” to surface compliance gaps.
  • Success version: run a follow-up “pre-parade” asking what must be true for the plan to succeed, then compare the two.

For a companion technique that improves existing text instead of plans, see our earlier critique-and-improve prompt, and for a broader library of reusable patterns, our prompting patterns cheat sheet.

What to watch next

  • Built-in “red team my plan” features in chat assistants and project tools.
  • Research on whether AI-generated risk lists improve real project outcomes.
  • Team workflows that combine AI pre-mortems with human review sessions.

Key takeaways

  • A pre-mortem assumes failure has happened and asks why.
  • Asking for root causes, warning signs, ranking and fixes makes the output actionable.
  • Specific inputs produce specific failure stories.
  • Run it more than once and verify any factual claims.
  • Treat the AI’s list as a prompt for discussion, not a forecast.

Frequently asked questions

Does a pre-mortem predict what will actually go wrong?

No. It surfaces plausible risks and hidden assumptions so you can prepare; it is not a forecast.

Which AI model should I use?

Any capable chat model works. Try a couple and compare, since they vary in how blunt and specific they are.

Can I paste confidential plans into a chat model?

Check your organization’s policy and the provider’s data terms first, or use a local model for sensitive material.