How to Run a Startup Pre-Mortem Before You Build

A startup pre-mortem is a session, run before you build anything, in which you assume the company has already failed and work backward to the cause. It takes about 90 minutes, produces a ranked list of the ways this specific company dies, and turns the top three into tests you can run in the next month. It is the cheapest diligence a founder can do on their own idea, and almost nobody does it because it feels like pessimism. It is the opposite: the founders who name the failure modes early get to choose which ones to fight.

We run pre-mortems on our own product decisions and we built an agent, the AI Red Team, whose only job is to argue against the founder. This article covers the human version first, then how to run it alone with an AI.

What a startup pre-mortem is and why it works before a post-mortem can

A pre-mortem works because people are far better at explaining a failure that has already happened than at predicting one that might. Ask a team "what could go wrong" and you get a polite list of generic risks. Tell the same team "it is eighteen months from now, the company is dead, write down why" and you get specific, uncomfortable, mostly correct answers. The framing removes the social cost of doubting the plan, because the plan has already failed in the exercise.

The technique was described by the psychologist Gary Klein in the Harvard Business Review in 2007. It does not need the literature to work; it needs a founder willing to hear the answers. A post-mortem is what you write after the money is gone. A pre-mortem is the same document written while you can still act on it.

How to run a startup pre-mortem in 90 minutes

Five people or fewer, one page of the plan, silent writing, then ranking. The format below is the one we use.

1. Share the plan in one page (10 minutes). What the company sells, to whom, at what price, how it reaches them, and what has to be true in eighteen months for it to be alive.
2. State the failure (2 minutes). Say it aloud: "It is [month, eighteen months from now]. The company has shut down." Fix the date; a vague future produces vague causes.
3. Write in silence (15 minutes). Every person writes as many distinct causes as they can, one per line, no discussion. The first spoken cause anchors everyone else, so nobody speaks.
4. Read them out (20 minutes). One cause per person per turn until the lists are empty. Merge duplicates only when they are the same mechanism, not the same topic.
5. Rank (30 minutes). Score each cause on the three axes in the next section and sort.
6. Assign tests (13 minutes). For the top three, name the test, the owner and the date.

Solo founders skip the group dynamics but keep every step; the AI Red Team section below covers the second voice.

The pre-mortem prompt that produces specific failure causes

The prompt is a single sentence that fixes the date and the outcome, and the discipline is refusing generic answers. "We ran out of money" is not a cause; it is the outcome of a cause. Push every line until it names a mechanism: "Sales cycles in mid-market restaurants ran nine months and we priced for a three-month cycle, so cash ran out before the fourth customer paid."

Causes for an early-stage company fall into a few families, and it helps to check each is represented before ranking:

• Nobody wanted it enough: the problem was real but not painful enough to change behaviour or pay for.
• The wrong buyer: the user loved it and the person with budget did not care.
• An incumbent absorbed it: the feature shipped inside a tool customers already paid for.
• Distribution never came: the product worked and no channel delivered customers at a cost the price could bear.
• The team broke: a co-founder left, vesting was never signed, the technical founder was the only one who could ship.
• A silent dependency: a platform, a regulation or a supplier changed and the business could not.

Our guide to validating a startup idea with AI covers how to test the first family directly; the other five are the ones founders forget.

How to rank pre-mortem failure causes: likelihood, cost and detectability

Score every cause from one to five on three axes and sort by the product. Likelihood is how probable it is given what you know today. Cost is how much of the company it takes with it. Detectability is inverted: a five means you would only notice when it is too late. That third axis is the one most risk lists omit, and it is the one that separates a pre-mortem from a worry list.

| Cause (illustrative, fictional restaurant scheduling startup) | Likelihood | Cost | Late to notice | Score | |---|---|---|---|---| | Incumbent POS vendor ships scheduling as a free add-on | 4 | 5 | 4 | 80 | | Managers use it but owners will not pay per location | 4 | 4 | 3 | 48 | | Nine-month sales cycle against a three-month cash plan | 3 | 5 | 2 | 30 | | Technical co-founder leaves before vesting cliff | 2 | 5 | 1 | 10 | | Labour-law change in one state breaks the scheduling rules | 2 | 3 | 5 | 30 |

The scores are illustrative and the company is fictional. The incumbent risk sits at the top not because it is the most likely, but because it is likely, fatal and slow to show up: a founder would spend months reading good retention numbers while the incumbent's roadmap quietly decided the outcome. Where two causes tie, the one you would notice later wins the higher rank.

Turning the top failure causes into tests you can run this month

Every top-ranked cause becomes one test with a kill criterion, an owner and a date. A test without a number you would act on is a research project. The shape is always the same: "If [observation] by [date], we [change the plan in this specific way]."

For the illustrative table above: the incumbent risk becomes ten calls to restaurant owners who already use that POS, asking whether they have seen the scheduling add-on and whether they would switch off it. The kill criterion is that if seven or more say they would take the free option, the wedge changes before any code is written. The buyer risk becomes five owners asked to pre-pay for a pilot at the intended price; three refusals means the pricing model, not the product, is the first thing to redesign.

Run the tests before the build, not alongside it. A founder who has written the first thousand lines of code is already defending them, and the test gets designed to pass. The 30-day idea-to-MVP plan we recommend puts the pre-mortem in the first week for that reason. Write the results into the same document as the causes; a pre-mortem that lives in a workshop slide is decoration.

Running a pre-mortem alone with an AI Red Team

A solo founder needs a second voice that does not care about their feelings, and that is what an AI red team is for. One person cannot argue against their own plan for long. The second voice has to be adversarial by design, not a general assistant that agrees with the prompt.

On Founders360 the AI Red Team reads the company profile, market size and competitor set that the Market Researcher has already written into Shared Context, then argues from those facts rather than from generic startup advice. On a fictional test company we use internally (ShiftPilot, an AI scheduling idea for restaurants), its first question named a real incumbent and asked what stops customers clicking that incumbent's auto-fill button. That is the top row of the table above, produced in the first minute, because the competitor list was already in context. The agent writes its ranked objections and the founder's answers back into Shared Context, so the Funding Finder later builds a deck that pre-empts them.

The rule we hold ourselves to is that the AI should argue, not flatter; we wrote about why in why your AI co-founder should argue with you. If the tool only ever validates the idea, it is a pep talk, not a pre-mortem. The free Skeptical VC does the same job from an investor's chair with no login.

Startup pre-mortem mistakes that waste the session

The most common mistake is running the pre-mortem with only people who want the plan to succeed. Co-founders, early hires and friendly advisors all have a stake in the answer. Invite one person who does not, or use the adversarial tool, and weight their causes higher.

The second is stopping at the list. Causes with no tests, owners or dates are a risk register, and risk registers are where risks go to be ignored. The third is treating a cause you cannot detect as a cause you do not have. We learned this on our own product: one agent's write-back into the shared memory was broken for the entire life of the feature by a single wrong dictionary key. Nothing raised, nothing logged, no request failed, and the allowlist read like coverage while nothing was written. The fix was a test that asserts every key matches something real and a health report of attempted versus produced. The pre-mortem equivalent is a cause scored five on detectability: if you would only find out after the fact, build the instrument now.

The fourth is running it once. Repeat it at every plan change, before a raise (the hardest investor questions are the causes you did not rank), and whenever a test fails.

Frequently Asked Questions

What is a startup pre-mortem?

A startup pre-mortem is a session, run before building, in which the team assumes the company has already failed at a fixed future date and writes down the specific causes. The causes are ranked by likelihood, cost and how late they would be noticed, and the top ones become tests with kill criteria.

How long does a startup pre-mortem take?

About 90 minutes for a team of five or fewer: ten to share a one-page plan, fifteen of silent writing, twenty to read the causes out, thirty to rank them and the rest to assign tests. A solo founder with an adversarial AI can do a first pass in under an hour.

Can a solo founder run a pre-mortem?

Yes, provided there is a second voice that argues against the plan. A general-purpose chatbot tends to agree with the prompt; an adversarial tool such as the AI Red Team on Founders360, or the free Skeptical VC, produces the objections a co-founder would.

What is the difference between a pre-mortem and a risk register?

A risk register lists risks and owners and is reviewed quarterly. A pre-mortem assumes the failure has happened, which produces more specific causes, and converts the top ones into tests with dates and kill criteria. The output is action this month, not a document.

How often should a startup repeat a pre-mortem?

Before the first build, before every fundraise, at every material change of plan, and after any pre-mortem test fails. Start each repeat from the previous document so retired causes do not consume the session again.

This week: write your plan on one page, set a failure date eighteen months out, and spend fifteen minutes in silence listing the causes. Score them on the three axes, then design one test for the top row with a number that would make you change the plan, and run it before you write any code.