Before you build
Startup Idea Pre-Mortem — Imagine It Already Failed
You have a one-liner. The repo is empty. The temptation is to open a design file or a model window and “just start.” A pre-mortem is the cheaper hour: write the failure history first, rank the ways it died, and leave the room with tests — not with a feature list.
Last updated: September 27, 2026
Direct answer
What is a startup idea pre-mortem?
A pre-mortem is a structured exercise: you treat the idea as already dead, then write why. Gary Klein, a research psychologist, published the method for project teams in “Performing a Project Premortem” (Harvard Business Review, September 2007). The useful move is not “what might go wrong?” — that question is easy to dodge. The useful move is “it failed; what killed it?” Klein’s HBR note points to 1989 work by Deborah J. Mitchell, J. Edward Russo, and Nancy Pennington on prospective hindsight: people generate more specific reasons when they treat an outcome as already known. This page adapts that desk exercise for a solo founder with a one-liner. The output is a ranked failure list plus the cheapest test that could show each top mode is already true. It is not a forecast that the startup will succeed or fail.
Key takeaways
What to remember
- Declare the death first. “What might go wrong?” is a risk chat. “It is 18 months later and the idea is dead” is a pre-mortem.
- Leave with a ranked list, not a brainstorm. Lethality first (would this invalidate the plan?), then likelihood.
- Each top mode needs a cheapest falsify test — a conversation about last Tuesday, a one-page smoke test, or a week of manual delivery. No factory.
- Write Continue / Refine / Stop before anyone talks to you. A bar invented after the compliments is a recap.
- A Yibud score is a flashlight. It can point at a weak dimension. It cannot write the failure history or decide for you.
Why it matters
Why founders skip the ugly hour
I have watched people spend a quarter building the part of the idea they already like — usually the interface — while the plan still hangs on a sentence they never wrote down: that a named person will pay, switch a weekly habit, or be reachable in a channel the founder can actually work. Klein’s original setting was a project team that has already almost decided. Daniel Kahneman, in Thinking, Fast and Slow (Farrar, Straus and Giroux, 2011), describes Klein’s session as a short speech: imagine you are a year on, the plan was implemented, the outcome was a disaster, and each knowledgeable person writes a brief history of that disaster. Kahneman’s interest is overconfidence and suppressed doubt, not startup scoring. A solo founder has a quieter version of the same problem. There is no dissenting colleague. There is only the story you tell yourself. Forty-five minutes of written failure is cheaper than three months of code that never met the lethal mode.
Vocabulary
Four terms this page uses on purpose
These match how the rest of Yibud talks. If a sentence here uses one of these words, it means this.
Pre-mortem
A structured session that assumes the idea or plan has already failed and asks for plausible reasons. Klein (HBR, 2007) framed it as the opposite of a medical post-mortem: you run it at the beginning so the plan can be repaired, not autopsied. On this page the “patient” is a one-liner startup idea, not a funded program.
Failure mode
A specific way the idea dies — not “marketing was weak,” but a mechanism: the named buyer never had the weekly pain, would not pay the planned price, could not be reached, or already had a good-enough workaround. Vague modes do not earn a test.
Cheapest falsify test
The lowest-cost action that could show a failure mode is already true. Interviews about a recent incident, a landing page with one action, or delivering the job by hand all qualify. A six-month build that “will prove it” does not.
Continue / Refine / Stop
Three verdicts written before field evidence arrives. Continue: the top modes are testable this week and nothing you already know makes the lethal one look true. Refine: the one-liner is too wide; rewrite the person or the job, then re-run the same session. Stop: you already have evidence the lethal mode is true, or you cannot name a cheap test and you are about to spend months anyway.
Not the same page
Pre-mortem vs critical-assumption vs the score
Three Yibud pages sit next to each other. Mixing them up wastes a week.
This page — generate the list
Thirty to forty-five minutes at a desk. You invent the failure history, rank the modes, and write one cheap test per top mode. You do not yet need interviews. You need a one-liner and a timer.
Critical assumption — kill one claim
After you have a ranked list, pick the single claim that would make the rest of the plan irrelevant if false. Write Continue / Refine / Stop lines, then spend a week trying to break that claim.
Critical assumption first — name, falsify, decide →A mid-band overall score is a flashlight, not a pre-mortem. It ranks relative risk in the inputs you typed. It does not write the disaster history. What a validation score actually means →
After the ranked list exists, write the Stop contract: signal, threshold, window, action. A pre-mortem without tripwires is a ranked diary. Write kill criteria before the next sprint →
The hour
How to run a 30–45 minute pre-mortem on a one-liner
Solo is fine. Klein designed the method for a team that has almost committed; Kahneman’s write-up keeps the silent writing step for a reason. If you have a co-founder, each of you writes alone for ten minutes before you talk. If you are alone, the page is the other person. Set a timer. Do not open the build.
- 1
Minutes 0–5 — write the one-liner and the obituary header
One sentence: who, what job, what you take in return. Then title a blank page: “It is 18 months from now. The idea failed. Here is why.” Klein’s prompt is past tense. “Might fail” lets you stay polite. “Failed” does not.
- 2
Minutes 5–15 — generate reasons in silence
List every plausible cause. Quantity first. Include: nobody had the problem in a real week; they had it and would not pay; you could not reach them; an incumbent was good enough; you could not deliver the outcome by hand; you quit. Do not rank yet. Do not explain the vision in the margin.
- 3
Minutes 15–22 — strike polite causes
Delete “we needed more features,” “marketing wasn’t good enough,” and “the timing was wrong” unless you can name the mechanism. A cause that cannot be tested or observed is a mood. Keep the ones that name a person, a price, a channel, or a workaround.
- 4
Minutes 22–32 — rank by lethality, then likelihood
For each remaining mode write L / M / H for likelihood and yes / no for lethality: would this invalidate the plan, or only hurt it? Sort lethal modes to the top. Then sort those by likelihood. The top three are the week’s work. The rest is a parking list.
- 5
Minutes 32–42 — write the cheapest falsify test for each top mode
One test per mode. If you still do not know whether the pain showed up last Tuesday, start with conversations about that Tuesday — Rob Fitzpatrick’s Mom Test discipline belongs here, not a pitch. If strangers already describe the pain and the expensive unknown is reach or intent, a one-page smoke test is enough. If they reach and the unknown is whether they will use or pay for a delivered outcome, do the job by hand. Steve Blank’s Customer Development is the posture after this page: leave the building to test the ranked claims. It is not a reason to skip the ranking.
- 6
Minutes 42–45 — write Continue / Refine / Stop for the idea
Three lines, same page, same sitting. Continue if the top modes are testable this week and nothing you already know makes the lethal one look true. Refine if the one-liner still says “users” or two jobs at once. Stop if the lethal mode is already visible in evidence you have, or if you cannot name a cheap test and you were about to spend a quarter building anyway.
What you leave with
The Failure Mode Ledger (copy this)
If the hour produced a mood, you did not finish. The page should have three filled rows and three verdict lines. Fill the brackets. Leave nothing as “users.”
Row — one failure mode
[Rank] [Named person] will not [observable action] because [mechanism]. Lethality: [yes/no]. Likelihood: [L/M/H].
Mechanism examples: no weekly pain, will not pay the planned price, cannot be reached in the named channel, already has a good-enough workaround. “They weren’t ready” is not a mechanism.
Row — cheapest falsify test
This week I will [conversation / one-page / manual job] with [N] qualified people. A no looks like [no incident / no click / no file / no payment] by [date].
Pick one method per mode. Three methods on one mode is stalling. The test should be able to produce a no you would accept.
Footer — the three verdicts
Continue if [top modes testable + no lethal mode already true]. Refine if [rewrite person or job, then re-run this hour]. Stop if [lethal mode already visible, or no cheap test exists].
Write the footer before recruitment. Sunday’s story is not a result.
The fork
Continue, Refine, or Stop after the hour — not after the build
The pre-mortem does not replace the field week. It decides whether the week is worth running, and on which sentence. The kill-first loop on the critical-assumption page is what you do next if the hour says Continue or Refine.
Continue
The top modes are specific, lethal or near-lethal, and each has a test you can run this week. You do not already have evidence that the lethal one is true. Take the first row into the critical-assumption week.
Refine
The one-liner still names “busy people” or two jobs. Or two modes tie for lethality because the person is fuzzy. Rewrite the person or the job on the same page. Re-run steps 2–6. Do not “refine” by adding a feature.
Stop
You already watched the lethal mode happen — nobody you can find has the weekly pain, or they have a workaround they will not drop — and you were about to build anyway. Or you cannot name a cheap test for the lethal mode. Write what you will not build. A different one-liner gets its own hour.
Worked example
One hour you can copy (illustrative)
The hour below is illustrative — names, prices, and counts are invented so you can see the setup. It is not a conversion benchmark and not a Yibud report. Copy the method, not the numbers.
The one-liner, written at minute 0
“A weekday dinner planner for parents who cook after 7 p.m., sold as a $9/month list.” The tempting next step is a recipe graph. The pre-mortem header is: it is 18 months later; the planner is dead.
Rank 1 — they already have a good-enough workaround (lethal, high)
Mechanism: last Tuesday they used a notes app, leftovers, and a grocery store they already walk through. They will not switch for a generated list. Cheapest falsify test: five conversations about last Tuesday’s dinner — no pitch. A no looks like: they describe a specific meal and a workaround they already accept. That is a Stop or a Refine toward grocery logistics, not a reason to ship recipes.
Rank 2 — they want the plan and will not pay $9 (lethal, medium)
Mechanism: the pain is real; the subscription is not. Cheapest falsify test: offer to plan next week’s five dinners by hand for $9. A no looks like: they take the free version of the conversation and do not send the $9 or a second week’s constraints. Compliments in the thread do not count.
Rank 3 — the founder cannot reach them except through ads they cannot afford (lethal if true, unknown)
Mechanism: the only path to a parent who cooks after 7 p.m. is paid social. Cheapest falsify test: one post in a single parent forum the founder already belongs to, asking who planned this week’s dinners after 7. A no looks like: silence, or replies from people who do not cook. Do not buy ads to “get a sample” before this post exists.
Illustrative close: the hour says Refine, not Continue — “parents” is still wide, and Rank 1 is untested. Rewrite as “parents who cooked after 7 p.m. three weeknights last week and already buy a meal kit or takeout those nights.” Then take Rank 1 into a critical-assumption week. Do not open the recipe graph “so the next five have a product.”
Where Yibud fits
Use the free validator as a flashlight, then run the hour yourself
Yibud is a free, no-signup startup idea validator. Scores come from a deterministic rule engine, not from a language model guessing success. Optional AI text, when it is used, only polishes prose. It does not invent the number. A Startup MRI report can name a weak dimension and a critical assumption. That is a starting flashlight. This page is the desk hour that turns a one-liner into a ranked failure list. If you already have a report, start the pre-mortem with the weakest dimension as a prompt — not as a verdict. Then write the three tests yourself.
Analyze my idea →Common mistakes
What usually wastes the hour
Running it as “what might go wrong”
That is a risk register. Klein’s method needs the past tense. If you catch yourself writing “we might struggle with distribution,” rewrite: “eighteen months later, nobody we could afford to reach ever saw the page.”
Stopping at the list
A page of fears is not a pre-mortem. Without rank, a cheapest test, and three verdict lines, you will test the mode you already like.
Testing the failure mode that flatters you
“The recipes weren’t personalised enough” keeps the build alive. The lethal mode is usually payment, a weekly workaround, or reach. Rank lethality before taste.
Treating compliments as disconfirming evidence
“I would use that” is not a no on Rank 1. Ask about last Tuesday, or ask for the $9, or ask for the file. Politeness cannot kill a mode you refused to test.
Using the score as the pre-mortem
A low distribution number is a hint. It is not the disaster history. If you skip the hour because the overall looked friendly, you used the flashlight as a permission slip.
Sources
Where these ideas come from
- Gary Klein, “Performing a Project Premortem” (Harvard Business Review, September 2007) — The primary business write-up of the method: assume the project has already failed, then generate plausible reasons. Used here as the core move — past tense, written reasons — not as a success-rate table. Klein does not claim the exercise predicts startup outcomes.
- Deborah J. Mitchell, J. Edward Russo, and Nancy Pennington, “Back to the Future: Temporal Perspective in the Explanation of Events” (Journal of Behavioral Decision Making, 1989) — The prospective-hindsight paper Klein’s HBR note points to. People generate more specific explanations when they treat an outcome as already known. Cited as the cognitive basis, not as a conversion statistic. This page does not invent a percentage on top of that paper.
- Daniel Kahneman, Thinking, Fast and Slow (Farrar, Straus and Giroux, 2011) — Kahneman describes Klein’s premortem as a brief session against overconfidence and suppressed doubt: imagine a year later, the plan was implemented, the outcome was a disaster, write the history. Used here as a reputable secondary account of business use — not as a startup scoring method.
- Steve Blank, Customer Development / The Four Steps to the Epiphany (2005) — Used only after ranking: the cheapest falsify tests are hypotheses you leave the building to test. Blank is not the source of the pre-mortem, and this page does not treat Customer Development as a sample-size rule.
In one paragraph
Summary you can quote
A startup idea pre-mortem is a 30–45 minute desk exercise: you treat a one-liner as already failed, write the reasons, rank them by lethality then likelihood, and attach the cheapest test that could show each top mode is already true. Gary Klein published the team version in Harvard Business Review in 2007; Daniel Kahneman later described it as a check on overconfident plans. The output is a ranked failure list plus Continue / Refine / Stop lines written before any compliment arrives. It is not a prediction that the startup will succeed. A Yibud score can point at a weak dimension. The hour still has to be written by the founder.
FAQ
Questions founders actually ask
How is a pre-mortem different from a SWOT list or a risk register?
Those lists enumerate what might happen. A pre-mortem assumes the death already happened and asks for mechanisms. Klein’s HBR piece is explicit about the tense shift. A register that never produces a ranked test and a Stop line is a diary.
How is this different from critical-assumption validation?
This page generates and ranks many failure modes. The critical-assumption page picks the single kill claim and runs a cheap week against a bar you wrote on Monday. Do the hour first if you only have a one-liner. Do the week next if the hour says Continue or Refine.
Do I need a team? Klein wrote this for project teams.
A team helps because dissent is easier when someone else writes first. A solo founder can still run it: silent writing, a timer, and a page that is allowed to be rude. If you have a co-founder, do not talk until both pages exist. Kahneman’s account keeps that silent step for a reason.
Can a pre-mortem tell me the idea will succeed?
No. Klein’s method surfaces reasons you would otherwise swallow. Kahneman presents it as a check on overconfidence, not as a forecast. Yibud will not tell you the idea will succeed either. The score is a structured read of the inputs you typed.
Where does the Yibud score fit, and do I need an account?
You do not need an account. Run the free analyzer if you want a flashlight on weak dimensions before the hour, or after it. The engine is deterministic. Optional language-model text only polishes prose. Bring this page to the report: write the disaster history, rank it, then take the top row into a critical-assumption week.
Write the failure history before you write the code
Yibud scores weak dimensions with a deterministic engine. You run the 30–45 minute pre-mortem, leave with ranked tests, and decide Continue / Refine / Stop against lines you wrote before anyone was polite.
Generate a Yibud report →