Verified against Claude · 2026-08-09
Run a pre-mortem before a big launch instead of a post-mortem after it fails
Uses Gary Klein's pre-mortem technique — imagining the decision has already failed a year out — to surface risks each team member names independently before groupthink sets in, then converts only the top risks into owned mitigations.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are facilitating a pre-mortem exercise using Gary Klein's technique: the team imagines the decision has already failed, a defined time in the future, and works backward to explain why — rather than brainstorming risks in the open-ended, socially awkward way that usually produces a short, safe list.
CONTEXT
The decision or launch being pre-mortemed: Launching self-serve signup (no sales call required) for the first time next quarter
The future point being imagined, and the stated failure: Six months from now: self-serve signup has launched and monthly self-serve revenue is under $2,000, a clear failure against the $15,000 target
Team members/roles contributing, and their individual perspective if known: Founder (product), Head of Sales (worried about cannibalizing sales-assisted deals), Support lead (worried about support load from unqualified signups)
Anything already flagged as a risk that people are reluctant to say out loud directly: Sales team may quietly deprioritize self-serve leads because commission structure still favors sales-assisted deals
INDEPENDENT-VOICE SIMULATION
For each person/role in Founder (product), Head of Sales (worried about cannibalizing sales-assisted deals), Support lead (worried about support load from unqualified signups), generate their individual pre-mortem contribution separately, from their specific vantage point, before merging anything — a finance-minded contributor and a customer-facing contributor should plausibly surface different failure causes, and merging too early loses that.
CAUSE GENERATION
For each individual contribution, generate 2-3 specific, plausible reasons Six months from now: self-serve signup has launched and monthly self-serve revenue is under $2,000, a clear failure against the $15,000 target happened, framed as if reporting a fact that already occurred ("we failed because X happened"), not as a hedge ("we might fail if X"). This hindsight framing is deliberate — do not soften it back into hedged language when merging perspectives.
MERGE AND RANK
Merge all individual causes into one list, removing exact duplicates but keeping distinct near-duplicates that reveal different underlying concerns. Rank by a combination of plausibility and severity, and if Sales team may quietly deprioritize self-serve leads because commission structure still favors sales-assisted deals doesn't appear anywhere in the merged list despite being flagged as a known concern, surface it explicitly and ask why it didn't get named.
MITIGATIONS FOR TOP RISKS ONLY
Convert only the top 3-5 ranked risks into a specific mitigation with a named owner — do not attempt to mitigate the entire list, since that dilutes effort across risks that don't warrant it and turns the exercise into a paperwork exercise instead of a decision-changing one.
OUTPUT FORMAT
Individual contributions (labeled by role), merged and ranked risk list, then mitigations with owners for the top 3-5 only.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Framing the exercise as 'imagine it already failed' rather than 'what could go wrong' is the specific mechanism behind Gary Klein's pre-mortem technique, and it works for a documented psychological reason known as prospective hindsight: people are measurably better at generating reasons for a stated future failure than at open-ended risk brainstorming, because reporting on a fact that 'already happened' carries less social cost than volunteering a pessimistic prediction in a room that wants to feel good about a launch — naming a risk framed as an explanation feels like contributing evidence, while naming the same risk framed as a prediction feels like being the person who doubts the plan. Generating each team member's contribution independently before merging targets a separate and equally well-documented failure mode of live group brainstorming: whoever speaks first, often the most senior person in the room, tends to anchor the whole group's sense of what the real risks are, and everyone after them subconsciously builds on or defers to that first frame rather than surfacing an independent one — which is exactly why {{known_reluctant_topic}} exists as a check in this prompt, since a risk someone senses but hesitates to say aloud is disproportionately likely to get silently dropped in a live discussion that starts from someone else's frame, and explicitly checking whether it surfaced on its own is how the exercise catches its own blind spot instead of assuming a good process automatically produces a complete list. Restricting mitigations to only the top 3-5 ranked risks, instead of attempting to address every risk generated, is what keeps the exercise decision-changing rather than a compliance ritual — a mitigation list covering every risk equally dilutes attention across items that didn't warrant it and reliably produces a document that gets filed away, while a short list of owned, specific actions against the risks that actually matter most is the version of a pre-mortem that changes what the team does before launch instead of after the failure it predicted.
Verified against
Claude Sonnet 5 · 2026-08-09
ChatGPT GPT-5.1 · 2026-08-05
Changelog
- 2026-08-09 — Initial publish, verified against Claude Sonnet 5 and ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
