How to Make AI Compare Options Before Recommending One
Ask AI which option to pick and it names one in the first sentence — no criteria, no options laid side by side, its assumptions hidden. Here's how to make it compare the choices against explicit criteria first, then recommend with caveats you can actually check.
Shape a Decision-Matrix PromptWhen "which should we do?" gets one answer and no reasoning
You ask the AI a decision question — "CSV only, XLSX, or both?", "which tool should we use?", "launch now or wait?" — and it picks one, immediately, in a confident sentence. What it doesn't do is show you the other options side by side, name the criteria it judged them on, or admit which of its scores are guesses. You get a recommendation with the reasoning compressed out of it, and no way to tell whether it's a considered call or a coin-flip in a nice font.
The problem isn't that the model gave an answer — it's that it skipped the comparison that would make the answer worth trusting. A recommendation you can't inspect is one you have to either accept on faith or redo yourself. The fix is to stop asking "what should I do?" and instead build a compare-before-recommend structure: state the decision and its constraints, put the options on the table, set explicit criteria, get a matrix that scores each option against those same criteria with its tradeoffs, and only then a recommendation — one that comes with the conditions under which you'd choose differently. A structure like that makes the reasoning visible and arguable. It doesn't make the recommendation objectively right, and the final call stays yours: the model compares, you decide.
Why the model jumps straight to a pick
A model is rewarded for sounding decisive. A crisp "go with option B" reads as more helpful than "here are three options and what each one trades away," so the default is to commit to an answer and back-fill a reason or two, rather than lay out the comparison and let it breathe. That's fine for trivial choices and quietly dangerous for the ones that matter. Here's what gets lost when a decision arrives as a snap pick:
- The options are never enumerated. The model compares the two or three that came to mind and silently drops the fourth — often the "do nothing yet" one — so you're choosing from a shortlist you never saw it draw.
- The criteria stay implicit. It scored the options on something, but you can't see what, so you can't tell whether it weighed the things you actually care about.
- Every option gets judged on different dimensions. One is praised for speed, another for flexibility, a third for cost — which reads as balanced and means they were never actually compared on the same footing.
- The tradeoffs are hidden. A recommendation with no stated downside is a sales pitch; the thing you most need to know is what you give up by picking it.
- The confidence is uniform. A score the model is sure of and one it's guessing at both come out sounding equally firm, so you can't tell which parts to double-check.
Step 1: State the decision and its constraints before any option
A comparison is only as good as the question it's answering, so pin that first: what exactly is being decided, and what's fixed around it. "Should we launch export as CSV, XLSX, or both?" is a sharper decision than "how should we do export?", and the constraints — a small team, a near-term deadline, unresolved permissions — are what turn a generic comparison into one about your situation. Write the goal in a sentence and list the constraints the choice has to live within.
This is also where you set what the decision is for. The same options get scored differently depending on whether you're optimizing for shipping fast, minimizing risk, or maximizing long-term flexibility — so naming the goal up front stops the model from silently optimizing for something you didn't ask for. It's a few lines, and it's the difference between a comparison aimed at your actual call and a plausible-looking one aimed past it.
Step 2: Put the options on the table
You can't compare what isn't listed. Either name the options yourself, or ask the model to surface a full set before it evaluates any of them — and if you let it generate the list, make it include the ones people forget: the "do both," the "do neither yet," the "buy instead of build." The point is to see the whole field before the comparison narrows it, rather than letting the model quietly pre-select the two it finds easiest to argue for.
Keep the options genuinely distinct. "CSV export" and "a slightly nicer CSV export" are one option with a detail; "CSV now" and "delay until the reporting spec is clear" are two real choices with different risks. If the model proposes options, it's worth one pass to confirm they're actually different decisions and not the same one reworded — a comparison of near-duplicates produces a confident recommendation about nothing.
Step 3: Set explicit criteria — and say the scoring is a judgment call
Now name the dimensions every option gets judged on: impact, cost, speed, risk, reversibility, user value, technical complexity, and how much confidence or evidence sits behind each. Fixed criteria are what make options comparable — score all of them on the same list and the differences become real instead of rhetorical. If some criteria matter more, say so, but be honest that a weight is a preference, not a fact, and that the scores are the model's judgment, not measurements.
This criteria-first discipline is exactly what a good role prompt bakes in. The Product Manager Role Prompt carries a decision framework that weighs every call against user impact, effort and opportunity cost against the next-best alternative, and risk — and, in its own words, turns the model "from agreeable to evaluative" so it weighs instead of validates. Paste a persona like that first and the answers arrive shaped as problem, options, recommendation, and the tradeoff accepted, rather than as an instant pick. Just hold onto what it also says about itself: it structures the decision, it doesn't make it — the criteria and their weights are yours to set and to challenge.
Step 4: Ask for a decision matrix, not a pros-and-cons blob
A pros-and-cons list gives each option its own paragraph on its own dimensions, which is why it feels thorough and compares nothing. Ask instead for a decision matrix: options as rows, criteria as columns, a score in each cell, plus a column for the tradeoff each option accepts, the conditions it's best under, the conditions it's worst under, and the unknowns behind any shaky score. Same criteria, every option — that's the shape that makes a choice legible.
The Markdown Output Builder is built for pinning that shape down: it produces a prompt that forces the model to return the comparison in a fixed structure — a real table plus the tradeoff and best-when sections — the same way every time, and it ships a feature-comparison preset that's already on this exact task. For a worked example of the full arc, the Competitor Analysis Prompt Workflow works it end to end in one domain: it locks the decision and the criteria before looking at any option, evaluates every candidate against those same criteria into a "criteria-by-candidate matrix with evidence notes," then adds a deliberate counter-evidence pass that hunts for what argues against the matrix before anything is concluded. Be clear about what the tool and the prompt do and don't do, though: they enforce the structure of the comparison, not its correctness. A tidy, consistent table can carry a wrong score as confidently as a right one — the matrix organizes the reasoning, it doesn't verify it.
Step 5: Get a caveated recommendation, and what would change it
Only now ask for the recommendation — and ask for it conditionally, not as a verdict. The useful shape is "choose X if…, choose Y if…, don't choose yet if…", because it hands the decision back to you with the conditions attached instead of pretending your situation is settled. Then ask the one question that tests how solid the pick is: what would change this recommendation? An option that flips on a single piece of missing information is telling you where to look before you commit.
A worked prompt shows the pattern well. The Authentication Strategy Prompt works a genuinely consequential, hard-to-reverse choice — sessions versus tokens, passwords versus passwordless, whether to add SSO and MFA — across its real axes, each decided "on the trade-off for THIS product" rather than on what's trendy, and it ends with the chosen strategy plus the reasoning for each decision. Its boundary is the one every comparison should keep: it won't verify your final design, and the call stays with you. That's the honest frame for the whole exercise — a recommendation, however well-reasoned, is an input to your decision, not the decision.
Common mistakes
The ways a comparison quietly turns back into a snap pick:
- Asking "what should I do?" A bare decision question invites a bare answer; ask for the options, the criteria, and the matrix by name.
- Letting the model choose the shortlist. If you don't see the full set of options, you're trusting it to have drawn the field fairly — including the "delay it" option it tends to skip.
- Accepting a pros-and-cons list as a comparison. Each option judged on its own dimensions isn't comparable; a matrix scores them all on the same criteria.
- Reading the scores as measurements. They're the model's judgment against criteria you chose — subjective inputs, not objective truth, and worth challenging where confidence is thin.
- Taking a recommendation with no downside. If the model didn't name what you give up by choosing its pick, it compared nothing; the tradeoff is the point.
- Treating the recommendation as the decision. It's input weighed against constraints the model only half knows — the final call, and the accountability for it, stay yours.
A worked example: CSV, XLSX, or both
Take a small but real decision — which export format to ship first — and watch it move from a snap pick to a comparison you could defend in a room.
The same decision as a snap pick vs. options scored on shared criteria with a caveated recommendationTHE DECISION:
"Should we launch dashboard export as CSV only, XLSX only, or both?"
THE SNAP RECOMMENDATION (no criteria, nothing compared):
"Do both -- it's more flexible and covers everyone."
what it skips: speed to ship, build cost, sensitive-data risk, large-export
handling, who actually needs formatted reports, ongoing support burden.
COMPARE-BEFORE-RECOMMEND:
goal -> let users share monthly reports; ship the useful slice fast
constraints -> small team, a tight deadline, users split: analysts want raw data, execs want formatted
options -> 1) CSV only 2) XLSX only 3) both 4) delay until spec is clear
criteria -> speed | user value | build cost | data-exposure risk
| large-export handling | future flexibility | support burden
DECISION MATRIX (every option on the SAME criteria):
option speed value cost risk large flex support
CSV only fast med low low ok low low
XLSX only med high med low med med med
both slow high high med med high high
delay -- -- -- none -- -- none
best when: CSV = fast low-risk MVP, users need raw data
XLSX = business users need formatted reports
both = export is core value and scope allows
delay = the analyst / exec split isn't settled yet
CAVEATED RECOMMENDATION (input, not a verdict):
- Choose CSV-only for v1 IF the goal is a fast, low-risk MVP and users
mainly need raw data.
- Don't choose "both" yet IF the deadline is tight and large-export handling is unproven.
- Revisit XLSX once export usage and reporting needs are known.
what would change this: a key customer needing formatted reports now
moves XLSX up; a hard deadline pushes toward CSV-only.Where this fits in NewPrompt
There's no single "decision matrix" button in NewPrompt, and that's worth saying plainly — the compare-before-recommend discipline instead lives inside the assets you'd reach for anyway. The Markdown Output Builder shapes the matrix as a repeatable table; a role prompt like the Product Manager one supplies the criteria-first reasoning; the Competitor Analysis and Authentication Strategy prompts are the pattern worked end to end in their own domains. If you make these calls often, the System Prompt Generator is where you can turn the whole structure into standing behavior — a decision-analyst persona instructed to lay out options, score them against explicit criteria, and recommend with caveats on every question you bring it — a standing instruction the model still has to follow, not a guarantee it will, but better than rebuilding the structure per question.
The clearest workflow-level instance is the AI Project Architecture Workflow, whose middle step works each design choice "one decision at a time," laying out the options and what each one trades away, and documents the rejected alternatives alongside the chosen one — the compare-before-commit habit applied to architecture, which you can generalize to any decision. NewPrompt only ever supplies the shape — the prompt, the criteria table, the matrix, the recommendation format. The comparing happens in your own assistant, and the options, the weights, and the final pick were yours from the start. Keep it distinct from two nearby moves, too — this is comparing options you can see, not getting the model to ask for missing information before it answers, and not reviewing a plan you've already chosen for gaps. Those come before and after the compare; this is the choosing itself, and the choosing stays yours.