Make Claude Name the Trade-offs, Not Just the Winner
What it is
A decision pattern where you make Claude lay out the trade-offs of a design as an explicit table — options as rows, the criteria you care about as columns — instead of just handing you a recommendation.
Why it works
A bare recommendation hides the reasoning that produced it, so you can't tell whether it weighed the things you care about or something else. Forcing the trade-offs into a table exposes the axes — cost, complexity, latency, reversibility — and lets you catch a bad weighting. It also makes the decision reviewable by teammates who weren't in the conversation.
When to use it
Any judgement call where reasonable engineers would disagree, and where you'll have to defend the choice later — build vs buy, library selection, database engine, a schema you'll live with.
When not to use it
When the criteria are obvious and one option dominates on all of them. A table adds nothing when there's no real tension to expose.
Prompt
We're deciding between <options> for <purpose>. The criteria I care about, most important first, are: <list, e.g. operational simplicity, cost, latency, team familiarity>.
Build a trade-off table: options as rows, my criteria as columns. Fill each cell with a short concrete judgement, not just good/bad. Flag any cell where you're uncertain. Then give a recommendation that follows from the table and name the one criterion that decided it.Example
Choosing a background-job library, you list operational simplicity, throughput, and observability. The table shows the flashy option wins on throughput but loses badly on operational simplicity — your top criterion — so the boring choice wins, and everyone can see exactly why.
Advanced version
Ask Claude to add a 'what would change this decision' row: the single fact about your scale or team that, if different, would flip the recommendation. That row tells you what to go measure before committing.
Common mistakes
- Letting Claude pick the criteria — you should name what matters, or the table optimises for the wrong things.
- Accepting vague cells like "good" or "scalable"; demand a concrete, comparable judgement in each.
- Treating the table as objective truth — the weights are yours, and the honest table makes them visible rather than hiding them.