Imagining that a project has already failed raises a team's ability to correctly identify the reasons for a future outcome by about 30 percent, according to research by Deborah Mitchell, Jay Russo, and Nancy Pennington published in the Journal of Behavioral Decision Making. That single...
Imagining that a project has already failed raises a team's ability to correctly identify the reasons for a future outcome by about 30 percent, according to research by Deborah Mitchell, Jay Russo, and Nancy Pennington published in the Journal of Behavioral Decision Making. That single finding is the whole case for the premortem: a short, calm ritual you run before a launch, in which the team assumes the plan has died and then explains, out loud, exactly what killed it.
I study behavioral psychology because the most expensive mistakes rarely come from a lack of intelligence. They come from a lack of the right question at the right moment. The premortem is one of the cleanest examples I have found of a question that changes what a group can see.
The technique was named and described by research psychologist Gary Klein in his 2007 Harvard Business Review article, "Performing a Project Premortem." A postmortem, in medicine, gathers people after a death to learn what went wrong. Everyone benefits except the patient. A premortem simply moves that same conversation to before the launch, while the patient can still be saved.
Here is the exact move. You gather the people who will do the work. You tell them to imagine it is some months from now and the project has failed completely, not partially, not "mixed results," but a clear, visible failure. Then each person writes down every reason they can think of for why it died.
The grammar is the mechanism. A normal risk meeting asks "what could go wrong?" A premortem asserts that it has already gone wrong and asks "what happened?" The first question invites a shrug. The second one invites a story, and people are very good at telling stories about events they treat as real.
This is where the 30 percent comes from. Mitchell, Russo, and Pennington called the effect prospective hindsight: you project yourself into a future where the outcome is settled, then look backward to explain it. Their work found that certainty of outcome, not merely the passage of time, produced longer and more concrete causal explanations. People stop hedging and start diagnosing.
Daniel Kahneman found the method useful enough to feature in Thinking, Fast and Slow, framing it as a rare, practical antidote to the overconfidence that sets in once a group has committed to a plan. Once a team has decided, dissent feels disloyal. The premortem legitimizes doubt by assigning it as the task.
There is a social benefit that matters more in small teams than large ones. In a company of two or three, the person raising a concern is often the same person who has to build the thing. Framing failure as a shared assumption lets them flag a weakness without it reading as reluctance. This is the same reason I keep coming back to how much of technology work is really consumer and human behavior wearing an engineering costume.
The failure it targets is optimism bias, and the pattern is well documented at scale. Bent Flyvbjerg's research on large projects, summarized by McKinsey, found that nine out of ten megaprojects run over budget, with overruns of 50 percent common, a pattern so durable he named it the Iron Law of Megaprojects.
Small businesses are not building bridges, but the mechanism is identical. Once you have chosen a plan, your mind quietly recruits evidence that it will work and discounts evidence that it will not. You estimate the best case and call it the plan. The premortem forces the opposite motion for thirty minutes.
Flyvbjerg's proposed remedy for large projects is reference class forecasting: instead of estimating from your own optimistic bottom-up view, you base the forecast on how comparable real projects actually turned out. A premortem is the small-team version of the same instinct. You cannot pull outcome data on a thousand past launches, but you can force yourself to reason from failure rather than from hope, which is most of the correction.
This connects to a broader truth I keep writing about: the biases you cannot see are the ones steering the decision. A premortem is one of the few tools that makes an invisible bias briefly visible, which is why I treat it as a sibling to any honest look at cognitive bias in technology decisions and to the sunk cost fallacy that keeps teams pouring money into a plan that has already told them it is failing.
The ritual is small on purpose. A useful premortem for a two-person or ten-person team takes half an hour and needs a wall, some paper, and a rule that no one defends the plan during the exercise.
State the assumed failure first. Be specific and concrete: "It is October. We shipped the new booking system and customers hated it. Bookings dropped." A vague failure produces vague causes, so pin the scenario to a date and an outcome someone would actually notice.
Then list causes silently. Give everyone a few minutes to write independently before anyone speaks. Silent generation matters because the first person to talk in a group anchors everyone else, and you want the full spread of fears, not an echo of the loudest voice.
Next, rank. Read the causes aloud, cluster the duplicates, and sort them by two axes: how likely each is, and how much damage it does if it happens. Most lists collapse to three or four causes that carry the real weight. The long tail is noise you can note and move past.
Finally, mitigate the top few. For each serious cause, decide one of three things: prevent it now, prepare a response, or accept it with eyes open. Writing "accept" next to a risk is a legitimate answer. Pretending the risk is not there is not.
A premortem that ends in a nice document has failed its own test. The output is not a report, it is a small set of changes to the plan and a small set of tripwires that tell you the failure is starting.
Tripwires are the underrated half. For each top risk, name the earliest signal you could actually observe. If the fear is "customers found the new flow confusing," the tripwire might be a spike in support messages in week one. Klein noted that a premortem sensitizes a team to pick up early signs of trouble once work is underway, and a named tripwire is how that sensitivity becomes something you can check.
Assign each mitigation an owner and a date, then let the plan proceed. The goal is not to talk yourself out of the project. It is to walk in with the three things most likely to sink it already handled or already watched. This is the same discipline behind building systems before you need them rather than after the emergency.
You do not need a premortem for reversible, low-cost choices. Save the ritual for decisions that are expensive to undo: a new customer-facing system, a migration, a pricing change, a partnership. The cost of the meeting is thirty minutes. The cost of the failure it catches can be a quarter.
In our own operations methodology at LTFI, the premortem sits at the front of anything we are about to run in production, next to the less glamorous truth that maintenance, not the launch, is the actual job. Launches are loud. The quiet failures that a premortem surfaces are the ones that show up three weeks later, when everyone has moved on.
There is a reason large AI and software efforts stumble at the end rather than the start. As I have written about the last mile of AI projects, the failure usually hides in the boring gap between "it works in a demo" and "it works for a real customer on a Tuesday." A premortem is one of the few habits that reliably drags that gap into the room before you have spent the budget.
The first mistake is running it too late. If the decision is already emotionally final and the launch is tomorrow, the premortem becomes theater. It works when there is still time and appetite to change the plan.
The second is letting the plan's owner defend it in the room. The moment someone says "well, that would not really happen," the exercise reverts to a normal optimistic meeting and the effect evaporates. Defense comes after, when you decide what to mitigate.
The third is treating every listed cause as equally urgent. A premortem generates a lot of material precisely because it lowers the bar for speaking up. The ranking step is what turns that raw fear into a plan. Skip the ranking and you get anxiety instead of foresight, which, like an unexamined default, quietly shapes the outcome anyway.
A premortem is a short exercise you run before a project launches. You imagine the project has already failed completely, then everyone lists the reasons it died. It is the opposite of a postmortem, which happens after failure, and it lets you fix problems while there is still time.
The core research holds up. Mitchell, Russo, and Pennington found that imagining an outcome as already settled improved people's ability to identify reasons for it by about 30 percent, a mechanism called prospective hindsight. Gary Klein built the premortem on that finding, and Daniel Kahneman later endorsed it as a practical decision tool.
For most small teams, thirty minutes is enough. Spend a few minutes framing the assumed failure, a few minutes on silent writing, then the rest ranking the causes and assigning mitigations. If it stretches past an hour, you are probably debating the plan instead of diagnosing its failure.
Skip it for small, reversible, low-cost decisions where the downside of being wrong is minor. Reserve the premortem for choices that are expensive or hard to undo, such as a migration, a new customer-facing system, a pricing change, or a partnership.
The people who will actually do the work, plus anyone who will feel the consequences. Diversity of role matters more than seniority, because the person who spots the fatal flaw is often the one closest to the messy detail, not the one who approved the plan.
Survivorship bias overstates the typical mutual fund's reported returns by roughly 1.6 percentage points a year, according to the University of Chicago's Center for Research in Security Prices: surviving U.S. stock funds averaged 8.8 percent over the decade ending 2003, while counting...
In a set of experiments published in 2011, people who assembled a plain IKEA storage box valued it 63 percent higher than an identical prebuilt one. The IKEA effect, named by the researchers who ran that study, is the bias that makes you overvalue what you built yourself. It quietly...
Goodhart's Law says when a measure becomes a target it stops being a good measure. Here is why small teams accidentally reward the number instead of the outcome, and how to build metrics that resist gaming.
Work With Us
Kief Studio builds, protects, automates, and supports full-stack systems for businesses up to $50M ARR.
Newsletter
Strategy, psychology, AI adoption, and the patterns that actually compound. No spam, easy to leave.
Subscribe
