How to Run a Pre-Mortem Meeting With a Free Template

A pre-mortem is a structured meeting where your team imagines a plan has already failed, then works backward to identify why. Run one before any significant launch, project kickoff, or strategic decision and you will surface the risks your optimism is hiding. This guide gives you a step-by-step facilitation process and a ready-to-use template you can run in under 60 minutes.

Why most teams skip the pre-mortem (and regret it)

Post-mortems are standard practice. You ship, something breaks, you hold a retrospective. By then the damage is done: a missed launch window, a burned budget, a lost customer.

The pre-mortem flips the sequence. Before you execute, you spend 45 to 60 minutes pretending you already failed. It's a technique Gary Klein formalized in the 1990s and it works because it overcomes a specific cognitive trap. Once a team has committed to a plan, individuals suppress doubts to avoid seeming disloyal or negative. The pre-mortem gives everyone explicit permission to voice those doubts.

Studies on prospective hindsight suggest this framing can surface roughly 30% more distinct failure causes than standard risk brainstorming, simply because "why did this fail?" pulls harder on memory and imagination than "what might go wrong?"

When to run a pre-mortem

Run one for any initiative that meets at least two of these criteria:

• Significant resources at stake. You are committing budget over $10,000, or more than two weeks of team time.
• Low reversibility. Once you go, it is hard to pull back: a product launch, a key hire, a vendor contract.
• Cross-functional dependencies. Multiple teams or stakeholders have to execute together.
• New territory. Your team has not done this specific type of work before.

Do not run a pre-mortem on every tactical decision. It is a tool for high-stakes planning, not a replacement for judgment on routine calls. If you want a framework for those everyday decisions, How to Make Better Decisions Under Uncertainty covers the broader toolkit.

How to run a pre-mortem: step-by-step

You need: a facilitator (usually the project lead or a neutral team member), four to eight participants who know the plan, 45 to 60 minutes, and a shared document or whiteboard.

Step 1: Set the frame (5 minutes)

Open by stating the plan clearly: one sentence on what you are doing, the timeline, and the success criteria. Then deliver the premise:

"Imagine it is [date six months from now]. The project failed. Not a little, not 'we could have done better.' It actually failed in a way that hurt the business. We are here to figure out why."

Do not soften it. "Imagine we had some challenges" invites lukewarm answers. "It failed badly" activates genuine concern.

Step 2: Silent individual generation (10 minutes)

Every participant writes their own list of failure causes, individually and silently. This is the most important step. Group discussion before individual writing lets louder voices anchor the whole team on a narrow set of risks.

Ask each person to write at least five specific reasons the project could fail. Encourage specificity: "we ran out of cash" is less useful than "we underestimated implementation costs by 40% and hit a cash-flow gap in month three."

Step 3: Round-robin sharing (15 to 20 minutes)

Go around the room or the video call. Each person reads one item. Rotate until all items are on the shared board. No debate yet, only clarifying questions. Duplicates are fine to note, but still record them because frequency signals importance.

If someone says "poor communication," push for specificity. "Poor communication between whom, about what?" gets you to "the engineering lead did not know the sales team had already promised the feature for Q3," which is actually actionable.

Step 4: Cluster and vote (10 minutes)

Group similar risks into themes. Common themes include:

• Scope and timeline assumptions
• Resource and budget gaps
• Dependency and coordination failures
• Market or customer assumptions
• Technical unknowns

Ask each participant to place three votes on the risks they consider most likely or most catastrophic. Use dot stickers on a physical board or a simple "+1" in a shared doc. The clusters with the most votes become your watch list.

Step 5: Build mitigations for the top risks (10 to 15 minutes)

For the top three to five risks, assign an owner and a mitigation action. A risk without a mitigation is just a worry. A risk with an owner and a next step becomes a plan element.

Step 6: Close and assign (5 minutes)

Summarize the three to five prioritized risks and their owners. Schedule the first check-in date. Add the risk list to your project plan as a standing agenda item so it does not disappear into a document no one reopens.

This last step connects to your broader execution discipline. If your team has not formalized how it tracks follow-through on decisions, How to Build an Execution Plan That Teams Actually Follow is a natural companion read.

Pre-mortem meeting template

Copy this into a shared doc before your session and fill in the bracketed sections.

---

Project name: [Name] Date of meeting: [Date] Facilitator: [Name] Participants: [Names and roles] Plan summary: [One paragraph: what you are doing, key milestones, success criteria] Failure scenario: Imagine it is [6 months from today]. The project has failed. Describe the failure in one sentence.

---

Individual brainstorm (silent, 10 min) Each person lists 5+ specific reasons the project could fail. Be concrete.

---

Shared risk board (facilitator records during round-robin)

---

Top risks after voting

---

Next check-in date: [Date] Where this document lives: [Link to project plan or shared folder]

---

Worked example: SaaS company launching a new pricing tier

A 12-person B2B SaaS team ran a pre-mortem before launching a new "Enterprise" pricing tier at $2,400 per year, up from their existing $600 Pro tier. The launch was six weeks out. Success criteria: five paid enterprise customers in 90 days.

During the silent brainstorm, participants surfaced 34 distinct failure reasons. After clustering, five themes dominated:

1. Sales process mismatch. The team had no inside sales motion; everyone assumed the CEO would close deals personally, but she had two other major commitments that quarter.
2. Feature gap. Three prospects had already asked for SSO and role-based permissions, neither of which was built yet.
3. Pricing anchoring. The jump from $600 to $2,400 was 4x. No one had tested whether that felt defensible to the target buyer.
4. Legal friction. Enterprise buyers typically require an MSA review. The company had no standard MSA template.
5. Marketing assumption. The landing page still positioned the product as a small-team tool.

By vote, risks one, two, and four ranked highest. The team assigned owners: the CEO delegated two enterprise prospects to a part-time sales consultant, scoped SSO as a four-week sprint, and had the company's lawyer draft a standard MSA template in week one.

Result: the 90-day goal took 110 days instead of 90, but the team closed four of the five target customers. Without the pre-mortem, the launch would likely have stalled and been quietly buried.

The most common pre-mortem mistake and how to avoid it

The mistake: skipping the silent individual brainstorm.

Most facilitators, under time pressure, jump straight to group discussion. This feels efficient but produces worse results. The first person to speak sets an anchor. Everyone else responds to that anchor rather than generating independently. You end up with five variations on one person's concern instead of 25 different failure modes.

The fix is strict: give people 10 minutes to write before anyone speaks. If you are running remotely, use a shared doc where everyone types simultaneously but cannot see each other's entries until the timer ends. The small time cost pays back immediately when the round-robin reveals risks no one had considered.

A related problem is "failure inflation": people list only dramatic, low-probability catastrophes because the exercise feels hypothetical. Counter it by prompting your team with: "What is a boring but plausible way this fails? What is the most likely failure, not the most dramatic?" That shifts the output from "a global recession hits" to "our biggest champion at the client leaves in week four and their replacement does not know us." The second one is what actually happens.

This kind of thinking, examining what is most plausible given what you already know, is explored further in Second-Order Thinking for Better Business Decisions.

Pre-mortem vs. risk register

Teams that already maintain a formal risk register sometimes wonder if a pre-mortem is redundant. It is not.

A pre-mortem surfaces what you do not know you do not know. A risk register tracks what you have already identified. Use both on significant projects.

Pre-mortems also fit naturally into a quarterly planning cycle. If you are structuring one, How to Run a Quarterly Planning Process for Small Teams explains where a pre-mortem slots into the broader rhythm.

Key takeaways

• A pre-mortem works by reversing the planning question: instead of "what could go wrong?" you ask "it already went wrong, why?" That shift bypasses the optimism bias that standard risk reviews reinforce.
• The silent individual brainstorm is the highest-leverage step. Skip it and you get anchored groupthink; keep it and you surface three to five times more distinct failure modes.
• Four to eight participants is the right room size. Fewer than four loses perspective diversity; more than eight makes the round-robin too slow to stay useful.
• The meeting only delivers value if it ends with named owners and written mitigations. A list of fears without actions is just a structured way to feel anxious.
• Run a pre-mortem when stakes are high and reversibility is low. For routine decisions it is overkill; for launches, key hires, and major vendor commitments it is one of the highest-ROI hours your team can spend.
• Keep the output document alive: add the top risks to your project plan and review them at your first team check-in after the session.