# Pre Mortem > - Skill: `frank-luongt/pre-mortem` (Agent Skill) - Install (CLI): `npx skillmds@latest add frank-luongt/pre-mortem` - Raw SKILL.md: https://api.skillmd.com/api/skills/frank-luongt/pre-mortem/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: frank-luongt (https://skillmd.com/u/frank-luongt) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/frank-luongt/pre-mortem --- --- 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: ```markdown ### 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 ```markdown ## 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](https://www.productcompass.pm/p/pre-mortem)