Pre Mortem

Pre-Mortem Risk Analysis Expert

Overview

A pre-mortem is a prospective hindsight exercise: imagine that your product has launched and failed, then work backward to identify why. This skill uses the Tiger / Paper Tiger / Elephant classification to categorize risks by type and urgency, ensuring launch-blocking issues are addressed before launch while avoiding wasted effort on unlikely risks.

Core Capabilities

• Prospective hindsight framing — "It is 14 days after launch, and we failed. Why?" surfaces specific, honest risks.
• Tiger / Paper Tiger / Elephant classification — separate real evidenced risks (Tigers) from anxiety (Paper Tigers) and unspoken concerns (Elephants).
• Urgency triage — tag each Tiger Launch-Blocking, Fast-Follow, or Track with owner and decision date.
• 6-phase facilitation — scene-setting, silent generation, cluster, classify, mitigate, address elephants in 60-90 minutes.
• Automated categorization — risk_categorizer.py summarizes distribution and flags elephants needing escalation.

When to Use

• Before committing significant resources to build (post-ideation, post-validation).
• Before a major launch, migration, or architectural change.
• When the team has "a bad feeling" they cannot articulate.
• When stakeholder confidence is high and you need to stress-test it.

Quick Start

python3 scripts/risk_categorizer.py --demo            # built-in sample (7 risks)
python3 scripts/risk_categorizer.py input.json        # categorize your risks
python3 scripts/risk_categorizer.py input.json --format json

Each risk needs description, category (tiger/paper_tiger/elephant), evidence, and urgency (launch_blocking/fast_follow/track) for tigers. Document the session with assets/pre_mortem_template.md.

References

Load the reference that matches the task — keep this file lean and pull detail on demand:

• [references/methodology-and-tools.md](references/methodology-and-tools.md) — the thought experiment, full Tiger/Paper Tiger/Elephant classification with examples, urgency table, the 6-phase facilitation script, risk_categorizer.py usage and flags, output formats, troubleshooting, success criteria, and bibliography. Read when running or scripting a session.
• [references/pre-mortem-guide.md](references/pre-mortem-guide.md) — Gary Klein's origin and why pre-mortems work, when (and when not) to run one, deep classification criteria across domains, the facilitation timeline, and a worked SaaS launch example. Read for the theory and a full example.
• [references/red-flags.md](references/red-flags.md) — 12 anti-patterns (mitigation theater, groupthink, vague risks, over-mitigated elephants, late pre-mortems, missing owners) with bad/good examples and one-line checks. Read before sharing pre-mortem output.

Scope & Limitations

In Scope: prospective hindsight using the "14 days after launch failure" framing; Tiger / Paper Tiger / Elephant classification with urgency levels; automated elephant escalation detection; risk registry generation; facilitation methodology for in-person and remote teams.

Out of Scope: ongoing risk management and tracking (see senior-pm/risk_matrix_analyzer.py); quantitative probability/impact scoring (senior-pm/); product discovery and hypothesis validation (brainstorm-experiments/); technical architecture risk assessment (engineering/ skills).

Important Caveats: most effective with 4-8 participants; the elephant escalation keyword check is a heuristic; pre-mortems complement, not replace, assumption mapping (identify-assumptions/); psychological safety is a prerequisite.

Integration Points

Pre-Mortem Analysis Template

Session Details

---

Summary

---

Tigers (Real Risks)

Launch-Blocking

Fast-Follow (Address within 2 weeks post-launch)

Track (Monitor, act if escalated)

---

Paper Tigers (Unlikely / Low Impact)

---

Elephants (Unspoken Concerns)

---

Action Plan: Launch-Blocking Items

These items must be resolved before launch can proceed.

Item T1: [Risk Name]

Item T2: [Risk Name]

---

Launch Decision

---

Follow-Up Schedule

---

Notes

Capture additional context, debates, or observations from the session.

Example: Acme Analytics — Pre-Mortem for "Shared Dashboards v1" Launch

Real-world scenario showing how to apply this skill end-to-end.

Context

Acme Analytics (Series-B B2B data platform) is preparing to launch "Shared Dashboards v1" — public/auth-gated dashboard sharing. The 3 most-load-bearing assumptions were validated in the assumption-mapping work; engineering has built v1 behind a feature flag. Launch is scheduled for 2026-08-15. Before commit, the PM (Priya) wants a structured pre-mortem with the full product trio + adjacent stakeholders.

Confidence in the room is high — assumptions tested green, engineering is on schedule, sales is excited. That's exactly the moment a pre-mortem matters. The pre-mortem skill is being applied to surface what could go wrong, classify each risk as Tiger / Paper Tiger / Elephant, and assign mitigations.

Inputs

• Feature: Shared Dashboards v1 — public link + magic-link guest viewer
• Launch target: 2026-08-15
• Assumptions tested green: V2 (renewal signal), U2 (external viewer comprehension), V1 (25% will share)
• Team: Priya (PM), Liang (Designer), Reza (Engineer), Anna (VP Product), Renata (CS lead), Yusuf (Security lead)
• 60-minute pre-mortem session
• Constraint: must produce ranked Tigers + mitigation owners by EOD
• Constraint: this is not a re-litigation of the build decision; it is a stress test

Applying the skill

1. Used the "14 days after launch, it failed" framing. Did not say "what could go wrong?" — that produces hand-waving. Said "It is 2026-08-29. The launch has failed. Why?" — that produces concrete failure narratives. 2. Silent generation, then share-out. Each of 6 participants wrote their failure narratives independently for 10 minutes. Group-mode produces 5-7 risks; silent-mode produced 23. 3. Classified each risk as Tiger / Paper Tiger / Elephant. Explicitly walked through each one and named the category with evidence. 4. Surfaced Elephants intentionally. Priya asked the explicit question: "What is the risk that we all know about but no one is saying out loud?" Three Elephants surfaced. 5. Wrote mitigations only for Tigers and Elephants. Did NOT spend time mitigating Paper Tigers — those are documented and parked. 6. Assigned owners with dates. Every Tiger and Elephant got a named owner and a deadline before launch.

The artifact

================================================================
  PRE-MORTEM — SHARED DASHBOARDS v1
  Date:     2026-05-22
  Duration: 60 minutes
  Facilitator: Priya Rao
  Participants: Priya (PM), Liang (Designer), Reza (Eng),
                Anna (VP Product), Renata (CS),
                Yusuf (Security)
  Launch target: 2026-08-15
================================================================


PART 1 — THE THOUGHT EXPERIMENT (10 MIN SILENT)

Framing read at start:
  "It is August 29, 2026. Shared Dashboards v1 launched
   on August 15, two weeks ago, and has failed. By 'failed'
   I mean one or more of: customer trust damaged, ARR
   negatively impacted, public incident, internal team
   morale damaged, or quietly rolled back. Take 10 minutes,
   silently. Write down every plausible reason why."

Total raw risks generated: 23


PART 2 — ALL 23 RISKS CLASSIFIED

[TIGER = real, evidence-backed, must mitigate]
[PAPER TIGER = sounds scary, low evidence or low impact]
[ELEPHANT = known but unspoken; surfaced deliberately]

  ID    Risk                                              Class
  ----  -----------------------------------------------   -----
  R1    A customer accidentally shares a dashboard
        containing PII; data leak makes the news          TIGER
  R2    External viewers don't understand context;
        bounce; customer concludes feature is broken      TIGER
  R3    Cross-tenant data leak in the embed framework     TIGER
  R4    CS gets flooded with permission-confusion
        tickets in the first week                         TIGER
  R5    Sales overpromises; demos a use case v1
        doesn't support                                   TIGER
  R6    Anna's CFO-pet pricing change lands the same
        week and confuses customers                       ELEPHANT
  R7    The competitor (Sigma) announces a similar
        feature the week we launch                        PAPER TIGER
  R8    Server can't scale to 10x traffic                 PAPER TIGER
  R9    Embed dependency on third-party SDK breaks
        on a customer's old browser                       PAPER TIGER
  R10   Sharing causes tier-3 seat cannibalization        TIGER
  R11   The lead engineer Reza is interviewing
        elsewhere and may leave before GA                 ELEPHANT
  R12   We launch but 40% of mid-market never sees
        the announcement                                  TIGER
  R13   Magic-link auth gets blocked by enterprise
        email security filters                            TIGER
  R14   Public dashboards get indexed by search engines
        and customer data shows up in Google              TIGER
  R15   GDPR/compliance review hasn't happened for
        the "anonymous viewer" data flow                  TIGER
  R16   Customer's CISO blocks the feature for security
        review and the customer drops it                  TIGER
  R17   Internal CS team doesn't have training in time    TIGER
  R18   The marketing materials get the messaging wrong
        and confuse the buyer                             PAPER TIGER
  R19   Mid-market customers love it but never tell
        their renewal AE, so renewal narrative doesn't
        change                                            TIGER
  R20   Renata's CS team has been told to deprioritize
        this feature in favor of a different initiative   ELEPHANT
  R21   Embedded analytics customers ALREADY paying for
        embedding get angry that "embedded" is now free   TIGER
  R22   Feature flag bug exposes the feature to all
        accounts on day 1, including tier-1 (not licensed) TIGER
  R23   Post-launch instrumentation isn't wired; we
        can't measure impact                              TIGER


PART 3 — TIGER COUNT

  TIGER: 14
  ELEPHANT: 3
  PAPER TIGER: 6

Average pre-mortem has 6-10 Tigers. 14 is high. Two reasons:
  - The feature touches security, billing, comms, and CS
    all at once.
  - The silent-generation method surfaced more than a group
    discussion would have.


PART 4 — TIGERS — DETAILED MITIGATIONS

R1  Accidental PII share
    Likelihood: medium. Evidence: 3 customers in our top-20
    have admin dashboards that include named lists.
    Impact: high — brand damage + GDPR.
    Mitigation:
      - Pre-share check that scans for "looks like PII"
        patterns (emails, phones, SSN format) and warns
        the sharer.
      - Sharing default is "auth-gated guest viewer," not
        public.
      - Public-link option requires a second confirmation.
    Owner: Liang + Reza
    Deadline: 2026-07-15

R2  External viewers don't understand context
    Likelihood: medium. Evidence: U2 experiment passed at
    6/8 but two viewers were confused.
    Impact: medium — customers conclude feature is broken
    even when it works.
    Mitigation:
      - Shared-dashboard view includes a "context" header
        block (filters, date range, definitions)
        editable by the sharer.
      - First-time view shows a one-line "this dashboard
        was shared with you by [name]" affordance.
    Owner: Liang
    Deadline: 2026-08-01

R3  Cross-tenant data leak in embed
    Likelihood: low. Evidence: Reza's prior on the embed
    framework is high.
    Impact: SEVERE — company-ending if it happens.
    Mitigation:
      - Penetration test on the embed flow scheduled
        2026-07-22.
      - Row-level security review pre-launch.
      - Bug bounty pre-announcement to the security
        researcher community 2026-08-01.
    Owner: Yusuf + Reza
    Deadline: 2026-08-08 (1 week before launch)

R4  CS flood for permission confusion
    Likelihood: high. Evidence: pre-launch usability
    testing showed permission UI confusion in 3 of 8 cases.
    Impact: medium — CS bandwidth + first-week perception.
    Mitigation:
      - CS pre-trained with a 90-min walkthrough +
        rehearsed 12 tickets in advance.
      - First-week dedicated #shared-dashboards Slack
        channel with eng + PM on rotation.
      - Updated FAQ in support portal pre-launch.
    Owner: Renata
    Deadline: 2026-08-08

R5  Sales overpromise
    Likelihood: high. Evidence: this happened with the last
    two major launches.
    Impact: medium — customer expectations vs reality
    mismatch.
    Mitigation:
      - Sales enablement deck explicitly lists "v1 does
        and does not."
      - 2 sales engineers review demo scripts pre-launch.
      - Roadmap "coming-in-v2" page published to set
        expectations.
    Owner: Anna (VP Product)
    Deadline: 2026-08-01

R10 Tier-3 seat cannibalization
    Likelihood: medium. Evidence: V3 in assumption map was
    parked because untestable.
    Impact: medium — ARR drag.
    Mitigation:
      - Launch with usage cap: tier-1 = 1 shared dashboard,
        tier-2 = 10, tier-3 = unlimited.
      - 30-day post-launch ARR review with finance to
        catch cannibalization signal early.
      - Pricing brief reviewed with CRO pre-launch.
    Owner: Priya + Finance contact
    Deadline: 2026-08-08

R12 40% of mid-market never sees the announcement
    Likelihood: high. Evidence: last 2 launches had
    similar coverage.
    Impact: medium — usage adoption lag.
    Mitigation:
      - 3-channel announcement: in-app banner, email,
        webinar.
      - CS reach-out to top-100 accounts personally.
      - Pricing page updated.
      - PR blog post + Twitter.
    Owner: Marketing partner + Renata
    Deadline: 2026-08-15

R13 Magic-link auth blocked by enterprise email filters
    Likelihood: medium. Evidence: this happens for 8% of
    transactional emails to enterprise customers today.
    Impact: medium — usability for enterprise viewers.
    Mitigation:
      - Send-from domain dedicated and SPF/DKIM aligned.
      - Magic-link expiry 24h (longer = more deliverability
        time).
      - Fallback: "didn't get the email? Reach out to your
        sharer" affordance.
    Owner: Reza + Marketing partner
    Deadline: 2026-08-01

R14 Public dashboards get indexed by Google
    Likelihood: high if not prevented. Evidence: default
    web behavior.
    Impact: HIGH — customer data exposure.
    Mitigation:
      - robots.txt disallow + noindex headers on all public
        share URLs.
      - Random + non-guessable share URL (UUIDv4).
      - Periodic Google search query for indexed share URLs
        (automated weekly).
    Owner: Reza + Yusuf
    Deadline: 2026-08-08

R15 GDPR review hasn't happened
    Likelihood: certain if not done. Evidence: it has not
    been done.
    Impact: SEVERE — regulatory risk.
    Mitigation:
      - DPIA filed with legal counsel 2026-06-15.
      - Anonymous-viewer data minimization audit.
      - Privacy policy updated.
    Owner: Yusuf + Legal
    Deadline: 2026-07-15

R16 Customer CISO blocks the feature
    Likelihood: medium. Evidence: 2 enterprise customers
    already asked.
    Impact: medium — slow enterprise adoption.
    Mitigation:
      - Pre-publish a security overview document.
      - SOC 2 control mapping document.
      - Sales engineering CISO talking points.
    Owner: Yusuf
    Deadline: 2026-08-01

R17 CS team not trained in time
    Likelihood: medium. Same root cause as R4.
    Impact: medium.
    Mitigation: (same as R4)
    Owner: Renata
    Deadline: 2026-08-08

R19 Mid-market loves it but doesn't tell AE
    Likelihood: high. Evidence: V2 experiment confirmed
    customers value it but only 12 of 30 mentioned it
    spontaneously.
    Impact: medium — renewal narrative doesn't update.
    Mitigation:
      - Quarterly business review template adds a
        "Shared Dashboards" usage card.
      - CS save script anchors on shared dashboards usage.
      - 90-day post-launch QBR data review.
    Owner: Renata + Priya
    Deadline: 2026-08-15 (template), 2026-11-15 (review)

R21 Embedded analytics customers get angry
    Likelihood: medium. Evidence: embedded customers pay
    a separate fee.
    Impact: medium — customer backlash.
    Mitigation:
      - Pre-launch 1:1 outreach to embedded customers (~24
        accounts) explaining how v1 is different from
        full embedding (no white-label, no SSO, no JS SDK).
      - Roadmap "embedded v2" page published.
    Owner: Priya + Renata
    Deadline: 2026-08-08

R22 Feature flag bug exposes to wrong accounts
    Likelihood: low. Evidence: feature flag system has
    had 2 bugs in 18 months.
    Impact: high — billing dispute + bad first impression
    for tier-1 users.
    Mitigation:
      - Soft launch to 10 internal accounts first.
      - Then 50 friendly customers for 1 week.
      - Then tier-2 and tier-3 only via flag check.
      - Audit flag values pre-launch and 24h after.
    Owner: Reza
    Deadline: 2026-08-15 (launch day)

R23 Post-launch instrumentation isn't wired
    Likelihood: medium. Evidence: this is the highest-
    risk gap in every Acme launch.
    Impact: high — can't measure success or learn.
    Mitigation:
      - Instrumentation as part of definition of done.
      - Pre-launch dashboard review.
      - One PM-owned launch dashboard, day-1.
    Owner: Priya + Sofia (data analyst)
    Deadline: 2026-08-08


PART 5 — ELEPHANTS — NAMED AND ADDRESSED

E1 (R6) — CFO pricing change collision
  What it is: Anna's CFO is pushing a tier restructuring
  to land the same week as Shared Dashboards. No one in
  the room had said this aloud before today.
  Mitigation: Anna will request the pricing change move
  by 4 weeks. If it can't move, the launch moves.
  Owner: Anna
  Deadline: 2026-06-01 (decision)

E2 (R11) — Lead engineer interviewing
  What it is: Reza is interviewing elsewhere. The team
  has been pretending this isn't happening.
  Mitigation: Anna has a private conversation with Reza
  this week. Either we know he's staying through GA, or
  we have a documented handoff plan. Either way, this
  feature does not ship without engineering continuity.
  Owner: Anna
  Deadline: 2026-06-01

E3 (R20) — CS deprioritized this internally
  What it is: Renata's leadership told the CS team to
  prioritize a different initiative. CS is going to be
  thin on the ground for this launch.
  Mitigation: Renata escalates with her director to get
  explicit allocation of CS bandwidth for the first
  4 weeks post-launch.
  Owner: Renata
  Deadline: 2026-06-15


PART 6 — PAPER TIGERS — DOCUMENTED, PARKED

  R7   Competitor announces same week. Possible, low impact.
        Acme launch goes ahead regardless.
  R8   10x scale problem. Engineering modeled this; current
        infra handles 100x baseline easily.
  R9   Third-party SDK breaks on old browsers. <2% of
        traffic on browsers >2 years old.
  R18  Marketing materials get messaging wrong. Marketing
        partner is in the room and accountable.
  Other minor PRD-quality risks ...


PART 7 — LAUNCH READINESS GATE

The launch will be considered ready when ALL the
following are TRUE:
  - All 14 Tigers have an "in-progress" or "complete"
    status with named owner
  - All 3 Elephants have been resolved (no more
    "unspoken" status)
  - Penetration test (R3) is COMPLETE and clean
  - GDPR / DPIA (R15) is COMPLETE
  - Robots.txt + noindex (R14) is verified in staging

If any of these is incomplete at T-7, the launch slips.
The slip authority sits with Priya alone, with Anna's
backstop.


PART 8 — POST-LAUNCH PRE-MORTEM REVIEW

The team will re-read this pre-mortem on 2026-08-29 —
exactly 14 days after launch.

For each Tiger, did the mitigation work?
For each Elephant, did naming it help?
For each Paper Tiger, did we make the right call to park
it?

This is the most important step. It calibrates the team's
risk intuition for the next pre-mortem.

Why this works

• The "14 days after, it failed" framing. Concrete past-tense narrative beats abstract "what could go wrong" by a wide margin. Participants generate specific failure stories, not vague concerns.
• Silent generation surfaced 23 risks, not 7. Group discussion would have stopped at the obvious. The silent 10 minutes is the lever.
• Three Elephants surfaced. The CFO collision, the engineer interviewing, and the CS deprioritization. None had been in any meeting note. The single question "what is the thing we all know about and aren't saying?" produced all three.
• Tigers got mitigations, Paper Tigers did not. Spending time mitigating Paper Tigers wastes pre-launch cycles. Documented and parked is the right disposition.
• Each Tiger has an owner and a date. Mitigations without owners are vapor. The list is operational, not just intellectual.
• Launch readiness gate is explicit. All 14 Tigers in progress + all 3 Elephants resolved + penetration test + DPIA + indexing controls. Without these, the launch slips. The slip authority is named (Priya, with Anna backstop).
• Post-launch review built in. The team commits to re-reading on Day 14. This is the calibration loop — most teams pre-mortem and then never look at the doc again. The review is what teaches the team to do better pre-mortems next time.

What's next

• Each Tiger mitigation becomes a tracked task in `../../execution/dependency-map/` with explicit dependencies.
• The launch readiness gate maps to `../../execution/launch-playbook/`.
• Post-launch monitoring uses `../../execution/activation-funnel/` for the usage signals and `../../execution/north-star-metric/` for the renewal narrative.
• If anything goes wrong despite the mitigations, run `../../execution/post-mortem/` for blameless RCA.
• The CS pre-training (R4 / R17) hooks into `../../execution/customer-feedback-triage/`.
• Comms plan (R12) is sequenced via `../../execution/launch-playbook/` and `../../execution/release-notes/`.

Pre-Mortem Methodology & Tooling

Read this when running a session end-to-end: the thought experiment, full risk classification with examples, the 6-phase facilitation script, the risk_categorizer.py tool, output formats, troubleshooting, and success criteria.

Core Concept

The Thought Experiment

"It is 14 days after launch. The product has failed. What went wrong?"

This framing exploits a cognitive bias: people are better at explaining past events than predicting future ones. By placing the failure in the "past" (even fictitiously), participants generate more specific and honest risk assessments.

Risk Classification

Tigers (Real Risks)

Tigers are real, evidence-backed risks that could cause serious harm if not addressed.

Characteristics:

• Supported by data, past experience, or observable trends.
• The team can describe a plausible failure scenario in concrete terms.
• Ignoring them would be negligent.

Examples:

• "Our authentication service went down 3 times last month. A launch-day outage is plausible."
• "We have zero customers in the enterprise segment. Our sales team has no enterprise relationships."
• "The EU regulation takes effect in 60 days. We have not started compliance work."

Paper Tigers (Look Scary but Unlikely)

Paper Tigers are risks that sound alarming but, on closer inspection, are unlikely or have minimal real impact.

Characteristics:

• Based on hypothetical scenarios without supporting evidence.
• The probability is very low, or the impact would be manageable.
• Often raised because of general anxiety rather than specific knowledge.

Examples:

• "A competitor might copy our feature" -- possible, but their execution timeline is 6-12 months.
• "The server might not handle 100x traffic" -- but our realistic projection is 5x, with auto-scaling.
• "Users might hate the new UI" -- but usability testing with 8 users showed high satisfaction.

Elephants (Unspoken Concerns)

Elephants are the risks everyone knows about but nobody talks about. They are the "elephant in the room."

Characteristics:

• The team avoids discussing them due to politics, hierarchy, or discomfort.
• Often involve people, process, or organizational issues rather than technical ones.
• Frequently the actual cause of failure when projects fail.

Examples:

• "The tech lead does not believe in this project and has been disengaged for weeks."
• "The CEO's pet feature is driving the roadmap, but customers have not asked for it."
• "We do not have a plan for what happens when the contractor's contract ends next month."

Tiger Urgency Classification

Once a risk is classified as a Tiger, assign an urgency level:

Methodology

Phase 1: Set the Scene (5 minutes)

The facilitator reads this prompt to the group:

"Imagine it is 14 days after our launch. The product has failed. Users are not adopting it, key metrics are down, and leadership is asking what went wrong. Take 10 minutes to write down every reason you can think of for why we failed. Be specific. Be honest. Nothing is off limits."

Ground rules:

• Anonymous contributions (sticky notes or digital equivalent).
• No attribution, no blame, no judgment.
• Quantity over quality in the first round.

Phase 2: Generate Risks (10 minutes)

Each participant independently writes down failure scenarios. One risk per sticky note. Aim for 5-10 per person.

Prompts to stimulate thinking:

• What technical system is most likely to break?
• What customer objection have we not addressed?
• What team dynamic could derail us?
• What external event could change our assumptions?
• What are we pretending is not a problem?
• What decision are we avoiding?

Phase 3: Share and Cluster (15 minutes)

1. Read each risk aloud (without attribution). 2. Place on the board. 3. Group similar risks together. 4. Merge duplicates.

Phase 4: Classify (15 minutes)

For each cluster, the group decides:

For each Tiger, assign urgency: Launch-Blocking, Fast-Follow, or Track.

Phase 5: Mitigation Plans (15 minutes)

For each Launch-Blocking Tiger, complete:

Phase 6: Address Elephants (10 minutes)

Elephants require a different approach than Tigers:

1. Acknowledge -- Name the elephant explicitly. "The team is concerned that..." 2. Assess -- Is this actually a Tiger in disguise? If so, reclassify. 3. Decide -- Either address it (assign an owner) or consciously accept it (document the acceptance and rationale).

Python Tool: risk_categorizer.py

Categorize and analyze risks using the CLI tool:

# Run with demo data
python3 scripts/risk_categorizer.py --demo

# Run with custom input
python3 scripts/risk_categorizer.py input.json

# Output as JSON
python3 scripts/risk_categorizer.py input.json --format json

Input Format

{
  "risks": [
    {
      "description": "Authentication service has had 3 outages in the last month",
      "category": "tiger",
      "evidence": "Incident reports from last 30 days",
      "urgency": "launch_blocking"
    }
  ]
}

Output

Risk distribution summary, action plans for launch-blocking tigers, and flags for elephants that may need investigation.

See scripts/risk_categorizer.py for full documentation.

Output Format

Pre-Mortem Summary

Pre-Mortem Analysis: [Product/Feature Name]
Date: YYYY-MM-DD
Participants: [list]
Total risks identified: N
  - Tigers: X (Launch-Blocking: A, Fast-Follow: B, Track: C)
  - Paper Tigers: Y
  - Elephants: Z

Risk Registry

Use assets/pre_mortem_template.md for the full document template.

Troubleshooting

Success Criteria

• Pre-mortem conducted before every major launch, migration, or significant resource commitment
• At least 5-10 risks generated per person during the silent writing phase
• Risk distribution includes all three categories (not all tigers, not all paper tigers)
• Every launch-blocking tiger has an assigned owner, concrete mitigation plan, and decision date
• Elephants are explicitly named and either addressed or consciously accepted with documented rationale
• Pre-mortem findings are reviewed against actual outcomes post-launch to calibrate future sessions
• Session duration stays within 60-90 minutes total across all 6 phases

Tool Reference

risk_categorizer.py

Categorizes pre-mortem risks as Tigers, Paper Tigers, or Elephants. Generates action plans for launch-blocking tigers and flags elephants with escalation signals.

Input fields per risk:

• description (required): Clear description of the risk scenario
• category (required): One of tiger, paper_tiger, elephant
• evidence (required): Supporting data or observations
• urgency (required for tigers): One of launch_blocking, fast_follow, track

Bibliography

• Gary Klein, "Performing a Project Pre-Mortem," Harvard Business Review (2007)
• Daniel Kahneman, Thinking, Fast and Slow (2011) -- prospective hindsight
• Chip Heath & Dan Heath, Decisive (2013) -- decision-making under uncertainty
• Amy Edmondson, The Fearless Organization (2018) -- psychological safety for surfacing elephants

Pre-Mortem Guide

Origin: Gary Klein's Prospective Hindsight

The pre-mortem technique was developed by psychologist Gary Klein and published in the Harvard Business Review in 2007. It is based on research into "prospective hindsight" -- the finding that imagining an event has already occurred increases the ability to identify reasons for that event by 30%.

Why Pre-Mortems Work

Traditional risk assessment asks: "What could go wrong?" This question triggers optimism bias -- people tend to minimize risks because they are invested in the plan's success.

A pre-mortem flips the frame: "The project has failed. Why?" This framing: 1. Legitimizes dissent. Team members have permission to voice concerns. 2. Activates different cognitive processes. Explaining a "past" event is easier than predicting a future one. 3. Reduces groupthink. The exercise explicitly asks for failure scenarios, breaking the social pressure to be positive. 4. Surfaces elephants. Anonymous contributions lower the barrier to raising sensitive issues.

When to Run a Pre-Mortem

• Before major commits. Before allocating a full team to a multi-month effort.
• Before launches. 2-4 weeks before go-live, when there is still time to act on findings.
• Before migrations or architectural changes. High-risk, low-reversibility decisions.
• Periodically during long projects. Every 6-8 weeks for projects lasting more than a quarter.

When NOT to Run a Pre-Mortem

• When the decision is already made and irreversible. A pre-mortem on a shipped feature wastes energy; run a retrospective instead.
• When the team lacks psychological safety. If people cannot speak honestly, the exercise will produce sanitized results.

---

Tiger / Paper Tiger / Elephant Classification

Tigers: Real Risks

Definition: Risks supported by evidence that could credibly cause the project to fail.

How to identify:

• Can the person describe a specific, plausible failure scenario?
• Is there data, past experience, or observable signals supporting this risk?
• Would a reasonable outside observer agree this is a real concern?

Examples across domains:

Paper Tigers: Perceived but Unlikely Risks

Definition: Risks that sound alarming but are unlikely to materialize or would have manageable impact.

How to identify:

• Is the scenario based on speculation rather than evidence?
• Is the probability very low (< 5%)?
• If it happened, could we recover quickly?
• Is this a general anxiety rather than a specific concern?

Examples:

Caution: Sometimes a Paper Tiger is actually a Tiger that the team is underestimating. If there is disagreement, investigate further before dismissing.

Elephants: Unspoken Concerns

Definition: Risks that the team is aware of but avoids discussing, typically because they involve interpersonal dynamics, organizational politics, or uncomfortable truths.

How to identify:

• The room goes quiet when the topic is raised.
• People speak in euphemisms or generalities.
• The risk involves a person, a relationship, or a power dynamic.
• Multiple people have mentioned it privately but not in group settings.

Examples:

How to surface elephants: 1. Anonymous contributions (sticky notes, digital forms). 2. Direct prompts: "What are we pretending is not a problem?" 3. One-on-one conversations before the session to prime participation. 4. Explicit psychological safety: "There will be no consequences for anything raised in this exercise."

---

Urgency Classification Guide

Once a risk is classified as a Tiger, assign one of three urgency levels:

Launch-Blocking

Definition: If this risk is not mitigated before launch, the launch should not proceed.

Criteria (any one is sufficient):

• The risk could cause data loss, security breach, or legal liability.
• The risk could cause >50% of target users to have a broken experience.
• The risk would make the core value proposition non-functional.
• The risk would cause immediate, public reputational damage.

Required action:

• Concrete mitigation plan with specific steps.
• Single accountable owner.
• Decision date: a specific date by which the mitigation is complete or the launch is postponed.

Fast-Follow

Definition: This risk is real but manageable at launch. It must be addressed within 2 weeks post-launch.

Criteria:

• The risk affects a subset of users or a secondary flow.
• A temporary workaround exists (manual process, reduced functionality).
• The risk grows over time but is acceptable for a short window.

Required action:

• Documented plan.
• Assigned owner.
• Scheduled in the first post-launch sprint.

Track

Definition: This risk should be monitored but does not require immediate action.

Criteria:

• The risk is real but low probability in the near term.
• The impact is manageable if it materializes.
• Early warning signals exist that would give time to respond.

Required action:

• Added to risk register.
• Monitoring metric or tripwire defined.
• Reviewed at regular cadence (weekly or bi-weekly).

---

Facilitation Guide for Pre-Mortem Sessions

Before the Session

1. Invite the right people. Include PM, Design, Engineering, QA, and at least one person outside the core team (fresh perspective). 2. Set expectations. Send a pre-read explaining the exercise and ground rules. 3. Prepare materials. Sticky notes (physical or digital), timer, board for clustering. 4. Create safety. Ensure anonymous contribution is possible.

During the Session (60 minutes total)

Facilitator Tips

• Protect anonymity. If reading sticky notes aloud, shuffle them first. Do not ask "whose is this?"
• Probe Paper Tigers. "What evidence would change this from a Paper Tiger to a Tiger?" This prevents premature dismissal.
• Name Elephants explicitly. "I notice the room got quiet. Let us talk about this one."
• Keep the energy up. This exercise can feel heavy. Remind participants that identifying risks is empowering, not demoralizing.
• Time-box strictly. The mitigation phase tends to expand. Keep it focused on Launch-Blocking items only.

After the Session

1. Document all risks in the pre-mortem template. 2. Distribute to all participants and stakeholders. 3. Track Launch-Blocking mitigations in your project management tool. 4. Schedule a follow-up review 1 week before the decision date.

---

Example Pre-Mortem: SaaS Feature Launch

Product: Analytics dashboard for a B2B SaaS product Launch date: 3 weeks from pre-mortem Participants: PM, 2 Engineers, Designer, QA Lead

Tigers Identified

Paper Tigers Identified

Elephants Identified

Action Plan (Launch-Blocking)

Red Flags: Pre-Mortem

Common ways this skill's output goes wrong — concrete examples, why they're bad, and how to fix them. Pair with the SKILL.md and Troubleshooting table.

How to use this document

When you have just facilitated a pre-mortem or classified risks, scan the red flags below before sharing the output. Each red flag shows the bad and good version, anchored in Klein's prospective hindsight method and the Tiger/Paper Tiger/Elephant classification.

---

Red Flag 1: Treating Paper Tigers as Tigers (Mitigation Theater)

Symptom. Risk list classifies "AWS could go down on launch day" as a Tiger and assigns 3 engineers to build redundancy. AWS has 99.99% SLA; the probability is negligible.

Why it's bad. Klein's framework explicitly separates Tigers (real, evidenced, plausible failure scenarios) from Paper Tigers (sound scary, lack evidence). Mitigating Paper Tigers burns capacity that should go to Tigers and Elephants. The result is "we mitigated everything" — but the actual launch fails on an unmitigated Tiger.

Bad example:

"Tigers: (1) AWS regional outage on launch day. Mitigation: build multi-region redundancy ($50K, 2 engineers, 6 weeks)."

Good example:

"Paper Tiger: AWS regional outage. Evidence: 99.99% SLA, no recent incidents in our region. Probability x impact below threshold for mitigation. Action: standard runbook, no extra investment."

How to catch it. For each "Tiger", what is the evidence of plausibility? If only the consequence is described (without evidence of likelihood), it may be a Paper Tiger.

---

Red Flag 2: Groupthink on Risks (Everyone Names the Same Three)

Symptom. 8 people in pre-mortem; output lists 4 risks, all of which the senior person mentioned first. Real risks held by the team go unspoken.

Why it's bad. Klein's whole insight is that prospective hindsight surfaces risks that ordinary planning misses. Groupthink defeats this — risks become a recitation of the senior's worries instead of a genuine surfacing exercise. The fix is silent individual generation before any group discussion.

Bad example:

Pre-mortem opens with the VP saying "I'm worried about scalability." 90% of subsequent risks named are scalability-related.

Good example:

Pre-mortem opens with 10 minutes of silent individual writing: 'Imagine it's 14 days post-launch and the product failed. Write 5 things that went wrong, in detail.' Then round-robin sharing. Output: 22 distinct risks across 5 categories — only one of which is scalability."

How to catch it. Was there silent individual generation before group discussion? If discussion started open, groupthink corrupted output.

---

Red Flag 3: Vague Risks ("Things Could Go Wrong")

Symptom. Risk list has items like "stakeholder issues", "scope creep", "technical risk." No specifics.

Why it's bad. Vague risks cannot be mitigated. "Stakeholder issues" could mean a hundred different scenarios, each with a different mitigation. Klein insists on specific, concrete failure scenarios — "the CRO will block the launch because we did not include the enterprise SKU."

Bad example:

"Risk: Stakeholder alignment problems."

Good example:

"Risk (Tiger): The CRO will block launch on Day -7 because the enterprise SKU was de-prioritized in scope. Evidence: CRO said in Q3 review 'enterprise must be in launch.' Mitigation: meet with CRO Day -21 to align scope; if not aligned by Day -14, escalate to CEO. Owner: PM."

How to catch it. For each risk, can you describe the specific scenario in 1-2 sentences? If not, the risk is vague.

---

Red Flag 4: Elephants Treated as Tigers (Over-Mitigating Large Acceptable Risks)

Symptom. Risk "we may need to add a second sales engineer to support enterprise customers" is classified as a Tiger and triggers urgent staffing action.

Why it's bad. Elephants are large, expected risks that the business has chosen to accept. Treating them as Tigers wastes pre-launch focus. The right response to an Elephant is acknowledge, plan for, and continue — not mitigate as if it were a launch-blocker.

Bad example:

"Tiger: 'We may need another sales engineer next quarter.' Mitigation: emergency hire."

Good example:

"Elephant: Enterprise traction will require 1-2 additional sales engineers in Q3. This is large but expected; we have budget. Plan: open req now, hire by Q3 start. Not a launch-blocker."

How to catch it. Is the risk unexpected and plausible, or large and expected? If the latter, it is an Elephant.

---

Red Flag 5: Pre-Mortem Held Too Late to Matter

Symptom. Pre-mortem held 1 week before launch. Surfaces a Tiger that requires 4 weeks of work to mitigate. The team launches anyway.

Why it's bad. Pre-mortems are valuable when there is still time to act. Held too late, they become theater — risks surfaced cannot be mitigated, and the team launches into known failure. Klein recommends pre-mortems at the planning stage, not the launch stage.

Bad example:

Pre-mortem on Day -7. Tiger surfaces: 'Onboarding flow has not been usability-tested with non-technical users.' Cannot fix in 7 days. Launch proceeds.

Good example:

Pre-mortem at project kickoff (Day -90). Tigers surface; mitigations planned. Second pre-mortem at Day -30 to re-check. Final launch checklist at Day -7 confirms Tigers have been addressed."

How to catch it. Can the surfaced risks actually be mitigated in the time remaining? If not, the pre-mortem was too late.

---

Red Flag 6: No Owner per Risk (Diffuse Accountability)

Symptom. Risk list has 12 items. Mitigations are sketched. No name attached. "The team will handle it."

Why it's bad. Diffuse ownership = no ownership. The risks that are not assigned drift; week 4 of the project, they are still listed as "the team will handle" with no progress. Klein's framework requires explicit ownership of each Tiger.

Bad example:

"Risk 1: Stakeholder alignment. Mitigation: hold meetings. Owner: team."

Good example:

"Risk 1 (Tiger): CRO will block launch over enterprise scope. Owner: Sarah (PM). Mitigation: 1:1 with CRO by Day -21. Check-in: Day -14. Escalation path: if unresolved, escalate to CEO by Day -10."

How to catch it. Does every Tiger have a single named owner with a deadline? If multiple owners or no owner, the risk will drift.

---

Red Flag 7: Failing to Update the Risk List

Symptom. Pre-mortem produces a risk list. The list lives in a doc, never updated. By Day -14, the team has discovered new risks not in the doc, and several listed risks are no longer relevant.

Why it's bad. Risk lists decay. A snapshot from Day -90 does not reflect Day -30 reality. Klein's prospective hindsight is most useful when run iteratively, with the list as a living tracker.

Bad example:

Risk doc from Day -90. Not opened since.

Good example:

Risk tracker updated weekly. Closed risks marked. New risks added as discovered. Status report each Friday: top 3 unmitigated Tigers + owners + ETAs. Visible to leadership."

How to catch it. When was the risk list last updated? Over 2 weeks = stale.

---

Red Flag 8: Mitigation That Costs More Than the Risk

Symptom. Tiger with $50K expected impact. Mitigation costs $200K and 3 engineering months. Net result is negative.

Why it's bad. Mitigation must be proportionate. Spending more on mitigation than the risk's expected cost (impact x probability) is risk-aversion overcorrection. Klein's framework implicitly requires cost-benefit reasoning.

Bad example:

Tiger: 'API rate limit could spike at launch.' Expected cost if it happens: 4 hours customer impact (~$2K). Mitigation: rebuild infrastructure with full elastic scaling ($150K, 2 engineering months)."

Good example:

Tiger: 'API rate limit could spike at launch.' Expected cost: ~$2K. Mitigation: pre-launch load test + automated alerting + scale-up playbook on-call ($5K, 1 engineering week). Proportionate."

How to catch it. For each mitigation, is the cost less than (impact x probability)? If not, you are over-mitigating.

---

Red Flag 9: Pre-Mortem as Solo PM Exercise

Symptom. PM lists risks alone in a doc. Workshop is not held; cross-functional input not gathered.

Why it's bad. Risks live in different parts of the org. Engineers know feasibility risks; designers know usability risks; support knows operational risks; sales knows market risks. A solo PM pre-mortem captures only PM-visible risks — typically the smallest set.

Bad example:

PM solo doc: 8 risks listed.

Good example:

Pre-mortem workshop with PM, design, engineering, support, sales, security. 22 risks surfaced from 8 different angles. Engineer caught a feasibility Tiger that PM had marked as a non-issue. Security caught an Ethical risk not previously considered."

How to catch it. Who was in the pre-mortem? If PM solo, the risk surface is incomplete.

---

Red Flag 10: Pre-Mortem Without "What Would We Do?" (Mitigation Plans Missing)

Symptom. Risks identified, classified, ranked. No mitigation plans written. Team congratulates itself on a good pre-mortem and moves on.

Why it's bad. Identifying risks without planning responses is half the job. The mitigation plan is what turns awareness into reduced risk. Klein's process explicitly requires action commitments for each Tiger.

Bad example:

"Tigers: 1. CRO blocking. 2. Enterprise SKU incomplete. 3. Onboarding untested. End of doc."

Good example:

"Tiger 1: CRO blocking. Mitigation: scope alignment meeting Day -21, owner PM, escalation path CEO. Tiger 2: Enterprise SKU. Mitigation: split into MVP enterprise feature (in scope) + advanced (Q+1), owner EM. Tiger 3: Onboarding untested. Mitigation: 5-user usability test by Day -45, owner UX."

How to catch it. Every Tiger has a written mitigation plan? If not, awareness without action.

---

Red Flag 11: Confusing Risk with Worry (Emotional, Not Evidence-Based)

Symptom. Risk list contains items the team feels worried about ("the design feels weak") but no concrete failure scenario.

Why it's bad. Worries are not risks. Worries are emotional signals worth investigating but cannot be assessed without translation into a concrete failure scenario. A pre-mortem of worries produces emotional alignment, not risk reduction.

Bad example:

"Risk: The design feels weak."

Good example:

"Worry: The design feels weak. Translated to risk: 'Users may not understand the value proposition from the landing page; signup conversion below 3% threshold.' Test: 5-user moderated test before launch. If conversion concern persists, classify as Tiger."

How to catch it. For each "risk", is there a concrete failure scenario with measurable consequence? If only feelings, translate or drop.

---

Red Flag 12: No Post-Launch Verification (Did the Tigers Actually Bite?)

Symptom. Launched 6 weeks ago. No retrospective on which risks materialized vs which did not.

Why it's bad. Pre-mortem skill compounds with practice. Without post-launch verification, the team never learns which of their risks were real (Tigers) vs imagined (Paper Tigers). Next pre-mortem repeats the same misclassifications.

Bad example:

Pre-mortem done. Launch done. No follow-up.

Good example:

Post-launch retro at Day +30 includes a 'risk verification' section. Of the 7 classified Tigers, 4 materialized as predicted (mitigations worked or didn't); 3 did not materialize (re-classify as Paper Tigers for future). Of the 5 Paper Tigers, 1 actually materialized (we missed it). Learning: pattern X risks deserve more weight."

How to catch it. Was there a risk verification step in the launch retro? If not, the pre-mortem skill is not compounding.

---

Red Flag Quick Reference

Related Reading

• SKILL.md Troubleshooting section (for symptom -> root cause -> resolution)
• references/klein-prospective-hindsight.md (if present)
• identify-assumptions/references/red-flags.md (for upstream assumption mapping)
• delivery-manager/references/red-flags.md (for adjacent incident/risk patterns)