Ask What Would Change the Recommendation

A follow-up move after Claude recommends an option: ask what would have to be true — or different — for it to change its recommendation. You're probing how robust the choice is by finding the assumptions and thresholds it actually hinges on.

A recommendation on its own tells you the conclusion but not its stability. Two 'go with option A' answers can be worlds apart: one holds across almost any reasonable assumption, the other flips the moment a single number moves. Asking what would change it surfaces exactly which assumptions are load-bearing — 'A wins unless your monthly volume exceeds 10k, then B pulls ahead.' Now you can check the one fact that decides it, rather than trusting or distrusting the whole answer wholesale. It turns a verdict into a map of when the verdict holds.

After any recommendation you're going to act on, especially close calls or high-stakes choices. Also whenever an answer feels suspiciously clean — asking what would flip it either confirms the choice is robust or reveals the fragility the confident tone was hiding.

Trivial or easily-reversible decisions where the cost of being wrong is tiny — interrogating the robustness of a low-stakes call is more ceremony than it's worth. Save it for choices that are hard to undo.

You recommended <option>. Now stress-test it: what would have to change for you to recommend something else instead? Name the specific assumptions or thresholds this choice depends on, how close each is to flipping, and which one fact I should verify because the decision hinges on it most.

Claude recommends building in-house over buying. You ask what would change it, and it answers: 'If your timeline is under two months or you lack a backend engineer, buying wins.' Both are true for you — so the real recommendation flips. The initial answer wasn't wrong; it rested on assumptions you hadn't stated, and one question exposed the hinge the whole decision turned on.

Combine this with a weighted scorecard: after scoring, ask which criterion or weight the ranking is most sensitive to, then verify the real-world value of exactly that factor. You spend your effort confirming the one input that decides the outcome, instead of second-guessing the whole analysis — targeted verification driven by where the decision is actually fragile.

• Accepting a recommendation without knowing which assumptions it depends on, then being blindsided when one turns out false.
• Treating a confident tone as robustness — fluency says nothing about how easily the conclusion flips.
• Asking what would change it but not then verifying the hinge fact it names, so the insight goes unused.