The riskiest part of that project was sitting in the room the entire time. Everyone could see it. Nobody would say it.
It was a systems migration I ran years ago, back in my IT operations days. A third-party integration sat on the critical path, owned by a vendor whose track record we all quietly distrusted. The VP sponsoring the project had personally championed that vendor. So in the kickoff, when I asked the standard question (“any concerns before we commit?”), the room gave me the standard answer. Nods. A couple of minor scheduling notes. Silence on the one thing that eventually slipped the launch by six weeks.
That silence is the problem a pre-mortem is built to solve. And most product managers who run one still miss the point of it.
The question that changes what people will say
A pre-mortem inverts the usual project kickoff. Instead of asking a team to imagine success and plan toward it, you tell them the project has already failed, then ask them to explain why.
The specific framing matters. Daniel Kahneman describes the procedure in Thinking, Fast and Slow as a short speech to a group that has nearly committed to a decision but not formally signed off: imagine we are a year into the future, we implemented the plan exactly as it stands now, and the outcome was a disaster. Take five to ten minutes to write the history of that disaster.
That small shift in tense does something a direct question cannot. “What could go wrong?” invites people to defend the plan or stay quiet to look like team players. “Here is how it failed, tell me the story” gives them cover. The failure is now a premise, not a prediction, so naming a cause is no longer an act of disloyalty. Gary Klein, the psychologist who formalized the technique in a 2007 Harvard Business Review article, put the mechanism plainly: a pre-mortem lets people surface every reason they can think of for the failure, especially the kinds of things they ordinarily wouldn’t mention as potential problems, for fear of being impolitic.
On my migration, the vendor risk would have come out in the first ninety seconds of a real pre-mortem. Written on a card, read aloud as one line in a list of failure causes, it is just an observation. Said out loud to the VP’s face as an objection, it was career math nobody wanted to do.
Where the number comes from
The technique is not a motivational trick. It rests on a specific piece of research.
In 1989, Deborah Mitchell of the Wharton School, Jay Russo of Cornell, and Nancy Pennington of the University of Colorado published a study in the Journal of Behavioral Decision Making titled “Back to the future: Temporal perspective in the explanation of events.” They found that “prospective hindsight,” imagining that a future event has already happened and then reasoning backward, increased people’s ability to correctly identify reasons for a future outcome by about 30 percent.
Thirty percent more of the real reasons, surfaced before you build anything. That is the entire case for the practice. Your team already holds most of the knowledge that predicts the project’s failure. The pre-mortem is a retrieval method for knowledge that is present but unspoken.
It is worth remembering how often that knowledge would otherwise stay buried. The Standish Group’s long-running CHAOS research, summarized in a 2024 ACM Queue analysis, continues to show roughly 31 percent of projects landing as clear successes, about half challenged, and close to a fifth failing outright. Large projects fare far worse than small ones. Plenty of those failures were foreseeable and, somewhere in the org, actually foreseen. They just were not said in time.
Why the standard risk review keeps missing the same risks
Product managers already run risk reviews. Risk registers, RAID logs, the “what are we worried about” round at the end of planning. Those tools catch a category of risk: the operational, logistical, visible kind. Dependency due dates, staffing gaps, unclear requirements.
What they miss is the risk that is socially expensive to name. The vendor the sponsor loves. The architecture decision the principal engineer made and would take personally. The launch date sales already promised a customer. These are the risks that kill projects precisely because the normal process is built to route around them politely.
I wrote recently about how a quiet room is not the same as an aligned one, and the pre-mortem is the sharpest tool I know for testing that. If you run one and the failure stories are all bland (“scope crept,” “we underestimated testing”), you have confirmation that the honest concerns are still in people’s heads, not on the table. A good pre-mortem produces at least one story that makes the room slightly uncomfortable. That discomfort is the signal it worked.
Running one that earns its half hour
The mechanics are simple, which is part of why they get botched. A pre-mortem takes about thirty minutes and runs in a specific order.
Start by stating the plan as decided, not as a draft up for debate. People need to imagine failing at this plan, not relitigate whether to do it. Then deliver the framing directly: it is a year from now, we shipped this, it went badly, write down why.
Have everyone write silently and independently for five to ten minutes before anyone speaks. This is the step most teams skip, and skipping it defeats the purpose. The moment one senior voice starts talking, anchoring sets in and quieter people converge on what was already said. Independent writing is what protects the dissenting view long enough to reach the table.
Then go around the room, one failure cause per person per turn, and capture every item without debating it. No “well, that won’t really happen.” You are collecting, not filtering. Only after the full list is out do you group the items and look at which failures are both plausible and severe.
Klein noted a useful side effect: going around the table forces even the most reluctant person to contribute, and hearing colleagues name concerns makes the whole group more willing to be candid. The structure does the social work you cannot do by asking nicely.
The mistake that wastes almost every pre-mortem
Here is where most product managers lose the value they just created. They run a genuinely good session, generate a page of sharp failure causes, feel the relief of having surfaced the hard stuff, paste the list into the project doc, and move on.
A surfaced risk with no owner and no decision is not managed. It is documented. Those are different things, and the gap between them is where the six-week slip lives.
Every failure cause worth keeping needs to convert into one of three outcomes before the meeting ends. Either someone owns a specific action to reduce it, with a date. Or the team explicitly accepts it as a risk you will carry and watch, named as such. Or you decide it changes the plan itself, which is the pre-mortem doing its highest-value work: killing or reshaping a bad decision before the money is spent. A cause that gets none of those three is a cause you chose to ignore, and you should at least ignore it on purpose.
On that migration, a real pre-mortem would not have magically fixed the vendor. But naming the dependency out loud would have forced the choice we avoided: build a fallback, negotiate a hard contractual date, or tell the sponsor plainly that their preferred vendor was the single largest threat to their launch. Any of those beats discovering it in week five. If you want a lightweight structure for taking one of those surfaced risks to a decision-maker, the one-page decision brief pairs well with a pre-mortem’s output.
When it is worth doing, and when it is not
A pre-mortem is not free. It costs a room of expensive people thirty focused minutes, and it works best before a real commitment, not after work is underway. I would not run one for a routine two-week feature. I would run one before any launch that is hard to reverse, any project with a fixed public date, any initiative crossing several teams, and any decision where I can feel the group converging suspiciously fast.
The last case is the one to watch for. When alignment arrives too easily and too early, that is usually not agreement. It is deference, or fatigue, or people reading the sponsor’s body language. A pre-mortem is how you find out which one you are dealing with while there is still time to act on the answer.
The technique is old, the research behind it is older, and it remains underused for a reason that has nothing to do with its difficulty. Asking a team to describe how your plan fails means being willing to hear it. That is the actual bar. The half hour is easy. Wanting the honest answer is the hard part.