Options, Not Answers
Bring two or three real options, each with what it costs, and say which you recommend. Never bring only the recommendation — and never bring options without one.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
When you bring a decision to someone, are you giving them a choice or asking them to approve yours?
The PM, on a Monday: "Can we get Apple Pay into checkout before Black Friday? Marketing wants it on the campaign page."
Work out the best way to do it, estimate it, and come back with the answer: "Yes, three weeks, here is the plan." Or, if it will not fit: "No, not before Black Friday." Either way, one clear answer.
"Three weeks" lands without context. The PM does not know that a one-week version exists with a different cost, so they either accept the three weeks and cut something else, or push back on the estimate — and the conversation becomes about your estimating instead of about what to build.
- "Three weeks" lands without context. The PM does not know that a one-week version exists with a different cost, so they either accept the three weeks and cut something else, or push back on the estimate — and the conversation becomes about your estimating instead of about what to build.
- "No" closes the conversation. Marketing hears that engineering blocked Apple Pay, not that there was a cheaper option with trade-offs they might have accepted.
- A single answer hides the judgement you made. You decided a hosted payment page was unacceptable because it redirects customers away from the store — but that was a product call about brand and conversion, and it was not yours to make alone.
- When the single answer turns out wrong, it is entirely yours. When you brought options and the PM chose, it is a shared decision with a shared record.
What is really going on
- Engineers usually know the cost structure of a request better than anyone else in the room: which parts are expensive, which are cheap, which constraints are real. A single answer throws that knowledge away and keeps only its conclusion.
- Presenting options moves the product judgement to the person who owns it, while keeping the engineering judgement with you. The PM decides whether a redirect is acceptable; you decide what each option actually costs.
- The recommendation is not optional. Options without a recommendation hand the other person all the work and hide your view — which you have, and which they need. "Here are three options, you choose" is abdication dressed as humility.
- Real options differ in what they give up, not only in how long they take. "Fast, medium, slow" versions of the same thing are one option at three prices. "In our checkout", "on the provider's page", and "after Black Friday" are three options.
A single answer hides the judgement
"Yes, three weeks" contains a hidden decision: you ruled out the hosted payment page because it sends customers away from the store. That might be the right call, but it is a call about brand, conversion and customer trust — the PM's and the designer's territory. By answering instead of offering, you made it for them without telling them.
Options surface the judgements that belong to other people and keep the ones that belong to you. You still decide what each option costs. They decide which cost they would rather pay.
Monday. The PM asks if Apple Pay can be in checkout before Black Friday, four weeks away, with a code freeze in three.
"Realistically no. A proper integration is three weeks plus testing and we freeze in three. Maybe early next year."
"Three ways to do it. One: fully inside our checkout — three weeks, which lands the day before the freeze with no buffer on our busiest path. Two: the provider's hosted payment page, which has Apple Pay built in — about a week, but customers leave our checkout to pay and the page will not look like ours. Three: after Black Friday. I would do two for Black Friday and move to one in January; the cost is the off-brand payment step for six weeks, so I would want design to look at it before we commit. Does marketing need it on all of checkout, or just on the campaign page?"
What makes an option real
Options are only useful if they are genuinely different ways of solving the problem, each one you would be willing to build. The test is what each gives up.
A: Apple Pay in checkout, polished (4 weeks). B: Apple Pay in checkout, standard (3 weeks). C: Apple Pay in checkout, minimal (2 weeks, some bugs).
A: In our checkout (3 weeks, tight against the freeze). B: Provider-hosted page (1 week, customers leave our page). C: After Black Friday (no risk to peak, marketing loses the headline).
The first set asks the PM to pick a quality level, which they cannot judge. The second asks them to pick a cost — schedule risk, brand, or timing — which is exactly the judgement they own.
The recommendation is not optional
Options without a recommendation look humble and work badly. The decider now has to judge risks they cannot see, and will usually pick the cheapest-looking option or the one presented most confidently. Your view is the most informed one in the room about costs; withholding it is not neutrality.
Say it plainly, after the options, with its cost: "I recommend B, and the cost is that the payment step looks like the provider's for six weeks." Then say what would change your mind. That last sentence is what makes it a recommendation rather than a verdict (Disagree and Commit).
Does this request need options, or just an answer?
when The choice is engineering-internal, cheap to reverse, and nobody outside the team pays for it.
cost None, unless you misjudged who pays — which is why the "who pays" check comes first.
when One option is clearly right, but a reasonable person might have expected another.
cost One sentence: "Doing X; not Y because Z."
when The options differ in what customers, support or finance experience, or the cost lands outside your team.
cost An hour of preparation and a decision you may not get to make yourself.
Always consider "not now"
"After Black Friday" is an option, and often the one that makes the others honest. Without it, the conversation is about how to squeeze the work in; with it, the conversation is about whether the work is worth squeezing in at all.
It also gives the decider an easy yes that is not a no. "Not now, with a waiting list so we know demand" is a decision; "no" is a wall (Saying No Well, Sequencing Work So Value Lands Early).
How to do it
Most important first.
- Bring two or three options. One is an answer; four or more is a menu the decider cannot hold in their head.
- For each option, state what it gets us, what it costs, and who pays — in the decider's units: weeks, customer experience, support load, money (Naming the Trade-off).
- Include "not now" or "do nothing" as an option whenever it is honestly viable. It is often the one that makes the others look properly priced (Saying No Well).
- Say your recommendation and why, in one sentence, after the options — and say what would change it.
- Check that every option is one you would actually build. If you would refuse to ship option A, do not present it; strawmen poison the trust in the real ones.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Open with the frame: "There are three ways to do this, and they differ in what customers see, not just in how long they take."
- Walk the options in the decider's terms: "Option one keeps customers in our checkout and takes three weeks. Option two takes a week but sends them to the provider's page to pay. Option three is after Black Friday, when the freeze lifts."
- Give the recommendation with its cost: "I would pick the provider page for Black Friday. The cost is that the payment step will not look like ours, which design will not love — I have asked them."
- Say what would change it: "If marketing only needs Apple Pay on the campaign landing page and not all of checkout, there might be a smaller version still — worth a two-minute check with them."
- "I do not want options, I want you to tell me what to do." Fair — the recommendation is option two, first line. The options are there so you can see what it costs compared to the alternatives, in thirty seconds.
- "Just do the best one." The best one depends on whether customers leaving our checkout is acceptable, which is your call, not mine. Everything else I have decided.
What can go wrong
- The strawman set: one real option flanked by two absurd ones, so the "choice" is obvious. People notice, and discount everything you bring afterwards.
- The menu without a chef: options without a recommendation, leaving a non-technical decider to guess which risk matters.
- Options too late: presenting options after you have already started building one, so the choice is theatre.
- Options that differ only in engineering taste (library A or library B) brought to a product decision-maker who cannot evaluate them. Decide those yourself.
- "Options means I should not have an opinion." The opposite: the recommendation is the most useful sentence in the message. Options are the evidence for it.
- "More options is more thorough." Past three, the decider stops comparing and starts guessing.
- "If I give options, I am avoiding responsibility." You are taking responsibility for the costs being right and the recommendation being yours; you are giving away only the part of the decision that was not yours.
Knowing whether it worked
- The PM chooses an option you did not recommend, and the reason is a product reason you did not know. That is the practice working.
- Fewer conversations about "why is the estimate so high?" and more about "which of these do we want?"
- People start bringing you requests earlier, before they have a date attached, because you turn requests into choices instead of verdicts.
- When a chosen option goes wrong, the retrospective discusses the choice, not the engineer.
- On a small team, options are a two-minute Slack message. As decisions involve more people, they become the options table in a one-pager (The One-Pager). The shape stays the same.
- At 10x team size, the engineer closest to the work is increasingly far from the person who decides. Options are what let that decider use the engineer's knowledge without being in every conversation.
- At 10x revenue, the product consequences of each option (conversion, support load) matter more in absolute terms, which makes it more important, not less, that the person who owns them makes the call.
- It takes longer to prepare. Three options costed honestly is more work than one plan.
- It gives away control. The PM may choose the option you like least, and you will build it.
- It can slow a simple decision. Not everything needs options; bringing three for a copy change wastes everyone's time.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALWherever the person deciding is not the person who knows the costs. It flips in an incident or a genuine emergency, where one clear answer now beats three options in ten minutes.
- TEAM-SPECIFICWith a PM, options go to the PM and the product call is theirs; without one, options go to whoever owns the outcome — a founder, a lead — and the engineer often makes the call with the options as the written reasoning.