A pre-mortem is a meeting where you imagine your project has already failed and work out why. Gary Klein described the method in Harvard Business Review in 2007: team members assume that the project they’re planning has just failed. Starting from “we failed” turns vague worries into specific stories you can check.
For a startup, the best time to run one is before you commit money to a build, while every risk is still cheap to test. This guide gives you a 90-minute format, a template with a filled-in example, and the step most pre-mortems skip: turning each failure story into a test, a stop rule or a smaller first release.
| Minutes | Step | What you end up with |
|---|---|---|
| 0-10 | Set the scene: “It’s 12 months from now. The product failed.” | Everyone working from the same failure date |
| 10-30 | Everyone writes failure stories alone, each starting with “We failed because…” | 3 to 5 stories per person |
| 30-50 | Read them out, merge duplicates, vote on the most likely | 5 to 7 failure stories |
| 50-75 | Find the root cause of each top story | One root cause per story |
| 75-90 | Pick a defense and an owner for each cause | A list of tests, stop rules and cuts, each with a name and a date |
Invite the people who will build, sell and pay for the product. If you work with an outside development team, invite their lead too. They may have seen products like yours fail in ways you haven’t.
“Technical risk” is a category. “We failed because the AI scoring was wrong one time in five and customers stopped trusting it” is a story you can test. Push the room for stories.
Real shutdowns give you a starting list. CB Insights looked at 431 venture-backed startups that shut down since 2023 and found the reasons for 385 of them. Running out of capital came up in 70% of cases, poor product-market fit in 43%, bad timing or the economy in 29% and unit economics that didn’t work in 19%. The report calls running out of capital almost always the final cause of death, not the root problem. Step 2 below is for finding that root problem.
For a product build, look for stories in five areas:
Platform stories are common for apps. In 2025 Apple reviewed 9,100,620 App Store submissions and rejected 2,093,244 of them. Performance problems were the most common reason, with 1,354,418 rejections (App Store Transparency Report 2025). Google Play has its own deadlines: from 31 August 2026, new apps and app updates must target Android 16 to be submitted (Google Play target API level requirements).
For each top story, keep asking “why did that happen?” until you reach something you can change. Five rounds is the usual rule of thumb.
Story: we ran out of money before launch.
The late launch is the symptom. The cause is a missing decision rule, and writing one takes an afternoon.
For each root cause, pick at least one defense you can start this month:
Then add two things most pre-mortems leave out.
The first is a test before the build. If a story depends on something technical you haven’t proven, test that first. On Subflare, an AI lead scoring product, we tested the risky AI part in 2 weeks before building the MVP. Our discovery sprint also sets aside one day for the riskiest technical question, for example running an AI model on 10 to 20 of your real examples.
The second is a stop rule. Decide now what result makes you stop, change course or cut scope. “If fewer than 10 of our first 50 pilot users come back in week two, we stop adding features and go talk to them” is a stop rule. Write it down with a date, because the call gets harder once the money is spent.
| Failure story | Root cause | Defense | Owner and date |
|---|---|---|---|
| The App Store rejected the app two weeks before launch | Review was planned as the last step, with no buffer | Send a build to review early, and check the app against the store rules for its category | Product owner, before the second sprint |
| Professionals didn’t move their bookings into the app | Nobody asked how they take bookings today | Interview 10 professionals about their last 10 bookings before building the calendar | Founder, within two weeks |
| The calendar took twice as long as planned | The full custom calendar was in the first release | Ship a first version of the calendar, and move notifications forward | Tech lead, at scoping |
| The budget ran out in month four | No checkpoint between “start” and “launch” | A spending checkpoint at 50% of the budget, with a continue, cut or stop decision | Founder, written into the plan |
The defenses in the first and third rows come from a real project. On Traza, a booking app for tattoo artists, the launch date was already promised and App Store review can take one to two weeks. So we sent the app to review early instead of polishing it until the last day, and it was approved on both stores. When the custom calendar grew bigger than planned, we cut it to a first version and moved push notifications and booking creation forward.
Investors ask about risks to find out whether you’ve thought about them. A pre-mortem gives you a specific answer: the two or three most likely failure stories, their causes and what you’re already doing about each. Put them on one “Risks and defenses” slide, use them when you talk about the market and competitors, and keep the full table ready for questions.
A pre-mortem goes better when the room has numbers to argue with. You can run your idea through our project estimate before the meeting:
Turn each one into a failure story. “We failed because the customer group was much smaller than we assumed.” “We failed because winning a customer cost twice our guess, and payback moved past our runway.” Change the starting numbers to your pessimistic case and watch the payback month move. If it lands after the money runs out, you have a stop rule with a number in it.
A meeting where the team imagines the project has already failed and works backward to the reasons. Gary Klein described the method in Harvard Business Review in 2007.
Before committing a budget to a first version or a big release, before a fundraise, before hiring or switching a development team, and after a pivot.
About 90 minutes: 10 to set the scene, 20 to write failure stories alone, 20 to merge and vote, 25 to find root causes and 15 to assign defenses and owners.
A risk assessment lists what might go wrong. A pre-mortem starts from a failure that has already happened and asks why, which gives you specific stories you can test.
Add one “Risks and defenses” slide with the two or three most likely failure stories, their root causes and what you’re already doing about each.
Turn a pre-mortem into owned tests, stop conditions and a smaller release rather than a list of fears. Review startup development and the Guestroom case when deciding how to translate those risk controls into delivery work. Explore software development for startups and the Guestroom case study.
Review failure scenarios before committing budget
Start with an AI-assisted project brief covering scope, budget, market assumptions and risks. Review its hypotheses before making a commitment.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.