The Pre-Mortem Practice: Spot Failure Before You Start

There is a website that tracks dead AI products like a graveyard. Last time I checked, it had counted around 90 of them: deprecated models, killed apps, shuttered services, failed startups. A second tracker puts the number of buried AI companies at 142. OpenAI’s own Sora consumer app made that list after 84 days. It launched, peaked near a million users, burned roughly a million dollars a day, lost a billion-dollar Disney deal, and was switched off. Builder.ai, valued at 1.5 billion dollars, went into liquidation after investigators found its revenue had been inflated by about 300 percent and its “AI” was largely hundreds of engineers in Gurgaon and Bangalore.

Every one of those deaths now has a postmortem. A blog post, a thread, a teardown, a “lessons learned” deck. Founders read them like horoscopes. The problem is timing. A postmortem is written after the body is cold. It tells you exactly why a company died on the day it can no longer help that company at all.

The durable version of that habit runs in the opposite direction. Instead of reading other people’s postmortems after their funeral, you write your own before your launch. You sit down on day zero, assume the project is already dead, and ask why. That exercise has a name. It is called a pre-mortem, and almost no founder actually runs one.

I have shipped two companies where AI does most of the work, and I have killed more ideas than I have launched. The single cheapest discipline I have found is this: spend one afternoon imagining the failure before you spend one month building toward it. This is the practice, the research behind it, and the loop I run so it does not stay a one-time meeting.

Table of Contents

• Why founders are blind to their own failure
• The Pre-Mortem Loop: the core framework
• Move one: Imagine it is already dead
• Move two: Enumerate the kill reasons
• Move three: Instrument the top reasons
• Move four: Revisit on a cadence
• The five surfaces where startups actually die
• A worked pre-mortem on the deaths everyone studied
• The contrarian take: a pre-mortem is not pessimism
• What to do Monday morning
• FAQ

Why founders are blind to their own failure

Ninety percent of startups fail. Walk into a room of founders and ask who expects to be in the failing nine out of ten. No hands go up. Every person in the room believes they are the exception. That gap, between the base rate and the felt confidence, is not a character flaw. It is wiring.

Daniel Kahneman spent a career documenting it. The human brain is built to be optimistic about its own plans. We underestimate time, cost, and risk, even when our own past gives us every reason not to. Psychologists call it the planning fallacy, and it does not improve with experience. The tenth project ships late for the same reason the first one did. You can know the statistic and still feel exempt from it.

For a founder this is expensive in a specific way. Optimism is the fuel. You cannot start a hard thing without believing it will work, so you train yourself to suppress the part of your mind that sees the downside. The same instinct that gets you to start is the instinct that blinds you to how you will fail. You are not allowed to be the pessimist, because the pessimist never launches.

So founders outsource pessimism to the postmortem. We let other companies die, then study the autopsy. The trouble is that an autopsy teaches you about a body that is already gone. By the time you are writing your own, the decisions that mattered were made twelve months ago, when you were too optimistic to question them.

The data backs up how common this is, and it is getting worse, not better. S&P Global found that 42 percent of companies scrapped at least one AI initiative in 2025, up from just 17 percent the year before. RAND’s 2025 analysis found that around 80 percent of AI projects fail to deliver their intended value, with roughly a third abandoned before they ever reach production. Forrester and Anaconda put the number at 88 percent of agent pilots that never graduate to production. These are not exotic failures. They are ordinary, repeated, and largely predictable. Which is exactly the point. If failure is predictable, it is also pre-mortem-able.

Notice what those numbers describe. They are not stories of teams blindsided by something nobody could have seen. A pilot that dies in the gap between a working demo and a working product died of a reason that was knowable on day one, because the gap was always there. An initiative that gets scrapped after a quarter was usually missing real demand the whole time, and the early excitement masked it. The reason the abandonment rate is rising is not that the failures got harder to predict. It is that more people are starting projects in a rush, on optimism alone, without ever pausing to write down how the thing in front of them most plausibly dies. The pre-mortem is the pause. It is cheap, it is fast, and the rising graveyard count is the cost of skipping it at scale.

The Pre-Mortem Loop: the core framework

Most people who have heard of the pre-mortem treat it as a single meeting. You gather the team before a launch, someone says “imagine this failed, why?”, everyone lists a few risks, and then the document goes in a drawer. That is better than nothing. It is also where most of the value leaks out.

A risk you name once and never track is just a worry you had on a Tuesday. The practice only pays when the imagining turns into instruments, and the instruments get checked. So I run it as a loop, not an event. Four moves, repeated on a cadence for the life of the project.

The loop matters more than any single move. A risk you imagined in January is not the risk that kills you in June, because by June the world moved and so did your plan. Running the loop quarterly keeps the failure picture current. Below, each move in detail.

Move one: Imagine it is already dead

The pre-mortem was named by Gary Klein, a cognitive psychologist, in a short Harvard Business Review piece. The instruction is deceptively simple. Before the project starts, gather the people who will build it and say: assume it is twelve months from now and this project has failed completely. It is a disaster. Now, working backwards, write the story of why.

The wording is the trick. You are not asking “what could go wrong”, which invites a polite, hedged list. You are asserting that it did go wrong, as a fact, and asking for the explanation. That small shift has a name and a number behind it.

In 1989, researchers Deborah Mitchell, Jay Russo, and Nancy Pennington ran a study on what they called prospective hindsight, the act of imagining that a future event has already happened. They found that this framing increased people’s ability to correctly identify reasons for a future outcome by 30 percent. Klein’s own field experience is that prospective hindsight roughly doubles the number of risks a team surfaces compared with a standard “what are the risks” prompt. Kahneman, who helped popularize the method, liked it precisely because it gives the suppressed pessimist a socially acceptable way to speak.

That last part is the underrated mechanic. In a normal planning meeting, the person who raises the ugly risk looks disloyal. They are the wet blanket slowing the team down. In a pre-mortem, the failure is a given, so naming a reason for it is not disloyalty, it is the assignment. You have changed the social cost of telling the truth. People who would never say “I think the founder is going to lose interest in six months” will write exactly that when the prompt makes pessimism the job.

For a solo founder there is no team to gather, which sounds like a problem and is actually a gift. You get to run the pre-mortem against yourself, on paper, with no audience to perform confidence for. The discipline I use is to write it in past tense, as a real account. “The product launched in March. By September it was dead. Here is what happened.” Past tense forces specificity. It is much harder to wave away “we ran out of money in week 30 because the one channel that worked stopped working” than the vague “funding risk”.

Move two: Enumerate the kill reasons

Once you have given yourself permission to see the failure, the goal is volume and honesty. List every reason the project died. Klein’s protocol asks each participant for around ten reasons, specifically including the ones they would never say out loud for fear of being rude. The rude ones are usually the real ones.

Quantity here is a feature. Research comparing the pre-mortem with the more familiar worst-case-scenario method found that people generate more reasons under the pre-mortem framing, and that groups generate more than individuals. The same body of work found that pre-mortems reduce a team’s overconfidence more than other critique methods do, including the classic devil’s advocate. You are not trying to find the one true cause. You are trying to widen the set of failures you can see, because the failure that kills you is almost always one you did not have on the list.

The honest reasons fall into predictable categories, and naming the categories helps you avoid blind spots. When I enumerate, I deliberately walk five surfaces and force at least two reasons from each, so I do not just list the comfortable technical risks and skip the uncomfortable human ones.

Surface	The uncomfortable kill reason it hides	Why founders skip it
Market	People liked the demo but never needed it enough to pay or switch.	Positive feedback feels like demand. It usually is not.
Cash	The runway math assumed a best case that did not arrive.	The optimistic forecast is the one that justified starting.
Team	A co-founder split, a key hire never came, or trust broke.	It feels disloyal to put it on the list.
Execution	A platform you depend on changed and made you redundant.	You assumed the ground under you would stay still.
Founder	You lost interest, burned out, or got pulled to a shinier idea.	Admitting you might quit feels like predicting your own weakness.

That founder row is the one most pre-mortems leave out, and it is the one I have personally tripped on more than once. The most likely reason a solo project dies is not a competitor or a market. It is that the person running it quietly stopped caring around month four and let it drift. If you cannot write that on your own list, you are not doing the exercise honestly.

Move three: Instrument the top reasons

Here is where the pre-mortem stops being a thought experiment and starts being an operating tool. A list of fears does nothing. The job is to take your top three or four kill reasons and convert each into two things: a leading indicator you can actually watch, and a kill criterion that tells you in advance when to stop.

The kill criterion idea comes from Annie Duke, the former professional poker player who wrote about quitting as a skill. Her best framing is that a good quitting condition combines a state and a date. A state is an objective, measurable condition, a benchmark you have hit or missed. A date is when you check. The format is: “if I am not in state X by date Y, I stop.” You write it before you start, while you are calm and rational, so that the in-the-moment, emotionally attached version of you cannot talk their way out of it.

This is the difference between worrying about a risk and managing it. “I am worried users will not pay” is a feeling. “If fewer than 10 of the first 100 trial users convert by week 8, I shut the paid plan and rethink the product” is an instrument. The first keeps you up at night. The second tells you what to do.

Kill reason (from the pre-mortem)	Leading indicator to watch	Kill criterion (state + date)
No real demand, just polite interest	Trial-to-paid conversion in first cohort	Under 10 percent paid by week 8: stop selling, re-interview.
One fragile channel carries everything	Share of signups from the top channel	Over 80 percent from one source by month 3: build a second before scaling.
Platform dependency makes us redundant	Percent of value the platform could ship natively	If the core feature ships in their roadmap, pivot the wedge that quarter.
Founder loses interest, project drifts	Weekly shipping cadence, honestly logged	Three weeks of near-zero shipping: schedule a real quit-or-commit review.

Notice what the kill criterion does to fear. A vague dread sits in the background and taxes every decision. A written state-and-date moves the dread onto a calendar, where it becomes a scheduled check instead of a constant hum. You stop carrying the risk and start auditing it.

There is a craft to picking the indicator, and most people get it wrong by choosing a lagging one. Revenue is a lagging indicator. By the time revenue confirms that nobody wants the product, you have already spent the runway finding out. The skill is to find the earliest observable signal that sits upstream of the failure. For weak demand, the leading signal is not revenue, it is how hard people work to keep using the product after the novelty wears off, which you can see in week-two retention long before it shows up in a bank account. For founder drift, the leading signal is not a missed launch, it is the honest weekly shipping log going quiet, which you can see weeks before the project visibly stalls. Pick the signal that moves first, because the entire value of a kill criterion is that it fires while you still have options. A criterion tied to a lagging metric is just a postmortem with extra steps.

Move four: Revisit on a cadence

A pre-mortem run once is a snapshot. A pre-mortem run on a cadence is a practice. The world your kill criteria were written against keeps moving, and the failure that was most likely on day zero is rarely the one most likely on day ninety.

I put a recurring quit-or-commit review on the calendar, separate from normal operations, on a fixed cadence. Monthly for an early project, quarterly once it is stable. Annie Duke’s point is that these reviews have to be scheduled and protected, because the natural state of a founder is to keep going by default, and a default of “keep going” means you only ever stop after the money is gone. A standing review converts quitting from a moment of weakness into a routine decision.

The review has three questions. First, did any kill criterion trip since last time, and did I honor it, or did I quietly move the goalposts? Second, has the world changed enough that I should run a fresh pre-mortem from scratch, because the failure picture is now different? Third, what is the single most likely reason this dies in the next ninety days, and is it instrumented? That third question regenerates the loop. The new top risk becomes the input to a new round of imagining.

The cost asymmetry is the whole reason to bother, and it is worth seeing as a curve rather than a sentence.

The lesson does not change. Why a project failed is roughly the same fact whether you discover it on day zero or day three hundred. What changes is the price of the discovery. At the start it costs you an afternoon and some discomfort. At the end it costs you the company, the team, and a year of your life. The pre-mortem is simply a decision to buy the cheap copy of the lesson.

The five surfaces where startups actually die

When you enumerate kill reasons, it helps to know where deaths cluster, so your imagination has somewhere productive to point. The published data on why startups and AI projects fail is consistent enough to map, and the map keeps your pre-mortem from drifting into improbable disasters while missing the boring ones that actually kill companies.

Read the percentages as evidence, not as a scoreboard, since they come from different studies measuring different populations. Around 35 percent of startup failures, per CB Insights, cite no market need, which is why “people liked it but nobody paid” belongs at the top of every pre-mortem. Of venture-backed companies that shut down, roughly 70 percent had run out of capital, which is why a cash kill criterion is non-negotiable. Leadership and team problems drive a strikingly large share of failures, with one analysis attributing 84 percent to leadership issues. On the execution surface, 88 percent of AI agent pilots never reach production, often because the thing they depended on shifted or because the gap between a working demo and a working product was wider than anyone budgeted for.

The founder surface has no clean statistic, because nobody surveys dead companies and writes “the founder simply stopped.” But the 90 percent base rate sitting next to the near-universal belief in being the exception tells you the surface is real. The pre-mortem is the one tool that points the optimism-blinded founder directly at their own most likely failure.

I have written about where defensibility actually lives when the platform under you keeps changing, in a piece on building an AI business that survives model churn, and about the specific reasons agents collapse on the execution surface in why AI agents fail in production. The pre-mortem is the practice that forces you to confront both before you commit, rather than after.

A worked pre-mortem on the deaths everyone studied

Abstract advice is easy to nod at and hard to use, so let me run the practice against two failures that already have famous postmortems. The point is not to dunk on anyone. It is to show that the postmortems being passed around contain reasons a pre-mortem on day zero could have surfaced for the price of an afternoon.

Take the AI video product that launched, drew close to a million users, and was switched off after 84 days while burning roughly a million dollars a day. The published autopsy is mostly about compute economics: the company decided it would rather point those graphics chips at its coding and enterprise products, and a large content partnership fell apart. Now run the pre-mortem backwards. On the Cash surface, the kill reason writes itself: “we shipped a product whose unit economics only work at a scale we never reached, and every active user cost us money.” That is not hindsight genius. The burn-per-user math existed on day one. A cash kill criterion of the form “if cost per active user is not under target X by week Y, we cap growth and fix economics before scaling” would have forced the conversation in week six instead of letting it run to a shutdown. The Execution surface reason is just as visible: “the platform that owned our compute had a more profitable use for it.” When you rent the most expensive input to your product from a company that also competes for that input, dependency is your most likely cause of death, and I have written about exactly that pattern in the model-churn piece linked above.

Now take the app-building company that reached a 1.5 billion dollar valuation and then collapsed into liquidation when investigators found revenue inflated by around 300 percent, with roughly 55 million dollars of real sales behind a 220 million dollar claim, and an “AI” that was largely human engineers. The postmortem is a fraud story. But a pre-mortem run honestly by the people inside would have hit the Team and Founder surfaces hard: “we told a story about the product that the product could not back up, and we kept telling it because the funding depended on the story.” The uncomfortable kill reason there is not technical. It is the one Klein’s protocol is designed to extract, the thing nobody will say in a normal meeting because it implicates the room. A pre-mortem that asked “assume we are exposed and dead in a year, why?” makes “because the numbers were not real and we all knew it” a legitimate answer instead of a career-ending accusation. That is the whole power of assuming the failure first. It gives the dangerous truth a door.

The lesson across both is the same one the cost curve showed. Every reason in those postmortems was available before launch. The companies did not lack the information. They lacked the practice of looking at it while looking still cost nothing. A graveyard of 142 buried companies is, read another way, a library of pre-mortems that were never run.

The contrarian take: a pre-mortem is not pessimism

The objection I hear most is that this is just dressed-up negativity. That dwelling on failure before you start will sap the conviction you need to do hard things, and that founders win by being delusionally optimistic, not by cataloguing the ways they might die. There is a real version of this concern, so let me take it seriously and then say where it is wrong.

The strongest case for relentless optimism is that most worthwhile things look impossible from the starting line, and a founder who fully priced in the odds would never begin. Optimism is not a bug in the founder mind, it is the engine. If you ran a brutal, honest pre-mortem on any ambitious project, the rational move would often be to not do it. So the worry that pre-mortems kill momentum is not silly. A team that spends every Monday rehearsing its own funeral will eventually believe in the funeral.

Here is why the objection misses. A pre-mortem is not a prediction that you will fail. It is a tool that assumes failure in order to gather information, then puts the optimism back. The difference is in what you do with the list. A pessimist reads the kill reasons and concludes the project is doomed. A founder reads the same list and instruments the top three, then proceeds with more confidence, not less, because the failures that used to live as a vague dread are now scheduled checks with defined responses. You have not added fear. You have converted free-floating fear into a managed set of risks.

The research is direct on this point. Pre-mortems reduce overconfidence, but they do not reduce action. They improve plan quality and increase the range of problems a team can anticipate and route around. The founders I have watched run this practice are not more hesitant. They are calmer, because they are no longer carrying a backpack of unnamed worries. The unhealthy alternative is not optimism, it is suppression, where you feel the risk, refuse to name it, and let it gnaw at you while you pretend it is not there.

There is also a failure mode in the other direction, and intellectual honesty requires naming it. You can over-instrument. If you turn forty fears into forty kill criteria and forty dashboards, you have built a bureaucracy of anxiety and you will spend more time auditing the project than building it. The discipline is to instrument the top three or four kill reasons and let the rest stay on the list as awareness, not as machinery. A pre-mortem that produces a forty-item monitoring system has missed the point as badly as one that produces nothing. The goal is the cheapest possible insurance, not the most thorough.

What to do Monday morning

Pick the project you are most excited about right now, the one you are least inclined to question. That is the correct target, because excitement is exactly the state in which the planning fallacy is strongest. Then block ninety minutes and run the loop once, by hand.

Start with the imagine move. Open a document and write, in past tense, the obituary of this project. “It is twelve months from today. The project is dead. Here is the story of how it died.” Do not hedge. Do not write “it might have struggled”. Write that it died, then explain. Give yourself fifteen minutes and do not stop early.

Then enumerate. Walk the five surfaces, Market, Cash, Team, Execution, Founder, and force at least two kill reasons from each, including the one that embarrasses you. If you cannot write a brutal Founder reason, you are not done. Aim for at least ten total. The honest ones will feel slightly sick to write. That feeling is the signal you are doing it right.

Now instrument. Circle the three reasons that are both most likely and most damaging. For each, write one leading indicator you can actually observe within the next month, and one kill criterion in state-and-date form: “if I am not in state X by date Y, I do Z.” Put those three checks somewhere you will see them, and put the kill dates on your calendar as real events.

Finally, schedule the revisit. Set a recurring quit-or-commit review, monthly to start, separate from your normal work rhythm. At each one, ask whether any criterion tripped, whether you honored it, and whether the world changed enough to rerun the whole pre-mortem. That recurring appointment is what turns a clever exercise into a practice, and the practice is what compounds.

If you want to go deeper on the surrounding skills, the pre-mortem sits inside a wider founder operating system. It pairs naturally with knowing the art of killing ideas cleanly, with making decisions under uncertainty without freezing, and with second-order thinking that traces a choice past its first consequence. It also connects to how I think founders should reason about fast-moving technology in how founders should think about AI, and where the cost of failure actually lands in a cost-first AI product launch. The full map lives in the founder operating system.

One afternoon. That is the entire ask. The graveyards are full of products whose founders could have written the postmortem on day one and chose not to look. You do not have to be one of them. Look now, while it is cheap.

Frequently asked questions

What is a pre-mortem?

A pre-mortem is the opposite of a postmortem. Before a project starts, you imagine it is twelve months in the future and has already failed completely, then work backwards to write the story of why. The technique was named by cognitive psychologist Gary Klein. Assuming the failure as a fact, rather than asking what could go wrong, makes people far more honest and specific about the risks they actually see.

How is a pre-mortem different from a postmortem?

A postmortem analyzes a failure after it has happened, when the decisions that mattered are already a year old and cannot be changed. A pre-mortem analyzes the same likely failure before you start, while it still costs only an afternoon and some discomfort to prevent. The lesson is roughly identical. The only thing that differs is the price you pay to learn it, and that price rises every month you wait.

Does the pre-mortem technique actually work?

The evidence is solid. Research on prospective hindsight by Mitchell, Russo, and Pennington in 1989 found that imagining an outcome has already happened increases the ability to correctly identify reasons for it by about 30 percent. Gary Klein reports the framing roughly doubles the number of risks a team surfaces. Later quantitative studies found pre-mortems generate more reasons than worst-case-scenario methods and reduce overconfidence more than devil’s advocate approaches do.

How do I turn pre-mortem fears into something actionable?

Take your top three or four kill reasons and convert each into a leading indicator you can watch and a kill criterion that combines a state and a date, in the form “if I am not in state X by date Y, I stop.” Annie Duke calls these states and dates. Writing them while you are calm prevents the emotionally attached future version of you from talking their way out of quitting when the signal actually fires.

How often should a founder run a pre-mortem?

Run it as a loop, not a one-time meeting. Do a full pre-mortem before you start, then hold a recurring quit-or-commit review, monthly for an early project and quarterly once it is stable. At each review, check whether any kill criterion tripped, whether you honored it or quietly moved the goalposts, and whether the world changed enough to rerun the whole exercise from scratch.

Is a pre-mortem just negative thinking that kills momentum?

No. A pre-mortem assumes failure to gather information, then puts the optimism back. A pessimist reads the kill reasons and quits. A founder instruments the top three and proceeds with more confidence, because vague dread becomes scheduled checks with defined responses. Studies show pre-mortems reduce overconfidence and improve plans without reducing action. The unhealthy alternative is not optimism, it is suppressing risks you can feel but refuse to name.

Can a solo founder run a pre-mortem alone?

Yes, and in some ways it is easier. With no audience to perform confidence for, you can be fully honest. Write the failure account in past tense as a real obituary, walk the five failure surfaces of Market, Cash, Team, Execution, and Founder, and force at least two reasons from each. The founder surface, where you lose interest or burn out, is the one solo founders most often skip and most need to confront.

What are the five surfaces where startups usually die?

Market, where there is no real need despite polite interest. Cash, where roughly 70 percent of shutdowns run out of capital. Team, where co-founder splits and leadership gaps drive a large share of failures. Execution, where a platform shift or the demo-to-production gap makes you redundant. And Founder, where you lose interest or burn out, the most likely cause of a solo project’s death and the one optimism hides best.