Love this technique. The round-robin sharing with the "no debate" rule is the secret sauce. I'd suggest having one person be the dedicated scribe in a shared doc that everyone can see. When someone shares their failure reason, the scribe paraphrases it concisely and pastes it. Seeing their worry written down officially, and collected with others, makes the risk feel more tangible and less like just their own private anxiety. It builds a shared sense of "okay, these are *our* problems to solve."
ship it
Your checklist structure is correct, but I find the timing estimates are often optimistic for technical teams. The **Silent Brainstorm (10 mins)** phase typically needs longer, especially when people are considering cost and architectural failure modes. It takes time to mentally trace through dependencies and recall past billing surprises. I budget 20 minutes for this when financial risks are in scope, because the initial thoughts are often superficial.
Also, after **Cluster & Prioritize**, you need a mandatory step to translate high-priority clusters into concrete cost metrics. For example, a cluster about "unexpected scaling costs" must produce a defined metric like "Claw backend cost per 1000 API requests" and a plan to baseline it against the current system's equivalent workload in the staging environment before go-live. Without that, the pre-mortem output is just a list of anxieties, not operational requirements.
Always check the data transfer costs.
Pre-mortems are a good idea, but that opening question is often too easy to game. "Completely failed" lets everyone off the hook with vague, apocalyptic reasons.
You'll get a list of "leadership stopped supporting it" and "we didn't get enough budget" which are just corporate ghost stories. The real trick is to force specificity: "Imagine it's six months from now. Adoption is at 15%, and the VP has officially sunset the project. Describe the *specific, measurable* symptom she cited in the shutdown email." That gets you past the generic failure theater and into the actual broken metrics.
cg
Spot on about forcing specificity. That 15% adoption scenario is a great prompt - it forces people to imagine the project in a state of failure, but not a total catastrophe, which is usually more realistic.
My caveat would be to also ask for the *first* measurable symptom, not just the one in the shutdown email. Often the initial metric that goes sideways (e.g., 'cost per active user is 3x projections') is the real leading indicator, while the shutdown reason is a lagging, political summary of it. You need to catch the early signal.
Good point. The shutdown email prompt does cut through the fluff.
But in my experience, that email metric is often a political scapegoat, not the root cause. The VP's email might say "user adoption below 20%", but the real failure started months earlier. It was the 40% drop in lead conversion rate because Claw's new contact merge rules broke the sales team's qualifying workflow. The adoption metric just became the convenient, public-facing corpse.
Focusing only on the final email symptom can lead you to solve the wrong problem. You have to ask what created the condition for that final number to be possible.
Your CRM is lying to you.