Pre-mortem
Method to identify failure risks before they happen
Let's go!
💡 WHAT IT IS?
The Pre-Mortem is a structured imagination exercise. Instead of asking "How can we succeed?" — which makes our brains generate optimistic ideas — we ask the opposite question: "Imagine our project has already FAILED one year from now. What caused the failure?" This deliberate inversion of perspective unlocks honest critique that wouldn't surface otherwise. When you imagine failure as a fact rather than a risk, your brain works backwards to construct plausible reasons — and those reasons reveal blind spots you'd never see when defending your project. Think of it like a doctor's autopsy versus a medical checkup. A checkup asks "Are you healthy?" — and patients tend to minimize symptoms. An autopsy asks "What caused the death?" — and produces uncompromising honesty. The Pre-Mortem brings autopsy-level honesty to projects that haven't even started.
Why it matters?
🎯 WHY IT MATTERS
Engineers are particularly vulnerable to a cognitive bias called "planning optimism." When working on a project they believe in, their brains automatically downweight risks and upweight opportunities. This isn't dishonesty — it's how human cognition works. The Pre-Mortem is the structured countermeasure. Three concrete reasons to invest time in imagining failure: 🧠 Reason 1 — It surfaces what politeness hides. In a team meeting, raising concerns can feel like sabotaging the team's enthusiasm. The Pre-Mortem gives everyone permission to voice concerns — because the rules of the game require imagining failure. Concerns become contributions, not betrayals. 🛡️ Reason 2 — It prepares mitigation while it's cheap. A risk identified in week 1 of the project costs hours to address. The same risk identified in week 8 costs weeks. The Pre-Mortem surfaces risks at the cheapest possible moment to fix them. 🎯 Reason 3 — It strengthens your pitch. At Demo Day, the jury will ask "What could go wrong?" Teams that have done a real Pre-Mortem answer with confidence — they've already thought through the risks and built mitigation into their plan. Teams that haven't, fumble.
Start Course ->
Index
How to do it?
Spot the mistake
Example
Test yourself
How to do it? Follow the steps strictly — the silent generation phase is non-negotiable.
STEP 1 — Set the SCENE The facilitator (or one team member) announces clearly: "It's March 2027 — one year from now. Our solution has been deployed and it has FAILED. The project is being discontinued. We are about to write the failure post-mortem." Important: the scene must be stated as a FACT, not a hypothesis. Not "imagine if..." but "this has happened." This grammatical choice changes how the brain processes the exercise. Hypothetical failures invite defense. Stated failures invite explanation. STEP 2 — SILENT GENERATION of failure reasons Each team member silently writes on sticky notes: "Why did our solution fail?" One reason per sticky. Generate as many as possible. Rules during this phase: - Absolute silence — no discussion, no glances, no reactions - Quantity over quality — generate, don't filter - One reason per sticky — don't combine - No idea is "too negative" or "unrealistic" — capture everything The silence is essential. If teammates discuss during generation, group dynamics kick in — early ideas anchor later ones, dominant voices crowd out quiet ones, and the team converges too fast on a narrow set of risks. Silence preserves diversity.
How to do it? Follow the steps strictly — the silent generation phase is non-negotiable.
STEP 3 — CLUSTER the failures by category After 7 minutes, all team members place their stickies on the board. Group them into three columns: - TECHNICAL FAILURES — the solution didn't work as intended (bugs, performance issues, integration breaks, data quality issues) - HUMAN FAILURES — users didn't adopt or misused it (resistance, low engagement, workarounds emerging, trust issues) - BUSINESS FAILURES — the value didn't materialize (cost overruns, missing KPIs, deprioritization, market shift) Most teams generate stickies disproportionately in one category. The imbalance itself is informative — it reveals where the team's mental energy goes (and where their blind spots live).
How to do it? Follow the steps strictly — the silent generation phase is non-negotiable.
STEP 4 — IDENTIFY the top 3 risks Discuss as a team: which 2-3 failure modes are MOST LIKELY to actually occur? Vote with dots if needed. The selected risks become the blind spots you'll address in subsequent exercises. Don't aim for exhaustivity — aim for clarity on your worst 2-3 risks. STEP 5 — ANTICIPATE mitigation (5 min) For each of the top risks, write 1-2 sentences on how you'd mitigate it. Not solve it perfectly — just begin to anticipate it. This step turns the Pre-Mortem from a worry exercise into an action-oriented one. The output is risks PLUS first-draft mitigation strategies.
Example ->
Example: A team is working on Signal Scout, an AI-powered cross-platform document search system for engineers.
Risk #1: "Engineers don't trust AI suggestions — verify everything manually" Why selected: appeared on 3 different stickies (high signal), and if it happens, it kills value capture even if technical execution is perfect.
For Risk #1: Build a "confidence indicator" into AI suggestions, showing the AI's certainty level. Engineers learn to trust high-confidence suggestions while still verifying lower-confidence ones — earning trust gradually rather than demanding blind trust.
Risk #2: "Inconsistent metadata across legacy systems to learn from" Why selected: technical foundation issue — if true, no amount of UX polish will compensate. Discovered to be checkable in Station 3 with the Data Listing activity.
TECHNICAL FAILURES : - Search results too slow (>3 seconds, users abandon) - Indexing breaks when source systems update - AI suggestions are wrong 15% of the time, users lose trust - Metadata too inconsistent across legacy systems to learn from - Integration with SharePoint v2019 breaks on next upgrade - Mobile version never delivered (only desktop works) - Multilingual support insufficient (only French documents indexed properly)
HUMAN FAILURES: - Engineers don't trust AI suggestions — verify everything manually - Adoption stays at 15% — only early adopters use it - Senior engineers feel threatened by automation - Junior engineers love it but their seniors discourage usage - Training is too long (45 min) — engineers skip it and never learn features - Document owners feel exposed by transparent search - Union concerns over "tracking what engineers search"
For Risk #2: Before hackathon, audit metadata quality on a sample of 100 documents from each source system. If consistency is below 70%, pivot scope to a metadata-cleanup-first approach rather than direct AI search.
BUSINESS FAILURES: - Setup cost exceeded estimate by 3x (350k€ instead of 120k€) - No clear KPI to prove time saved — leadership loses interest - Other priorities pushed it down the roadmap - Sponsor leaves SYSTRA mid-project — project loses internal champion - Data Privacy Officer rejects user behavior tracking - Procurement renegotiation of cloud contract delays infrastructure - Competing internal initiative emerges and absorbs budget
What this example teaches
Example: A team is working on Signal Scout, an AI-powered cross-platform document search system for engineers.
📝 What this example teaches: Notice that the team's ideas cluster 9-7-7 across the three categories — not too imbalanced. The two risks selected are NOT the most dramatic ones (no apocalypse scenarios) but the most LIKELY ones. The mitigation drafts are concrete enough to act on, not just acknowledgments.
Risk #1: "Engineers don't trust AI suggestions — verify everything manually" Why selected: appeared on 3 different stickies (high signal), and if it happens, it kills value capture even if technical execution is perfect.
For Risk #1: Build a "confidence indicator" into AI suggestions, showing the AI's certainty level. Engineers learn to trust high-confidence suggestions while still verifying lower-confidence ones — earning trust gradually rather than demanding blind trust.
Risk #2: "Inconsistent metadata across legacy systems to learn from" Why selected: technical foundation issue — if true, no amount of UX polish will compensate. Discovered to be checkable in Station 3 with the Data Listing activity.
TECHNICAL FAILURES : - Search results too slow (>3 seconds, users abandon) - Indexing breaks when source systems update - AI suggestions are wrong 15% of the time, users lose trust - Metadata too inconsistent across legacy systems to learn from - Integration with SharePoint v2019 breaks on next upgrade - Mobile version never delivered (only desktop works) - Multilingual support insufficient (only French documents indexed properly)
HUMAN FAILURES: - Engineers don't trust AI suggestions — verify everything manually - Adoption stays at 15% — only early adopters use it - Senior engineers feel threatened by automation - Junior engineers love it but their seniors discourage usage - Training is too long (45 min) — engineers skip it and never learn features - Document owners feel exposed by transparent search - Union concerns over "tracking what engineers search"
For Risk #2: Before hackathon, audit metadata quality on a sample of 100 documents from each source system. If consistency is below 70%, pivot scope to a metadata-cleanup-first approach rather than direct AI search.
BUSINESS FAILURES: - Setup cost exceeded estimate by 3x (350k€ instead of 120k€) - No clear KPI to prove time saved — leadership loses interest - Other priorities pushed it down the roadmap - Sponsor leaves SYSTRA mid-project — project loses internal champion - Data Privacy Officer rejects user behavior tracking - Procurement renegotiation of cloud contract delays infrastructure - Competing internal initiative emerges and absorbs budget
Spot the mistake
🔍 SPOT THE MISTAKE —Pre-mortem
Find the 3 errors in this Pre-mortem. Click on each error to identify it. CONTEXT — A team ran a Pre-Mortem on a new project. They made three classic mistakes that compromised the exercise's value. Find them.
1. "What if our project might possibly not succeed as expected, in a hypothetical scenario?"
The team gathered around the board and started discussing reasons out loud as they wrote stickies.
CLUSTERED FAILURES (23 total): - TECHNICAL: 19 stickies - HUMAN: 2 stickies
- BUSINESS: 2 stickies
Mistakes found ->
🔍 SPOT THE MISTAKE — Pre-mortem
🎉 EXCELLENT! You spotted all 3 mistakes. You've now learned the 3 most common Pre-Mortem pitfalls: ✓ Pitfall 1: Hypothetical scene phrasing (the 'maybe it might fail' trap) ✓ Pitfall 2: Discussion during silent generation (the anchoring trap) ✓ Pitfall 3: Ignoring category imbalance (the blind spot signal) A Pre-Mortem that avoids these three pitfalls will surface 3-5x more honest insights than one that doesn't. The cost of doing it right is the same as doing it wrong — but the value differs by an order of magnitude.
Test yourself ->
TEST YOURSELF — Pre-mortem 3 questions to validate your understanding. No grade — just learning signal. 1/3
TEST YOURSELF — Pre-mortem 3 questions to validate your understanding. No grade — just learning signal. 2/3
TEST YOURSELF — Pre-mortem 3 questions to validate your understanding. No grade — just learning signal. 3/3
End of the course
You've mastered the logic of the Pre-mortem
✓ You know the right moment to run it✓ You understand why silent generation is non-negotiable ✓You can read clustering imbalance as diagnostic information
✅ CORRECT!
🧠 Why this works The Pre-Mortem is most valuable at the moment when you have a concept but haven't yet committed major resources to building it. At this point: - You can still pivot the concept based on identified risks - Mitigation strategies cost hours to design, not weeks - The team is engaged enough to take it seriously, but not so committed that they can't hear bad news
📐 The principle Pre-Mortem timing matters. Too early (no concept yet) = nothing concrete to fail. Too late (already building) = too expensive to fix. 💡 The sweet spot Right after you've selected your concept (end of ideation), and right before you commit to detailed design or hackathon execution. That's when the Pre-Mortem unlocks the most value.
WRONG
❌ "After the project failed — to learn from mistakes" 🧠 What happened here? What you're describing is a post-mortem (after-failure analysis), not a Pre-Mortem. Post-mortems are valuable for learning from past projects, but they don't help the current project succeed. 📐 The principle The 'Pre' in Pre-Mortem means BEFORE failure. The exercise is preventive, not reactive. Its value lies in surfacing risks while they're still cheap to address. 💡 Try again.
❌ "When you have a concept but haven't built it yet" 🧠 What happened here? Running a Pre-Mortem at the end of the hackathon is too late. By that point, you've already built the solution — you can't easily address structural risks. The Pre-Mortem becomes a stress-inducing exercise rather than a value-creating one. 📐 The principle Pre-Mortem timing is about catching risks while they're still cheap to address. End-of-hackathon is the most expensive moment to discover them. 💡 Try again.
❌ "Never — it's too pessimistic for an innovation context" 🧠 What happened here? The Pre-Mortem isn't pessimistic — it's preventive. Calling preventive analysis 'too pessimistic' is like calling a fire alarm 'too anxious.' The exercise is uncomfortable for 20 minutes precisely so the project can be successful for 12+ months. 📐 The principle Realistic risk anticipation is the opposite of pessimism — it's the foundation of mature optimism. Pessimism says 'this will fail.' Pre-Mortem says 'this might fail in specific ways, and here's how we prevent them.' 💡 Try again.
❌ WRONG
❌"Discuss freely with neighbors — collaboration helps" 🧠 What happened here? Discussion during generation creates anchoring. The first ideas spoken become reference points that unconsciously shape everyone else's thinking. The result is convergent rather than divergent generation — exactly what the Pre-Mortem is trying to avoid. 📐 The principle Silence preserves diversity. Diversity produces breadth. Breadth surfaces blind spots that focused discussion would miss. 💡 Try again.
❌ "Only write technical failures" 🧠 What happened here? Restricting generation to technical failures imposes a category bias from the start. The team will end up with a long list of technical risks and zero awareness of human or business risks — the very pattern the exercise is designed to break. 📐 The principle Generate broadly across ALL categories during silent phase. Categorize AFTER. The categorization happens during clustering, not during generation. 💡 Try again.
❌ "Vote on most likely failures in real-time" 🧠 What happened here? Voting in real-time during generation interrupts the flow. The whole point of silent generation is uninterrupted divergent thinking. Voting comes later, after clustering. 📐 The principle Each phase has its purpose. Generation = breadth. Clustering = structure. Voting = focus. Mixing them dilutes each. 💡 Try again.
❌ WRONG
❌ "Trust the data — clearly this is a technical project with mostly technical risks" 🧠 What happened here? Trusting a 19-2-2 distribution is dangerous. The imbalance is more likely to reveal the team's BLIND SPOT than the project's actual risk profile. Most innovation projects fail for human and business reasons, not technical ones — so this imbalance is the opposite of what real failure patterns look like. 📐 The principle Strong imbalance in clustering is diagnostic information. It reveals where the team's mental energy goes — and where their blind spots are. 💡 Try again.
❌ "Move on with the top 2 risks regardless" 🧠 What happened here? Moving on with the top 2 risks from a 19-2-2 distribution means selecting the top 2 from the 19 technical risks — and completely ignoring the (likely much more dangerous) human and business risks the team didn't generate. 📐 The principle The selection of top risks must come from a balanced analysis, not a skewed one. If the analysis is skewed, fix it before selecting. 💡 Try again.
❌ "Restart the entire Pre-Mortem from scratch" 🧠 What happened here? Restarting the entire Pre-Mortem is overkill. The 19 technical risks are valuable data — you don't want to lose them. You just need to complete the analysis by adding focused work on the missing categories. 📐 The principle Build on what you have. Iterate rather than restart. 💡 Try again.
✅ CORRECT!
🧠 Why this works A focused second-round generation on the underrepresented categories rebalances the analysis. The team is now consciously hunting for what they unconsciously missed. The result is usually 5-10 additional risks in human and business categories. 💡 The technique Announce explicitly: 'For the next 4 minutes, we're generating ONLY human failures. What adoption, trust, training, or resistance issues could occur? Silent generation.' Then repeat for business risks.
📐 The principle The Pre-Mortem is iterative if needed. The first round surfaces the team's natural risk landscape. Subsequent focused rounds correct for blind spots.
✅ CORRECT!
🧠 Why this works Silent generation has three critical functions: 1. It prevents anchoring (no one's ideas pollute others) 2. It protects quiet team members (introverts contribute as much as extroverts) 3. It maximizes diversity (people pursue different angles in parallel) One reason per sticky enables later clustering. Combining 3 reasons on one sticky breaks the analysis because the cluster can only be in one place.
📐 The principle Discipline of form (silence + one-per-sticky) enables freedom of content (diverse, honest, uninfluenced ideas). 💡 The non-negotiable Some team members will resist the silence — especially extroverts who think out loud. Resist their resistance. The 7 minutes of silence are non-negotiable. The exercise's value depends on them.
Pre-mortem
Diane Sales
Created on May 18, 2026
Start designing with a free template
Discover more than 1500 professional designs like these:
View
Customer Service Course
View
Dynamic Visual Course
View
Dynamic Learning Course
View
Akihabara Course
Explore all templates
Transcript
Pre-mortem
Method to identify failure risks before they happen
Let's go!
💡 WHAT IT IS?
The Pre-Mortem is a structured imagination exercise. Instead of asking "How can we succeed?" — which makes our brains generate optimistic ideas — we ask the opposite question: "Imagine our project has already FAILED one year from now. What caused the failure?" This deliberate inversion of perspective unlocks honest critique that wouldn't surface otherwise. When you imagine failure as a fact rather than a risk, your brain works backwards to construct plausible reasons — and those reasons reveal blind spots you'd never see when defending your project. Think of it like a doctor's autopsy versus a medical checkup. A checkup asks "Are you healthy?" — and patients tend to minimize symptoms. An autopsy asks "What caused the death?" — and produces uncompromising honesty. The Pre-Mortem brings autopsy-level honesty to projects that haven't even started.
Why it matters?
🎯 WHY IT MATTERS
Engineers are particularly vulnerable to a cognitive bias called "planning optimism." When working on a project they believe in, their brains automatically downweight risks and upweight opportunities. This isn't dishonesty — it's how human cognition works. The Pre-Mortem is the structured countermeasure. Three concrete reasons to invest time in imagining failure: 🧠 Reason 1 — It surfaces what politeness hides. In a team meeting, raising concerns can feel like sabotaging the team's enthusiasm. The Pre-Mortem gives everyone permission to voice concerns — because the rules of the game require imagining failure. Concerns become contributions, not betrayals. 🛡️ Reason 2 — It prepares mitigation while it's cheap. A risk identified in week 1 of the project costs hours to address. The same risk identified in week 8 costs weeks. The Pre-Mortem surfaces risks at the cheapest possible moment to fix them. 🎯 Reason 3 — It strengthens your pitch. At Demo Day, the jury will ask "What could go wrong?" Teams that have done a real Pre-Mortem answer with confidence — they've already thought through the risks and built mitigation into their plan. Teams that haven't, fumble.
Start Course ->
Index
How to do it?
Spot the mistake
Example
Test yourself
How to do it? Follow the steps strictly — the silent generation phase is non-negotiable.
STEP 1 — Set the SCENE The facilitator (or one team member) announces clearly: "It's March 2027 — one year from now. Our solution has been deployed and it has FAILED. The project is being discontinued. We are about to write the failure post-mortem." Important: the scene must be stated as a FACT, not a hypothesis. Not "imagine if..." but "this has happened." This grammatical choice changes how the brain processes the exercise. Hypothetical failures invite defense. Stated failures invite explanation. STEP 2 — SILENT GENERATION of failure reasons Each team member silently writes on sticky notes: "Why did our solution fail?" One reason per sticky. Generate as many as possible. Rules during this phase: - Absolute silence — no discussion, no glances, no reactions - Quantity over quality — generate, don't filter - One reason per sticky — don't combine - No idea is "too negative" or "unrealistic" — capture everything The silence is essential. If teammates discuss during generation, group dynamics kick in — early ideas anchor later ones, dominant voices crowd out quiet ones, and the team converges too fast on a narrow set of risks. Silence preserves diversity.
How to do it? Follow the steps strictly — the silent generation phase is non-negotiable.
STEP 3 — CLUSTER the failures by category After 7 minutes, all team members place their stickies on the board. Group them into three columns: - TECHNICAL FAILURES — the solution didn't work as intended (bugs, performance issues, integration breaks, data quality issues) - HUMAN FAILURES — users didn't adopt or misused it (resistance, low engagement, workarounds emerging, trust issues) - BUSINESS FAILURES — the value didn't materialize (cost overruns, missing KPIs, deprioritization, market shift) Most teams generate stickies disproportionately in one category. The imbalance itself is informative — it reveals where the team's mental energy goes (and where their blind spots live).
How to do it? Follow the steps strictly — the silent generation phase is non-negotiable.
STEP 4 — IDENTIFY the top 3 risks Discuss as a team: which 2-3 failure modes are MOST LIKELY to actually occur? Vote with dots if needed. The selected risks become the blind spots you'll address in subsequent exercises. Don't aim for exhaustivity — aim for clarity on your worst 2-3 risks. STEP 5 — ANTICIPATE mitigation (5 min) For each of the top risks, write 1-2 sentences on how you'd mitigate it. Not solve it perfectly — just begin to anticipate it. This step turns the Pre-Mortem from a worry exercise into an action-oriented one. The output is risks PLUS first-draft mitigation strategies.
Example ->
Example: A team is working on Signal Scout, an AI-powered cross-platform document search system for engineers.
Risk #1: "Engineers don't trust AI suggestions — verify everything manually" Why selected: appeared on 3 different stickies (high signal), and if it happens, it kills value capture even if technical execution is perfect.
For Risk #1: Build a "confidence indicator" into AI suggestions, showing the AI's certainty level. Engineers learn to trust high-confidence suggestions while still verifying lower-confidence ones — earning trust gradually rather than demanding blind trust.
Risk #2: "Inconsistent metadata across legacy systems to learn from" Why selected: technical foundation issue — if true, no amount of UX polish will compensate. Discovered to be checkable in Station 3 with the Data Listing activity.
TECHNICAL FAILURES : - Search results too slow (>3 seconds, users abandon) - Indexing breaks when source systems update - AI suggestions are wrong 15% of the time, users lose trust - Metadata too inconsistent across legacy systems to learn from - Integration with SharePoint v2019 breaks on next upgrade - Mobile version never delivered (only desktop works) - Multilingual support insufficient (only French documents indexed properly)
HUMAN FAILURES: - Engineers don't trust AI suggestions — verify everything manually - Adoption stays at 15% — only early adopters use it - Senior engineers feel threatened by automation - Junior engineers love it but their seniors discourage usage - Training is too long (45 min) — engineers skip it and never learn features - Document owners feel exposed by transparent search - Union concerns over "tracking what engineers search"
For Risk #2: Before hackathon, audit metadata quality on a sample of 100 documents from each source system. If consistency is below 70%, pivot scope to a metadata-cleanup-first approach rather than direct AI search.
BUSINESS FAILURES: - Setup cost exceeded estimate by 3x (350k€ instead of 120k€) - No clear KPI to prove time saved — leadership loses interest - Other priorities pushed it down the roadmap - Sponsor leaves SYSTRA mid-project — project loses internal champion - Data Privacy Officer rejects user behavior tracking - Procurement renegotiation of cloud contract delays infrastructure - Competing internal initiative emerges and absorbs budget
What this example teaches
Example: A team is working on Signal Scout, an AI-powered cross-platform document search system for engineers.
📝 What this example teaches: Notice that the team's ideas cluster 9-7-7 across the three categories — not too imbalanced. The two risks selected are NOT the most dramatic ones (no apocalypse scenarios) but the most LIKELY ones. The mitigation drafts are concrete enough to act on, not just acknowledgments.
Risk #1: "Engineers don't trust AI suggestions — verify everything manually" Why selected: appeared on 3 different stickies (high signal), and if it happens, it kills value capture even if technical execution is perfect.
For Risk #1: Build a "confidence indicator" into AI suggestions, showing the AI's certainty level. Engineers learn to trust high-confidence suggestions while still verifying lower-confidence ones — earning trust gradually rather than demanding blind trust.
Risk #2: "Inconsistent metadata across legacy systems to learn from" Why selected: technical foundation issue — if true, no amount of UX polish will compensate. Discovered to be checkable in Station 3 with the Data Listing activity.
TECHNICAL FAILURES : - Search results too slow (>3 seconds, users abandon) - Indexing breaks when source systems update - AI suggestions are wrong 15% of the time, users lose trust - Metadata too inconsistent across legacy systems to learn from - Integration with SharePoint v2019 breaks on next upgrade - Mobile version never delivered (only desktop works) - Multilingual support insufficient (only French documents indexed properly)
HUMAN FAILURES: - Engineers don't trust AI suggestions — verify everything manually - Adoption stays at 15% — only early adopters use it - Senior engineers feel threatened by automation - Junior engineers love it but their seniors discourage usage - Training is too long (45 min) — engineers skip it and never learn features - Document owners feel exposed by transparent search - Union concerns over "tracking what engineers search"
For Risk #2: Before hackathon, audit metadata quality on a sample of 100 documents from each source system. If consistency is below 70%, pivot scope to a metadata-cleanup-first approach rather than direct AI search.
BUSINESS FAILURES: - Setup cost exceeded estimate by 3x (350k€ instead of 120k€) - No clear KPI to prove time saved — leadership loses interest - Other priorities pushed it down the roadmap - Sponsor leaves SYSTRA mid-project — project loses internal champion - Data Privacy Officer rejects user behavior tracking - Procurement renegotiation of cloud contract delays infrastructure - Competing internal initiative emerges and absorbs budget
Spot the mistake
🔍 SPOT THE MISTAKE —Pre-mortem
Find the 3 errors in this Pre-mortem. Click on each error to identify it. CONTEXT — A team ran a Pre-Mortem on a new project. They made three classic mistakes that compromised the exercise's value. Find them.
1. "What if our project might possibly not succeed as expected, in a hypothetical scenario?"
The team gathered around the board and started discussing reasons out loud as they wrote stickies.
CLUSTERED FAILURES (23 total): - TECHNICAL: 19 stickies - HUMAN: 2 stickies
- BUSINESS: 2 stickies
Mistakes found ->
🔍 SPOT THE MISTAKE — Pre-mortem
🎉 EXCELLENT! You spotted all 3 mistakes. You've now learned the 3 most common Pre-Mortem pitfalls: ✓ Pitfall 1: Hypothetical scene phrasing (the 'maybe it might fail' trap) ✓ Pitfall 2: Discussion during silent generation (the anchoring trap) ✓ Pitfall 3: Ignoring category imbalance (the blind spot signal) A Pre-Mortem that avoids these three pitfalls will surface 3-5x more honest insights than one that doesn't. The cost of doing it right is the same as doing it wrong — but the value differs by an order of magnitude.
Test yourself ->
TEST YOURSELF — Pre-mortem 3 questions to validate your understanding. No grade — just learning signal. 1/3
TEST YOURSELF — Pre-mortem 3 questions to validate your understanding. No grade — just learning signal. 2/3
TEST YOURSELF — Pre-mortem 3 questions to validate your understanding. No grade — just learning signal. 3/3
End of the course
You've mastered the logic of the Pre-mortem
✓ You know the right moment to run it✓ You understand why silent generation is non-negotiable ✓You can read clustering imbalance as diagnostic information
✅ CORRECT!
🧠 Why this works The Pre-Mortem is most valuable at the moment when you have a concept but haven't yet committed major resources to building it. At this point: - You can still pivot the concept based on identified risks - Mitigation strategies cost hours to design, not weeks - The team is engaged enough to take it seriously, but not so committed that they can't hear bad news
📐 The principle Pre-Mortem timing matters. Too early (no concept yet) = nothing concrete to fail. Too late (already building) = too expensive to fix. 💡 The sweet spot Right after you've selected your concept (end of ideation), and right before you commit to detailed design or hackathon execution. That's when the Pre-Mortem unlocks the most value.
WRONG
❌ "After the project failed — to learn from mistakes" 🧠 What happened here? What you're describing is a post-mortem (after-failure analysis), not a Pre-Mortem. Post-mortems are valuable for learning from past projects, but they don't help the current project succeed. 📐 The principle The 'Pre' in Pre-Mortem means BEFORE failure. The exercise is preventive, not reactive. Its value lies in surfacing risks while they're still cheap to address. 💡 Try again.
❌ "When you have a concept but haven't built it yet" 🧠 What happened here? Running a Pre-Mortem at the end of the hackathon is too late. By that point, you've already built the solution — you can't easily address structural risks. The Pre-Mortem becomes a stress-inducing exercise rather than a value-creating one. 📐 The principle Pre-Mortem timing is about catching risks while they're still cheap to address. End-of-hackathon is the most expensive moment to discover them. 💡 Try again.
❌ "Never — it's too pessimistic for an innovation context" 🧠 What happened here? The Pre-Mortem isn't pessimistic — it's preventive. Calling preventive analysis 'too pessimistic' is like calling a fire alarm 'too anxious.' The exercise is uncomfortable for 20 minutes precisely so the project can be successful for 12+ months. 📐 The principle Realistic risk anticipation is the opposite of pessimism — it's the foundation of mature optimism. Pessimism says 'this will fail.' Pre-Mortem says 'this might fail in specific ways, and here's how we prevent them.' 💡 Try again.
❌ WRONG
❌"Discuss freely with neighbors — collaboration helps" 🧠 What happened here? Discussion during generation creates anchoring. The first ideas spoken become reference points that unconsciously shape everyone else's thinking. The result is convergent rather than divergent generation — exactly what the Pre-Mortem is trying to avoid. 📐 The principle Silence preserves diversity. Diversity produces breadth. Breadth surfaces blind spots that focused discussion would miss. 💡 Try again.
❌ "Only write technical failures" 🧠 What happened here? Restricting generation to technical failures imposes a category bias from the start. The team will end up with a long list of technical risks and zero awareness of human or business risks — the very pattern the exercise is designed to break. 📐 The principle Generate broadly across ALL categories during silent phase. Categorize AFTER. The categorization happens during clustering, not during generation. 💡 Try again.
❌ "Vote on most likely failures in real-time" 🧠 What happened here? Voting in real-time during generation interrupts the flow. The whole point of silent generation is uninterrupted divergent thinking. Voting comes later, after clustering. 📐 The principle Each phase has its purpose. Generation = breadth. Clustering = structure. Voting = focus. Mixing them dilutes each. 💡 Try again.
❌ WRONG
❌ "Trust the data — clearly this is a technical project with mostly technical risks" 🧠 What happened here? Trusting a 19-2-2 distribution is dangerous. The imbalance is more likely to reveal the team's BLIND SPOT than the project's actual risk profile. Most innovation projects fail for human and business reasons, not technical ones — so this imbalance is the opposite of what real failure patterns look like. 📐 The principle Strong imbalance in clustering is diagnostic information. It reveals where the team's mental energy goes — and where their blind spots are. 💡 Try again.
❌ "Move on with the top 2 risks regardless" 🧠 What happened here? Moving on with the top 2 risks from a 19-2-2 distribution means selecting the top 2 from the 19 technical risks — and completely ignoring the (likely much more dangerous) human and business risks the team didn't generate. 📐 The principle The selection of top risks must come from a balanced analysis, not a skewed one. If the analysis is skewed, fix it before selecting. 💡 Try again.
❌ "Restart the entire Pre-Mortem from scratch" 🧠 What happened here? Restarting the entire Pre-Mortem is overkill. The 19 technical risks are valuable data — you don't want to lose them. You just need to complete the analysis by adding focused work on the missing categories. 📐 The principle Build on what you have. Iterate rather than restart. 💡 Try again.
✅ CORRECT!
🧠 Why this works A focused second-round generation on the underrepresented categories rebalances the analysis. The team is now consciously hunting for what they unconsciously missed. The result is usually 5-10 additional risks in human and business categories. 💡 The technique Announce explicitly: 'For the next 4 minutes, we're generating ONLY human failures. What adoption, trust, training, or resistance issues could occur? Silent generation.' Then repeat for business risks.
📐 The principle The Pre-Mortem is iterative if needed. The first round surfaces the team's natural risk landscape. Subsequent focused rounds correct for blind spots.
✅ CORRECT!
🧠 Why this works Silent generation has three critical functions: 1. It prevents anchoring (no one's ideas pollute others) 2. It protects quiet team members (introverts contribute as much as extroverts) 3. It maximizes diversity (people pursue different angles in parallel) One reason per sticky enables later clustering. Combining 3 reasons on one sticky breaks the analysis because the cluster can only be in one place.
📐 The principle Discipline of form (silence + one-per-sticky) enables freedom of content (diverse, honest, uninfluenced ideas). 💡 The non-negotiable Some team members will resist the silence — especially extroverts who think out loud. Resist their resistance. The 7 minutes of silence are non-negotiable. The exercise's value depends on them.