Six months from now, the launch described below failed. Work backward and produce three layers:
1. Causal failure: the proximate reason it failed (an adoption number, a metric drop, a user reaction).
2. Upstream cause: what was true earlier that made the proximate failure inevitable. The decision, gap, or assumption upstream of the proximate cause.
3. Early warning sign: something I could observe today (in the beta, in interviews, in current data) that would predict this failure.
Then propose one concrete mitigation I could implement this week to address the early warning sign.
Do not constrain the failure mode in your reasoning - if you find a failure I didn't predict, name it.
The launch:
{{launch_description}}
Pre-mortem: assume the launch failed
Add to PromptPaste
Download PromptPaste for MacDownload PromptPaste for iPhoneDownload PromptPaste for iPadDownload PromptPaste for Mac & iPhone
the prompt
Example output
Six months from now, the cross-device sync launch failed. Here's why:
Causal failure: Activation rate of opt-in sync stayed below 8%. Without enough users on it, we couldn't measure the retention impact. The feature shipped, was used by a fraction of the cohort, and got cut in Q3 planning.
Upstream cause: We launched it as opt-in with no in-product nudge. Our power users didn't discover the setting on their own because it lives in a settings sub-menu they never visit. The opt-in vs. opt-out debate consumed all our risk-management attention and we forgot the discovery mechanism entirely.
Early warning sign you can see today: in the current beta, opt-in rate without a discovery prompt is ~5%. With even a one-time toast on app launch, beta opt-in jumps to ~35%. We have the data; we just need to ship the toast.
Mitigation this week: add a one-time in-app toast on first launch after the feature ships, prompting power users (>10 sessions/month) to enable sync. Two-line eng change.
Common mistakes
Don't constrain the failure scenario ('assume it failed because of pricing'). That gets you a defense of pricing dressed as a pre-mortem. Let the model invent the failure. Also: this prompt produces uncomfortable findings. The mistake is acknowledging them in the chat and ignoring them in the launch plan. Either change the plan or write down explicitly which risks you're knowingly accepting - so the postmortem six months later doesn't read as 'we never thought of this.'
More from AI Prompts for Product Managers
PRD draft from a one-line problem
Act as a senior product manager. I'm going to give you a one-line problem statement. Before drafting any PRD, do this: 1. State the…
Customer interview synthesis
Read the raw customer interview transcripts below. Produce: 1. The top 5 themes ranked by frequency (number of interviews where the theme…
Stakeholder weekly update
Convert my raw bullets below into a weekly stakeholder update. Use exactly three sections: 1. Shipped: each item with a one-line outcome,…
Why it works
Pre-mortem is the single most under-used PM decision tool. The format: assume the launch failed, then work backward to find why. AI is unusually good at this because it has no skin in the game - it'll surface failure modes you'd defend against if asked directly. This prompt structures the pre-mortem into three layers: causal failure (the proximate reason), upstream cause (what was true earlier that made the proximate failure inevitable), and early warning sign (what you can observe today that would predict the failure). Run this before any launch and you'll either change the plan or write down knowingly which risks you're accepting. Tested cleanest on Claude Opus 4.7. (See also: the universal pre-mortem in the Power Prompts pack - this is the PM-specific version with launch-shaped failure modes.)