Ask it why this will fail. Then don’t believe it.
A model will give you five confident reasons your idea is doomed. Some are real. Some it invented to be helpful. The skill is telling them apart.
What changed
Pre-mortems used to be hard to run because people are polite. Nobody wants to be the one who says the sponsor’s favourite idea won’t work. The model has no such problem. It will attack anything, instantly, in bullet points.
That’s useful. It’s also dangerous, because a well-written objection feels like evidence, and the model writes well. The facilitator’s job moved from getting objections out of people to deciding what to do with objections that arrive for free.
The skill
Treat every AI-generated criticism as a question to investigate, never as a finding. Then sort the questions into three bins, so the room knows what to do with each one.
| Check today | Needs a customer | Noise |
|---|---|---|
| We have the data, the person or the system in the room. Answer it before 4pm. | Only a real person can answer this. Becomes a test question for Day 8. | Generic, unfalsifiable, or true of every idea ever. Bin it, and say why. |
| “The regulator won’t allow pre-bill calls” → ring compliance now. | “Customers will ignore a call from an unknown number” → put it in the test script. | “Adoption may be slow” → noise. |
Fig. 5 — The triage board. Every objection gets exactly one home.
The prompt is simple. Paste the brief and the chosen idea, then: “Give us the eight most likely reasons this fails in practice. For each one, say what would have to be true for it to be a real problem, and what evidence would show it.” The second half of that prompt matters. It makes the model expose its own assumptions, which makes the sorting faster.
Then the room sorts. Facilitator reads each objection out. The team puts it in a bin. If they argue about which bin, that’s a good sign; it means they’re engaging with it as a question rather than a verdict.
What goes wrong
The first failure is putting everything on the wall as “risks”. We did this early on. The sponsor saw eight risks on a wall and got nervous, and the idea got quietly downgraded by the end of the day. Nothing had been checked. The model had written a list and the list had become real.
The second failure is the opposite: dismissing the lot because “it’d say that about anything”. It would. Some of what it says is still right. In the high-bill sprint the model flagged a dependency on the billing system’s data lag that nobody in the room had thought about. It went in “check today”, someone rang the data team, and it changed the design.
The third is subtle. The model is better at generating objections than at weighting them. It will give equal confidence to a fatal regulatory block and a mild UX niggle. The weighting is human work.
Run it Monday
- After the idea is chosen, run the eight-objections prompt. Ask for “what would have to be true” with each.
- Draw three columns on the wall. Sort as a group. Every objection gets one bin.
- “Check today” items get a name and a time. “Needs a customer” items go straight into the test script.
- Bin “noise” visibly and say why. The team needs to see you not believing the model.
An AI objection is a question to examine, not evidence by itself.
If this sounds like your organisation. Most of the AI pilots we see stall right here: confident analysis, no mechanism for checking it. A HyperSprint is two days of exactly this, on one real workflow, with real customers at the end. If you’d rather talk it through first, get in touch.
The stress-test prompt and the triage board are in the facilitation deck.
