Use an AI premortem to find the question your project plan needs to answer

Imagine that your project has failed, and ask what you need to investigate now.

You have a plan for a small software product. Ask AI to list its risks, and you may get categories you already know: technical problems, weak demand, a slipping schedule. What would make you change what you do next?

A premortem starts before implementation but asks you to imagine the plan has already failed, then explain how. Failure is a temporary premise for the exercise, not a prediction about your project. It gives the discussion an outcome to work backward from.

What the original method asks a team to do

In Gary Klein's 2021 account, team members first learn the plan, then assume it has failed. Each writes reasons independently; they take turns contributing different reasons, then consider responses. Klein describes this as a way to make reservations easier to voice. The team brings different experience to that discussion.

The change in question matters. “What are the risks?” can stay at the level of labels. “How did this plan fail?” asks for an explanation connecting decisions and events. That explanation is something to examine, not something you have discovered happened.

Why the failure premise matters—and what research leaves open

In 1989, Deborah Mitchell, J. Edward Russo, and Nancy Pennington ran two student experiments about hypothetical personal and work outcomes. They varied past versus future timing separately from whether the outcome was certain or uncertain. Certainty had more influence on explanations than timing alone; certain outcomes elicited more action-based reasons. The authors cautioned that more reasons need not mean better explanations. These experiments did not test AI or software-project success. Here, that distinction suggests using a concrete story to find questions, rather than treating detail as evidence of accuracy.

Find a question that changes what you build first

Consider a fictional independent software owner building a tool for clients to review drafts. The initial plan is to polish the draft overview first, then add invitations and comments.

For the premortem, set one outcome:

The four-week trial has ended. Clients are still sending feedback by email, and the owner is still combining their comments manually.

One possible explanation is:

The invited contact forwards the invitation to the person who actually approves the work. That person can't complete joining the tool. Feedback goes back to email, and the owner brings the responses together outside the product.

This entire chain is an authored hypothesis; none of these events has occurred. Its value is that it exposes an assumption in the plan: the invitation path will work for the person who needs to approve, even when that person wasn't the original recipient.

A better overview wouldn't necessarily answer that question. The chain points to something to investigate before spending more time on it:

Can the actual approver go from a forwarded invitation to reading the draft and submitting feedback?

That is more useful for sequencing work than “clients might not like the tool.” It names a person, a starting point, and an action the product plan depends on.

Before polishing the overview, investigate whether the approver can use a forwarded invitation to review.

The proposed next step is to ask an expected approver to try a version of that path before expanding the overview. Observe how they reach the draft and attempt to leave feedback. What happens could guide whether the invitation path needs attention first. No such trial has been carried out in this example.

The failure story doesn't establish why joining would be difficult, so it doesn't yet justify a particular fix, such as removing sign-in. It has done a smaller job: turned a broad concern into a question worth resolving before more polishing.

Use AI to work on the hypothesis

For a solo version, write your own concern before asking AI to extend it. That's an application choice for this exercise, not a finding from the 1989 study. Then give the tool the short plan and the failure outcome, and ask it to make the reasoning explicit:

Here is my project plan and my own concern. For a premortem, assume the four-week trial has ended with clients still emailing feedback. Describe one plausible sequence of actions that could lead there. Mark assumptions and any step that needs more explanation. Identify the plan assumption this sequence depends on, then suggest one question I could investigate now whose answer would change what I work on first. Keep events hypothetical; don't invent customer answers or claim a fix has been validated.

Read the response for the link that matters to your next decision. In this example, that link is whether a forwarded invitation lets the actual approver complete the review. If the AI skips from “invitation forwarded” straight to “client refuses to use the product,” ask what could happen between those events before accepting the explanation.

A model playing founder, client, and project manager is still one source generating possibilities. It doesn't recreate the independent contributions in Klein's team exercise. Bring the question to people who can answer it; use the imagined failure to decide what you need to learn from them.