How to run a pre-mortem before a startup launch

Knowing how to run a pre-mortem starts with one instruction: ask your team to imagine the project has already failed, then have each person write down why. A startup can do this in about an hour before any launch, hire or big commitment. The output is a short list of the most likely reasons for failure, each with an owner, an action and a warning sign to watch.

Psychologist Gary Klein described the method in Harvard Business Review in 2007. His point was that people often keep their doubts to themselves while a plan is being made, and a pre-mortem makes it safe to say them out loud. Asking "why did this fail?" instead of "what might go wrong?" tends to change the answers, because people are no longer defending the plan. They are explaining a story they can picture.

This guide walks through a full session using one invented example, so you can copy the structure for your own project.

What is a pre-mortem and when should a startup run one?

A pre-mortem is a planning meeting held before work starts, in which the team assumes the project failed and lists the reasons. It is the opposite of a post-mortem, which looks back after something has already gone wrong.

Run one when a decision is expensive to undo. Good moments include:

• A product launch with a fixed date, such as moving from free beta to paid plans
• A first sales or marketing hire, where the cost of a wrong fit is months of salary
• A migration of billing, data or infrastructure that customers will notice
• A fundraise, before you commit time to a long investor process
• A partnership or large contract with terms you cannot easily exit

Skip it for small, reversible choices. If you can undo a decision in a day, the hour is better spent shipping and learning. Our guide on setting clear decision rights on small teams is a useful companion for sorting which calls deserve this much attention.

How to run a pre-mortem in one 60-minute meeting

Atlassian's Team Playbook lists its pre-mortem play at about 10 minutes of preparation and a 60-minute run time, for groups of 3 to 11 people. That size fits most early teams. The steps below follow the same shape, adjusted for a startup.

Pick a facilitator

The facilitator keeps time, enforces the silent-writing rule and asks follow-up questions. It should not be the person who owns the project, because that person will be tempted to answer each concern as it comes up. At a small startup, the co-founder who is least involved in the project, or a trusted advisor joining by video, usually works well. The project owner takes part as an equal and writes reasons like everyone else.

Before the meeting (10 minutes)

Write a one-paragraph description of the project: what it is, the date, and what success looks like in numbers. Send it to everyone a day ahead. Set up one shared document or whiteboard with a single prompt at the top: "It is three months after launch and this project failed. Why?"

Set the scene (5 minutes)

Read the project description aloud. State the failure as fact, in the past tense. Remind people that every reason is welcome, including ones about the founders.

Write alone (10 minutes)

Everyone writes reasons silently and on their own. This is the most important rule in the session. If people talk first, the loudest view anchors everyone else.

Share and group (10 minutes)

Go around the room and have each person read one reason at a time until all are on the board. Merge duplicates into groups.

Vote (5 minutes)

Give each person three votes to place on the groups they think are most likely or most damaging. Atlassian's play uses the same three-vote rule and lets people stack votes on one item.

Discuss and assign (20 minutes)

Take the top three groups. Spend about seven minutes on each, agree at least one action, and name an owner and a due date before moving on.

A worked example: a paid-plan launch

Here is how the session might look for Nora, founder of a six-person software company that plans to switch its free beta to paid plans on 1 December. The team, risks and numbers below are examples for illustration, not data from a real company.

After ten minutes of silent writing, the team had 31 reasons. Grouping cut them to nine, and voting picked these as the top concerns:

Notice what each row has. The reason is specific enough that someone can picture it happening. The action is something a person can finish by a date. The warning sign is a number someone can check without a meeting.

The fourth row changed the plan most. Two people had booked holidays for the first week of December, and nobody had connected that to the launch date until it appeared on the board. Nora moved the launch to 8 December the same afternoon, which cost one week and removed a risk nobody had planned to discuss.

The other five groups did not disappear. Nora kept them in the same document under a heading for lower-priority risks, to revisit two weeks before launch.

Weak reasons versus useful reasons

The quality of a pre-mortem depends on how specific the reasons are. Vague answers feel safe to write but give the team nothing to act on. The table compares typical first drafts with sharper versions.

If a reason is weak, the facilitator should ask one follow-up: "What exactly happened, and who noticed first?" That question usually turns a label into a scene.

People also hold back reasons about leadership. Founders can help by writing one reason about themselves and reading it first, for example, "I kept changing the pricing page until the day before launch." It shows that no topic is off limits.

Adapting the method for remote teams and solo founders

Not every team can get everyone into one room for an hour.

For teams across time zones, Atlassian suggests running the play asynchronously: share the document with a deadline, ask people to add reasons and tag items for discussion, and have them sign up for tasks. Keep the silent-writing rule by asking people not to read others' entries until they have added their own.

Solo founders can still run a useful version:

1. Write the failure story yourself, in the past tense, as if explaining it to an investor.
2. List at least ten reasons, including ones about your own habits and time.
3. Send the plan to two people who will be honest, such as an advisor or another founder, and ask each for three reasons it failed.
4. Pick the top three across all lists and give each an action and a date.

The outside view matters most here, because a solo founder has nobody to disagree with in the moment.

Keeping the pre-mortem alive after launch

The document is only useful if someone looks at it again. Put the top risks and their warning signs where the team already works, and check them on a schedule.

A few habits keep it from fading:

• Add every agreed action to the project's task list with its owner and due date, so it gets tracked with the rest of the work.
• Review the warning signs in the weekly team meeting until the launch is over.
• Two weeks after launch, compare what happened with what the team predicted.
• Note which risks came true and which never mattered, so the next session is sharper.

In Nautis, the agreed actions can go onto a Task Board as Outcome tasks with assignees and due dates, and a warning sign that is a number can be tracked as a KPI task, short for key performance indicator, with a target number. The Decision Loop guide describes logging a decision with its key assumptions and expected outcome, then choosing a review date 30, 60 or 90 days out to record what happened. Logging the launch decision there with the pre-mortem's top risks as assumptions gives you a dated record to check against.

Nautis also includes a panel of artificial intelligence (AI) advisors. If you want an outside challenge before the meeting, the AI Advisory Board can be asked to stress-test a plan, as covered in how an AI advisory board stress-tests a decision. Treat its answers as more reasons for the board, not as a replacement for your team's own list.

When the review date comes, read the original reasons aloud before looking at the results. The gap between what people feared and what actually happened is what makes the next pre-mortem faster and more honest.