Pre Mortem

Pre Mortem

Run a pre-mortem risk analysis on a PRD or launch plan. Categorizes risks as Tigers (real problems), Paper Tigers (overblown concerns), and

Category: development Source: phuryn/pm-skills

What Is This?

Overview

A pre-mortem is a structured risk analysis technique where a team imagines that a product launch or plan has already failed, then works backward to identify what caused that failure. Unlike a post-mortem, which reviews what went wrong after the fact, a pre-mortem surfaces risks before they become real problems. This proactive approach gives teams the opportunity to address critical issues while there is still time to act.

The Pre Mortem skill on Happycapy applies this technique to product requirements documents and launch plans. It uses a veteran product manager persona to analyze your input and categorize every identified risk into one of three types: Tigers, Paper Tigers, or Elephants. Tigers are real, high-probability problems that need immediate attention. Paper Tigers are concerns that sound alarming but are actually overblown or manageable. Elephants are the unspoken worries that teams know exist but rarely discuss openly.

Each risk is then classified by urgency: launch-blocking, fast-follow, or track. This layered output gives product managers and engineering leads a clear, prioritized view of what needs to be resolved before shipping, what can be addressed shortly after launch, and what simply needs monitoring over time.

Who Should Use This

  • Product managers preparing a PRD for stakeholder review or engineering handoff
  • Engineering leads stress-testing a technical architecture or implementation plan
  • Startup founders evaluating whether a product is ready for a public launch
  • Program managers reviewing cross-functional launch readiness
  • Design leads checking whether UX decisions introduce downstream risk
  • QA leads identifying gaps in test coverage or release criteria

Why Use It?

Problems It Solves

  • Teams often enter launch reviews with blind spots, focusing on what is going well rather than what could fail
  • Unspoken concerns about a plan go unaddressed because no one wants to be the person who raises them
  • Risk reviews tend to treat all risks equally, making it hard to prioritize what actually needs action
  • Post-launch retrospectives identify problems too late, after users have already been affected
  • Launch decisions get made without a shared understanding of what the team is accepting as known risk

Core Highlights

  • Categorizes risks as Tigers, Paper Tigers, or Elephants for clear communication
  • Classifies each risk as launch-blocking, fast-follow, or track
  • Applies a veteran product manager perspective to your specific document
  • Works with PRDs, launch plans, technical specs, and feature briefs
  • Surfaces unspoken concerns that teams often avoid raising in meetings
  • Produces a structured, actionable risk register rather than a vague list of worries
  • Helps teams align on what is acceptable risk versus what must be resolved before shipping

How to Use It?

Basic Usage

To run a pre-mortem, invoke the skill and pass your PRD or launch plan as the input variable. The skill uses $A as the placeholder for your document.

/pre-mortem

$A = [paste your PRD or launch plan here]

You can also reference a document by name if your platform supports file context:

/pre-mortem

$A = launch_plan_v3.md

Specific Scenarios

Scenario 1: Pre-launch stress test. A product manager has a PRD ready for engineering kickoff. Before the first sprint begins, they run the pre-mortem to identify any launch-blocking Tigers that would require scope changes before work starts.

Scenario 2: Stakeholder alignment. A team is heading into a launch review meeting with leadership. They run the pre-mortem in advance and use the Elephant category output to bring unspoken concerns into the open before the meeting, rather than letting them surface as objections mid-discussion.

Real-World Examples

Example 1: A fintech team pastes their payment integration PRD. The skill identifies a Tiger around PCI compliance scope that was not explicitly addressed in the document, classifying it as launch-blocking.

Example 2: A SaaS company runs the skill on a go-to-market launch plan. The output flags a Paper Tiger around competitor response timing, noting that the concern is real but not launch-blocking, and a fast-follow recommendation to prepare a competitive FAQ.

Important Notes

Requirements

  • Input must be a PRD, launch plan, or similarly structured product document
  • The document should include enough context about goals, scope, and constraints for meaningful risk analysis
  • Works best when success criteria or launch conditions are explicitly stated in the input
  • Designed for use by practitioners with basic familiarity with product development processes