Naming the Trade-off
Every real decision rejects something. Say what you gave up, who pays for it, and why that price is worth it — before someone else discovers it for you.
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 explain a decision, can you say out loud what you chose not to have?
The PM, in the checkout channel: "Quick one — why are we reserving stock at payment and not when it goes in the cart? Finance is asking."
Explain why the chosen option is good. Reserving at payment keeps stock available for people who are actually buying, it is simpler, and it is what most shops do. List the benefits, sound confident, move on.
Finance was not asking about benefits. They were asking because three refunds last Saturday came from people who paid for the last unit of a jacket and were then told it was sold out. The answer that lists only benefits sounds like you did not know about the refunds — or knew and hoped nobody would ask.
- Finance was not asking about benefits. They were asking because three refunds last Saturday came from people who paid for the last unit of a jacket and were then told it was sold out. The answer that lists only benefits sounds like you did not know about the refunds — or knew and hoped nobody would ask.
- A decision explained only by its upside invites the question "then why did we not also do the other thing?", and the conversation restarts from zero every time someone new asks.
- The cost you did not name gets named by someone else, later, in a worse room. "Engineering knew this would happen and did not tell us" is a sentence that costs more trust than the refunds cost money.
- Without a named trade-off there is nothing to revisit. When the jacket sells out at every drop, nobody can say "the condition we accepted has changed", because nobody wrote down the condition.
What is really going on
- A decision is a choice between costs, not between a good option and a bad one. If one option were free and the other expensive, nobody would have needed to decide. The fact that it took a meeting means something was given up.
- The rejected option has a constituency. Somebody would have preferred it: support would prefer no oversold refunds; merchandising would prefer no stock locked in abandoned carts. Naming the trade-off is naming whose preference lost, and why.
- Unnamed costs do not disappear; they move. They move to support, who answer the "sold out after I paid" email; to finance, who reconcile the refund; to the next engineer, who "fixes" the oversell and reintroduces the locked-stock problem you chose against.
- Naming the trade-off turns a verdict into an argument someone can check. "We accept occasional oversells on the last unit because holding stock for abandoned carts would block real buyers more often" can be tested against data. "Reserving at payment is better" cannot.
Every real decision has a loser
If a choice had no downside, nobody would have scheduled a meeting about it. Reserving stock at payment was chosen over reserving at add-to-cart, and the losing option had real advantages: nobody would ever pay for something that was already gone. Choosing against it means accepting that, sometimes, someone will.
The engineers who are trusted with bigger decisions are not the ones who are always right. They are the ones whose explanations already contain the cost, so that when the cost shows up, it is a known quantity instead of a revelation.
We reserve at payment because it keeps inventory available for customers who are ready to buy. It is simpler and it is the industry-standard approach.
We reserve at payment, not at cart. We accept that on a busy drop a few customers pay for the last unit and get an automatic refund. We did it because reserving at cart would lock stock in carts that never check out, which on a normal day blocks more real buyers. We would revisit for limited-release items if a drop sells out in minutes.
The second version survives the first oversell refund: finance reads it and sees a cost that was predicted and priced, not a bug that was hidden.
The sentence shape
"We chose X over Y. We accept Z. We did it because W. We would revisit if V." It is not elegant, and that is the point: it is hard to say without actually knowing Y, Z and V. If you cannot fill in the "accept" clause, you have not finished deciding — you have found the option you like.
Use it out loud in standup, in a PR description, in a Slack reply to the PM. It scales down to one line and up to a decision record without changing shape (Decision Records).
The PM asks in the checkout channel why stock is reserved at payment. Finance is watching the thread because of last weekend's refunds.
"Reserving at payment is the standard approach and keeps inventory free for real buyers. The refunds were an edge case, I can look into it."
"We reserve at payment instead of at add-to-cart. The cost we accepted is exactly what happened Saturday: on the last unit, two people can both pay and one gets refunded. We chose it because cart reservations lock stock in abandoned carts, which on a normal day blocks more sales than drops refund. If limited drops keep selling out like this, I would switch those items to cart reservation with a ten-minute hold — about three days of work. Want me to write that up?"
Costs people hide without meaning to
Most unnamed trade-offs are not concealed; they are just not in the engineer's field of view. The cost lands on someone the engineer never talks to. Checking these four places before you explain a decision catches most of them.
- Support — which emails or tickets will this create, and do they have an answer ready? (The Support Loop)
- Finance — refunds, fees, reconciliation differences, anything that shows up as a line item.
- The next engineer — what becomes harder to change, and what will they be tempted to "fix" that is actually the accepted cost?
- The customer — what will a real person experience on the bad path, in their words: "I paid and then got an email saying it was gone."
When the trade-off is not yours to accept
Naming a trade-off sometimes reveals that you are not the one who should accept it. An engineer can accept "three days more work"; an engineer should not quietly accept "finance absorbs refunds on every drop". The moment the cost lands outside your team, the decision needs the person who pays it.
Is this trade-off yours to accept, or do you need someone else to agree?
when The cost is engineering time, internal complexity, or something your team alone absorbs and can undo.
cost You own it fully; if it goes wrong, nobody else was asked.
when The cost lands on support, finance or customers but is small and reversible.
cost A message and a short wait. Worth it: the payer now expects the cost instead of discovering it.
when The cost is money, customer trust or legal exposure, or cannot easily be undone.
cost Slower. The decision leaves your hands, and you write the options for whoever holds it (The One-Pager).
How to do it
Most important first.
- Use one sentence shape and keep using it: "We chose X over Y. We accept Z. We did it because W. We would revisit if V." Every part is load-bearing; the "accept" clause is the one people skip.
- Name the cost in the unit the person paying it uses: refunds per sale weekend for finance, emails per week for support, days of work for the team — not "some edge cases".
- Name who pays. "Support will see a handful of oversell emails during drops" is a cost with an owner; "there may be some oversells" is a cost with no one attached, which means no one was asked.
- Say what would change your mind, as a condition someone else could notice: "If oversell refunds pass what finance is willing to absorb on a drop weekend, we move to reservation at cart for limited items only."
- Tell the people who pay before you ship, not after. The cheapest moment to name a trade-off is when the person paying can still object (Options, Not Answers).
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- Lead with the choice and the price together: "We reserve stock at payment, not at add-to-cart. The price is that on a busy drop, a few people pay for the last unit and get refunded."
- Then the reason, in terms of the rejected option's cost: "Reserving at cart would lock stock in carts that never check out, and on a normal day that blocks more real buyers than the oversell ever refunds."
- Then who pays and whether they agreed: "Support handles the oversell emails with a template; I checked with them before we shipped. Finance sees the refunds as a separate line."
- Close with the revisit condition: "If a drop ever sells out in minutes, the trade-off flips for that item, and we would reserve at cart for limited releases only."
- "Just tell finance it is the standard approach." It may be standard, and finance will still see the refunds. Telling them what they will see and why is the difference between a known cost and a surprise.
- "You are overcomplicating a simple choice." It is one extra sentence. The alternative is the same conversation every time someone new notices the refunds.
- "Why not do both — reserve at cart with a short timeout?" That is a real third option and it has its own cost: timers, a release job, and customers who lose stock mid-checkout. If it is worth it, we should compare it properly rather than bolt it on.
What can go wrong
- The fake trade-off: naming a cost nobody cares about ("it is slightly more code") so you can say you named one, while the real cost — refunds — goes unmentioned.
- The trade-off buried in paragraph four of a document, where it is technically disclosed and practically hidden. If it matters to the reader, it goes in the first three sentences.
- Over-hedging: listing eleven possible downsides so that nothing can ever be your fault. That is not naming the trade-off; it is refusing to have made one.
- Naming the trade-off once, in a meeting, and nowhere else. The sentence has to live where the next person will look (Decision Records).
- "Naming the trade-off means listing pros and cons." A pros-and-cons list has no decision in it. The trade-off is one sentence about what you gave up to get what you chose.
- "If I name the downside, people will reject the decision." Sometimes they should — and if they would have rejected it knowing the cost, shipping it without telling them was the worse outcome.
- "Small decisions do not have trade-offs." They do; they are just cheap. The skill is spending one clause on them, not a document (Reversible vs Irreversible Decisions).
Knowing whether it worked
- When someone asks "why did we do it this way?", the answer includes a "we accepted" clause, and the asker does not come back with "but did you consider…" about the option you rejected.
- Support and finance hear about the cost from you before they see it in their queue. The first oversell refund arrives with a template already written.
- Decisions get revisited because a named condition changed, not because a new person arrived and re-argued the whole thing.
- Your written decisions contain the word "accept" or "give up" with a concrete cost next to it.
- On a small team the person who pays for the trade-off is usually in the room. As the team grows the payer is two teams away, and naming the cost in writing is the only way they find out.
- At 10x traffic, costs that were "a few a week" become a queue. A named trade-off with a unit ("oversells per drop") tells you when you have crossed the line; an unnamed one is discovered by support in a spike.
- At 10x team size, the rejected option gets proposed again by someone who never heard why it lost. A written trade-off is what makes that a five-minute conversation instead of a two-week redesign.
- It makes you look less certain. "We chose this and it costs that" sounds weaker in the moment than "this is the right approach" — until the cost appears.
- It invites objection. Naming who pays gives them a chance to say no, which will sometimes slow the decision down or change it.
- It takes a little more thought per decision: you have to actually know what the rejected option would have cost, which means you have to have looked.
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.
- GENERALTrue of any decision explained to someone who pays part of its cost. It differs only in weight: a copy change needs one clause, a pricing or data decision needs the full sentence shape in writing.
- TEAM-SPECIFICWhere a PM owns the call, the engineer's job is to make sure the cost side is complete and in the PM's units; where there is no PM, the engineer names the trade-off directly to the people who pay it.
Where the depth lives
This domain teaches the product-side judgement and hands the mechanism off.