<!-- AUTO-GENERATED by export-plugins.py — DO NOT EDIT -->

---

name: pre-mortem description: Structured risk analysis that imagines launch failure and works backward to identify threats. Use when preparing for a product launch, major release, or any high-stakes initiative. tags: [risk, launch, planning, product-management]

Pre-Mortem

A structured risk identification technique: imagine the product has already failed, then work backward to identify what went wrong — before it actually does.

---

Purpose

Traditional risk planning asks "what could go wrong?" which triggers optimism bias. Pre-mortems flip the frame: "It failed. Why?" — which activates prospective hindsight and surfaces risks people are reluctant to raise.

---

When to Use

• 2–4 weeks before a product launch or major release
• Before committing significant resources to a new initiative
• After completing a PRD or architecture review, before sprint execution
• When the team feels overconfident about a plan

When NOT to Use

• During ideation or brainstorming (too early, kills momentum)
• After launch (use a retrospective instead)
• For minor changes or bug fixes

---

Required Inputs

Read and reference the following (if available):

• PRD or product spec
• Launch plan or release checklist
• Architecture or technical design
• Go-to-market plan
• Stakeholder expectations

---

The Process

Step 1: Set the Scene

Start with this prompt to the team (or yourself):

"Imagine it's 6 months from now. This initiative has failed spectacularly. Customers are unhappy, metrics haven't moved, and leadership is asking what went wrong. What happened?"

Generate 10–15 potential failure causes without filtering. Include:

• Technical failures
• User adoption problems
• Market/competitive misreads
• Organizational/political issues
• Operational breakdowns
• Missing capabilities

---

Step 2: Classify Each Risk

Categorize every risk into one of three types:

Tigers — Real, evidence-backed risks that require action

• Based on data, past experience, or expert judgment
• Would cause significant damage if they materialize
• Can be mitigated with specific actions

Paper Tigers — Concerns that seem scary but are manageable

• Often raised by stakeholders with incomplete context
• Low probability or low actual impact
• Can be acknowledged and monitored without dedicated action

Elephants — Unspoken risks nobody wants to discuss

• Political sensitivities (team capabilities, budget, leadership decisions)
• Uncomfortable truths (market isn't ready, product isn't differentiated)
• Requires psychological safety to surface

---

Step 3: Score Tigers by Urgency

For each Tiger, classify urgency:

Urgency	Definition	Action Required
Launch-Blocking	Must solve before launch or initiative is at serious risk	Mitigation plan required NOW
Fast-Follow	Can launch, but must address within 30 days post-launch	Assign owner, set deadline
Track	Monitor with defined triggers; act if situation changes	Define monitoring metric and threshold

---

Step 4: Create Mitigation Plans for Launch-Blocking Tigers

For each launch-blocking Tiger, produce:

### Tiger: [Risk Description]

**Evidence**: Why we believe this is real
**Impact if unmitigated**: What happens if we ignore it
**Mitigation plan**:
1. [Specific action]
2. [Specific action]
3. [Specific action]
**Owner**: [Name/Role]
**Due date**: [Date — must be before launch]
**Success criteria**: How we know the risk is mitigated

---

Step 5: Produce the Pre-Mortem Summary

## Pre-Mortem Summary

**Initiative**: [Name]
**Launch date**: [Date]
**Pre-mortem date**: [Today]
**Participants**: [Names/Roles]

---

### Launch-Blocking Tigers (Must Resolve)

| # | Risk | Impact | Mitigation | Owner | Due |
|---|------|--------|------------|-------|-----|
| 1 | [risk] | [impact] | [action] | [who] | [when] |

### Fast-Follow Tigers (Resolve Within 30 Days)

| # | Risk | Impact | Mitigation | Owner | Due |
|---|------|--------|------------|-------|-----|
| 1 | [risk] | [impact] | [action] | [who] | [when] |

### Tracked Risks (Monitor)

| # | Risk | Monitoring Metric | Trigger Threshold | Owner |
|---|------|------------------|-------------------|-------|
| 1 | [risk] | [metric] | [threshold] | [who] |

### Paper Tigers (Acknowledged, No Action)

- [risk] — Why it's manageable: [reason]

### Elephants (Surfaced, Needs Discussion)

- [risk] — Why this matters: [reason]

---

### Decision
- [ ] **GO** — All launch-blocking Tigers mitigated
- [ ] **CONDITIONAL GO** — Launch-blocking Tigers have plans, not yet resolved
- [ ] **NO-GO** — Unresolved launch-blocking Tigers, delay recommended

---

Facilitation Tips

• Anonymity helps — Let people write risks privately before sharing
• No judgment — Every risk gets written down, classified later
• Elephants are the prize — The most valuable risks are the ones people are afraid to say
• Time-box — 45–60 minutes for the full exercise
• Revisit — Review the pre-mortem 1 week before launch to check mitigation progress

---

Anti-Patterns

Avoid	Why	Instead
Skipping Elephants	The unsaid risks are often the most dangerous	Create psychological safety, use anonymous input
All risks are Tigers	If everything is critical, nothing is	Force classification — most risks are Paper Tigers
No owners assigned	Unowned risks never get mitigated	Every Tiger needs a named owner and due date
Running too early	Pre-mortem needs a concrete plan to evaluate	Run after PRD/architecture, before execution
Running too late	No time to mitigate launch-blocking risks	Run 2–4 weeks before launch, not the day before
Optimism creep	Team agrees risks exist but "we'll figure it out"	Demand specific mitigation actions, not vague reassurances

---

References

• Klein, Gary. "Performing a Project Premortem." Harvard Business Review (2007)
• Tigers, Paper Tigers, Elephants framework

<!-- Source: .faos/custom/skills/business/pre-mortem/SKILL.md -->