ع
Learn Tracks Reference Guides Saved
playbook

Compare solution options and land on one

Score 2-4 candidate solutions against the same criteria — cost, effort, risk, time-to-value — and get a defensible recommendation, not a pros/cons list nobody can act on.

medium ~35 min
when to reach for this

The gaps are named, and now there are 2 to 4 plausible ways to close them — a quick patch, a middle-ground fix, a full build, maybe a vendor. Each one sounds reasonable described on its own, which is exactly the problem: a pros/cons list where every option gets its own framing lets the loudest advocate win. Options analysis forces every candidate onto the same scorecard — cost, effort, risk, time-to-value — so the comparison is honest and the recommendation is something you can defend to whoever signs off. This is a Claude Desktop conversation, grounded in the requirements doc and the gap analysis, no terminal needed.

gather this first
  • Your requirements.md and gap-analysis.md — the options are only worth comparing against what the business actually needs and what's actually broken, not a generic feature list.
  • The candidate options themselves, even roughly sketched — "do nothing but tweak policy," "build a self-serve tool," "buy a vendor product" — 2 to 4 is the useful range; more than that usually means two of them are the same option in disguise.
  • Whatever you know about each option already — a vendor quote, a rough engineering estimate, a policy someone mentioned — so Claude works from real numbers instead of guessing them.
the workflow

  1. Name the options and the criteria before scoring anything

    Open requirements.md, gap-analysis.md, and your rough option notes in Claude Desktop. Before comparing, make Claude restate each option in one sentence and confirm the criteria — a comparison against the wrong criteria is worse than no comparison.

    you ask
    Read requirements.md and gap-analysis.md. Here are the candidate options I'm considering: [list them, roughly]. Restate each option in one clear sentence, then propose the criteria we should score them on — cost, effort, risk, time-to-value, and anything else the requirements doc implies matters here. Flag if any two options are actually the same thing described differently.

    what you get back A clean restatement — "Option A: patch the policy so a backup approver can sign off. Option B: build a self-serve status-check tool. Option C: full self-serve returns flow including refunds." — plus confirmed criteria, and a flag if two options collapse into one.

  2. Score every option against the same criteria

    Same table, same columns, every option judged on identical terms. This is what stops each option from being described in its own most flattering language.

    you ask
    Score each option against our criteria — cost, effort, risk, time-to-value — in a single table, one row per option, one column per criterion. For cost and effort, use the real numbers I gave you where I have them, and clearly mark any figure you're estimating rather than sourced. Be honest about each option's weak points — don't flatten the differences to make them look similar.

    what you get back A scannable table: "Option A: cost ~$0 (policy change), effort 1 day, risk low, time-to-value immediate — but doesn't reduce ticket volume. Option C: cost $80K (est.), effort one quarter, risk medium (needs Eng + Finance), time-to-value slow — but solves the gap end to end." Every cell traceable to a real number or clearly marked as an estimate.

    An estimate presented as a fact is how options analyses go wrong later. Make Claude flag every guess so you know what to verify before it's in front of a decision-maker.

  3. Name what each option doesn't solve and who signs off

    Cost and effort tell you what an option takes; this step tells you what it leaves broken and who has to approve it. Both belong beside the scores, not left implicit.

    you ask
    For each option, add two things: what it explicitly does NOT solve from the gap analysis, and exactly who would need to sign off before it moves to build (name a role or a named stakeholder, not just a team). Leave the sign-off blank if you genuinely don't know who it should be.

    what you get back "Option B doesn't handle refunds at all — status visibility only. Sign-off: Engineering lead + Support manager. Option C solves the gap end to end. Sign-off: Engineering lead, Finance (budget), and Ops (process owner) — all three, not one." Now the comparison shows what's left broken, not just what's spent.

  4. Get a recommendation and what would flip it

    The reasoning is what makes a recommendation defensible. Ask for the pick, the tradeoff, and the one thing that would change the answer — that last part is what a skeptical stakeholder will actually ask.

    you ask
    Given the scores and our stated priorities [state them, e.g. "we need something shippable this quarter, cost is secondary"], recommend one option. Explain why it wins on our priorities, what we give up by picking it, and what would have to change for the recommendation to flip to a different option.

    what you get back "Recommend Option B: only path that ships this quarter and closes the highest-priority gap (self-serve status) at moderate risk. We give up full refund automation for now. This flips to Option C if the priority shifts from 'ship this quarter' to 'solve the gap completely,' or if Finance approves a larger budget."

    The "what would flip it" line is the part worth keeping — it tells a skeptical stakeholder exactly which assumption to challenge instead of re-litigating the whole comparison.

  5. Write the options-analysis.md and route it to sign-off

    Package the comparison, the recommendation, and the open sign-offs into one file — this becomes the direct input to the business case.

    you ask
    Assemble this into options-analysis.md: the options restated, the scoring table, what each doesn't solve, sign-off needed per option, the recommendation with its reasoning, and what would flip it. Show me the diff before saving.

    what you get back Claude shows the new file as a diff — you review it, click accept, and options-analysis.md is saved: a defensible, side-by-side comparison ending in a named recommendation, ready to feed the business case.

make it your own
  • Only one option feels real: even when there's an obvious favorite, score at least one deliberate alternative (including "do nothing") against the same criteria — a recommendation that was never actually compared to anything is not an analysis, it's a preference.
  • Build vs. buy: if one option is building in-house, pair this with Read your codebase in plain English first, so the build option's cost and effort are grounded in what the change would actually touch, not a guess.
  • High-stakes or contested pick: have Claude argue the strongest case against its own recommendation before you circulate it — a pick that survives its own best counter-argument travels better into a room with a skeptical stakeholder.
  • Feeds the business case directly: options-analysis.md is the direct input to a one-page business case for leadership — bring it in along with requirements.md so the case is built on an already-defensible comparison, not a fresh argument from scratch.
watch out for
  • An option nobody named a sign-off for is the one that stalls. Every option needs a real name or role attached to its approval, not just "Engineering" or "leadership" — a vague sign-off column is how a recommendation dies quietly in committee.
  • Estimates dressed as facts are the riskiest thing in the table. A cost or effort figure Claude inferred from context is a guess until someone verifies it — mark every estimate clearly and check the ones that matter before the recommendation is circulated.
  • Claude recommends; a named stakeholder decides. The recommendation is a well-reasoned input weighted by the priorities you gave it — it is not a decision until someone with the authority to approve the option puts their name on it.
  • Don't let the criteria get chosen to fit a favorite option. If cost, effort, risk, and time-to-value happen to rank in exactly the order that favors the option you walked in wanting, ask Claude to sanity-check whether the criteria were set before or after you saw the scores.

you'll end up with An `options-analysis.md` — 2 to 4 options scored against the same criteria with sourced or clearly-flagged numbers, what each option leaves unsolved, the sign-off each needs, and a recommendation with its reasoning and what would flip it — a comparison you can defend in the room, ready to feed straight into the business case.

Questions people ask

How many options should I compare?
Two to four is the useful range. Fewer than two isn't a comparison; more than four usually means two of your "options" are the same idea described differently — ask Claude to check for that before scoring, since it collapses the table and sharpens the real choice.
What if I don't have real cost or effort numbers yet?
Give Claude what you do know and ask it to estimate the rest, clearly marked as estimates rather than sourced figures. The scoring table is still useful as a first pass, but verify any estimate that's doing real work in the recommendation before you circulate it — a wrong number under a confident table is worse than a visible blank.
Does the recommendation replace my judgment?
No — it's a structured input weighted by the priorities you stated, not the final word. You still decide whether those priorities are right for this moment and whether to accept the tradeoff the recommendation makes. Nothing here is a decision until a stakeholder with real authority signs off on the chosen option.
How does this connect to the business case?
Options-analysis.md is the direct input — the recommended option, its reasoning, and its sign-off requirements carry straight into the one-page business case for leadership. Running this well means the business case starts from an already-defensible comparison instead of building the argument from scratch.