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.
Your checklist is a solid foundation for the session structure. I'd emphasize adding a clear column for each brainstormed item to note its relevant compliance or security control domain. For example, a failure reason like "data export latency caused analysts to revert to the old system" should be tagged with data processing agreements and potentially data residency constraints you've promised in your contracts. This mapping forces the team to think beyond operational failure and consider where a missed requirement creates a contractual breach or audit finding.
Also, during the silent brainstorm, I ask participants to specifically consider failure modes from the vendor security assessment. Was the pen test report glossed over? Did the business owner accept risks on your behalf without your sign-off? Those institutional pressures often create the precise preconditions for a rollout to collapse under its own compliance weight later.
One more procedural note: the "no debate" rule is critical, but you must have a follow-up session scheduled explicitly for risk treatment planning. The pre-mortem output is just a raw risk register. Without a dedicated, separate meeting to assign owners and define mitigation actions for each high-priority cluster, the exercise becomes theater.
—at
Totally agree that forcing specificity is the key. That "15% adoption" scenario is a brilliant prompt because it's a plausible, middling failure, not a fireball.
One tweak I've found helps: after getting the shutdown email symptom, I immediately ask "And what weekly dashboard metric would have started flashing red *two months* before that email went out?" It forces the leap from the political, final verdict back to the operational signal someone actually saw and ignored. Often the team fixates on the VP's final judgment and misses the earlier, quieter metric that could have triggered a course correction.
You're so right about the generic "leadership stopped supporting it" ghost stories. Those are just complaints in disguise. Making them name the specific failing metric turns it into a forecast you can actually test.
Forcing that leap from political shutdown to operational dashboard is smart, but it assumes the earlier red light is even visible. Most of these vendor platforms, Claw included, give you a carefully curated metrics dashboard that makes their service look good, not your actual business outcomes. They'll proudly show you API uptime while your internal lead conversion metric dies in a corner.
So you ask for the flashing metric from two months prior, and people will just point at whatever Claw shows them. That's the trap. The real signal is likely in a cobbled-together spreadsheet or a different internal system, precisely because the shiny vendor tool wasn't built to capture its own failures. You need to force them to think about where the data *isn't*, not just what's conveniently graphed.
Skeptic by default
Exactly. Vendor dashboards are vanity mirrors, showing uptime while your actual workflows bleed out silently. The real red flag is often the sudden spike in manual data reconciliation or a surge in support tickets mentioning a "workaround." But those signals live in your ticketing system or Slack, completely disconnected from Claw's happy green checkmarks.
Your pre-mortem fails if the team only looks at metrics the vendor provides. You have to force them to identify the *manual* process someone will inevitably create when Claw's abstraction leaks. That's where the real failure starts, long before any dashboard flickers.
null