product-premortem

name	product-premortem
description	Explicit-only skill for product and business premortems. Use this skill only when the user explicitly invokes "$product-premortem", "use product-premortem", "run a product premortem", "product-premortem this", "premortem this launch", "premortem this pricing change", "haz un product-premortem", or "premortem de producto". Stress-test a product, launch, pricing change, positioning shift, hire, partnership, strategy, or business decision before commitment by assuming it failed and working backward. Do NOT trigger on broad phrases like "what could go wrong", "am I missing anything", "poke holes in this", simple feedback requests, ordinary product/design discussion, LLM Council requests, or multi-perspective requests unless the user explicitly asks for product-premortem.
license	MIT
metadata	{"version":"0.1.0"}

Product Premortem

A product premortem assumes the product, launch, pricing change, positioning shift, hire, partnership, strategy, or business decision has already failed. Work backward from that failure to expose blind spots, hidden assumptions, and concrete changes that make the plan more resilient.

This skill is explicit-only. If the user asks for normal feedback, design critique, brainstorming, or "what could go wrong" without explicitly invoking this skill, do not use it.

When To Use

Use only when the user explicitly asks for a product premortem with one of the trigger phrases in the description.

Good product premortem targets:

• A product or feature launch
• A pricing, packaging, or business model change
• A positioning, messaging, or go-to-market shift
• A hire, partnership, vendor, or deal decision
• A product strategy or roadmap bet
• Any product/business commitment where the cost of being wrong is high

Do not use for:

• Vague ideas with no concrete plan yet; help clarify the plan first
• Simple feedback on copy, UI, docs, or drafts
• Questions with one factual answer
• LLM Council or multi-perspective requests
• Technical implementation risk; use development-premortem only if explicitly requested

Context Threshold

Before running the premortem, gather only the minimum context needed. Scan the current conversation and any user-provided files first. If one of these is missing and cannot be inferred, ask one focused question at a time:

1. What is it? A one-sentence description of the product/business decision.
2. Who is it for or who does it affect? Customer, user, buyer, internal team, stakeholder, or partner.
3. What does success look like? Revenue, adoption, retention, trust, time saved, approval, learning, or other target outcome.
4. What constraints matter? Deadline, budget, distribution channel, brand risk, team capacity, stakeholder pressure, or market timing.

If the user has provided enough context, proceed immediately and state any assumptions.

Workflow

Step 1: Set The Frame

State the frame explicitly:

It's 6 months from now. [The product/business decision] failed. It did not reach the intended users, business outcome, or stakeholder goal. We're looking back to understand how it died.

Use 6 months as the default horizon. Adjust only when the user gives a different launch window or decision horizon.

Step 2: Generate Failure Reasons

Generate every genuine failure reason that fits this specific plan. Do not force a fixed count. Some plans have 4 real failure modes; others have 9.

Each failure reason must be:

• Specific to the user's plan, not generic business advice
• Grounded in the context provided
• A real threat, not a minor inconvenience
• Stated in 1-2 direct sentences

Use these product lenses as prompts, not headings unless they help:

• Market timing and category maturity
• User adoption and behavior change
• Buyer/user mismatch
• Positioning and messaging clarity
• Pricing, packaging, and willingness to pay
• Distribution and acquisition channels
• Trust, credibility, and proof
• Operational readiness and support load
• Stakeholder incentives and approval friction
• Competitive alternatives and switching costs

Step 3: Deepen The Important Failures

For each major failure reason, produce a short deep dive:

### [Failure Reason]

**Failure story:** [2-3 paragraphs explaining how this failure played out.]
**Underlying assumption:** [The hidden assumption that made this failure possible.]
**Early warning signs:** [1-2 observable signals.]

If multi-agent delegation is available and the task is high stakes, run independent deep dives in parallel. Otherwise perform the deep dives inline while keeping each failure independent.

Step 4: Synthesize

Produce the synthesis first; this is the product of the premortem:

# Product Premortem: [Plan Name]

## Synthesis

**Most likely failure:** [The failure most probable given the plan.]

**Most dangerous failure:** [The failure with the largest downside.]

**Hidden assumption:** [The single assumption most likely to be wrong or untested.]

**Single most important revision:** [The one concrete change that would most improve the plan.]

## Revised Plan

1. [Concrete change mapped to a failure mode.]
2. [Concrete change mapped to a failure mode.]
3. [Concrete change mapped to a failure mode.]

## Pre-Launch Checklist

- [ ] [Specific thing to verify, test, or put in place.]
- [ ] [Specific thing to verify, test, or put in place.]
- [ ] [Specific thing to verify, test, or put in place.]

## Failure Analysis

[Failure deep dives.]

## Assumptions

- [Assumption made because the user did not provide enough detail.]

Artifact Mode

Default to Markdown in chat. Generate an HTML report or transcript only if the user explicitly asks for a report, artifact, file, or saved transcript.

When artifact mode is requested:

• Save product-premortem-report-[timestamp].html
• Save product-premortem-transcript-[timestamp].md
• Keep the HTML self-contained with inline CSS
• Put the synthesis at the top
• Include one scannable card per failure reason

Quality Bar

• Do not sugarcoat serious problems.
• Do not pad the analysis with weak failure modes.
• Do not say "consider testing"; name the test, audience, price, channel, or threshold.
• Do not end with abstract advice. End with concrete revisions and checklist items.
• Keep the tone direct, useful, and grounded in the user's actual plan.