Saying No Well
A product engineer almost never refuses. They propose the smaller, cheaper way to find out who is right — and make it easy for the person asking to say yes to that instead.
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 think a request is wrong, what do you offer instead of a refusal?
The head of marketing, in the team channel with the PM copied: "We are losing repeat customers to competitors with loyalty points. We need a points programme this quarter."
There are two respectable answers. Say yes and build it, because marketing sees the customers leave and you do not. Or say no clearly, with the engineering reasons: it is a quarter of work, the order model is not ready, and nobody has shown that points drive repeat purchases.
The yes: a quarter spent on accrual, expiry, refunds, accounting treatment and fraud rules. At the end nobody can say whether points brought anyone back, because the request was never framed as a question.
- The yes: a quarter spent on accrual, expiry, refunds, accounting treatment and fraud rules. At the end nobody can say whether points brought anyone back, because the request was never framed as a question.
- The flat no: it is heard as "engineering does not care about retention". The request goes over the team's head and returns as a mandate with a deadline, and now there is no room left to shape it.
- The no with reasons: every reason is about engineering cost, which invites a negotiation about cost — "what if we hire a contractor?" — instead of a conversation about whether points solve the problem.
- Both answers lose the actual question: are repeat customers leaving, why, and would points change it. That was answerable in weeks, not a quarter.
What is really going on
- A request is a bet someone is making on a problem. Refusing the bet does not remove the problem or their belief in it; it only removes you from the conversation about it.
- Disagreement about a feature is usually disagreement about a fact nobody has checked: do repeat customers leave, do they leave for points, would a reward bring them back. Facts can be checked cheaply. Opinions cannot be argued to a conclusion.
- "Yes, and here is the smallest way to find out" turns a disagreement into an experiment. The requester gets movement on their problem this week; you get evidence before the quarter is committed.
- Status matters. The person asking often outranks you. A refusal forces them to choose between their idea and your judgement in public. An alternative lets them pick a path without losing face.
- Sometimes the right answer really is no — a legal problem, a security hole, a broken promise to customers. Those are rare, and they are easier to say if you have not spent your no on everything else (Disagree and Commit).
Three answers to the same request
Every answer to the points request tells marketing something about engineering, beyond the words. The third answer is the only one that keeps the problem, the requester and the evidence in the same conversation.
| Answer | What the requester hears | What usually happens next |
|---|---|---|
| "Yes, we will build loyalty points." | Engineering is on board. | A quarter of work, launched without a baseline. Nobody can later say whether points brought anyone back. |
| "No — it is too big and there is no evidence." | Engineering does not care about retention. | The request goes over the team's head and returns as a deadline with less room to shape it. |
| "Yes to the goal — here is a two-week way to find out if points are the answer." | Engineering wants what I want and has a faster path. | A test runs, a decision follows with evidence, and the requester keeps bringing problems to the team. |
The reply, written
Most of these conversations happen in writing, in a channel where other people are watching. That makes the first reply matter more than the meeting that follows it.
The head of marketing posts in the team channel, PM copied: "We are losing repeat customers to competitors with loyalty points. We need a points programme this quarter."
"Points is a big project — accrual, expiry, refunds, accounting, fraud. We do not have capacity this quarter and there is no data showing points drive retention. Maybe next half?"
"Agreed that repeat purchase is the thing to fix. Before we commit a quarter to points, can we check whether a reward brings lapsed customers back? Proposal: a one-off reward code to customers who have not ordered in 90 days, half of them get it and half do not, results in two weeks. If the reward group comes back noticeably more, points are likely worth it and I will scope them with the PM. If not, they are probably leaving for something else — delivery times are my next suspect. Does that work for you both?"
Designing the smaller way to find out
A good alternative is not smaller for its own sake. It is aimed at the single fact the decision hinges on, and its result would change what you build. If both outcomes of the test lead to the same decision, it is not a test; it is a delay.
Which cheap test fits "would points bring customers back?"
when You can email lapsed customers and can wait a few weeks for orders to come in.
cost The value of the discounts. A one-off reward tests the incentive, not the mechanics of a points programme.
when Support tickets, reviews or account-closure reasons exist and nobody has grouped them.
cost A day of reading. It tells you why people left, not whether points would have kept them.
when You want to know whether shoppers care enough to click, and marketing is comfortable showing a "coming soon" message.
cost Some shoppers are disappointed, and a click is far cheaper than changing where you shop.
when The decision has already been made above the team, or any test would take longer than a first version.
cost The full build cost, but at least the result can be read afterwards (Instrumentation First).
When no is the answer
A few requests deserve a plain no, and they are easier to say if you have not been saying no to everything else. They are the ones where no experiment could make the answer yes.
Even then, say once and plainly what you would do instead. The difference between a no and a refusal is whether the person leaves knowing a way forward.
- It breaks the law or a contract — storing card numbers on the order record to make reorders faster.
- It breaks a promise to customers — emailing people who unsubscribed because the reward test needs a bigger audience.
- It creates a security or safety problem that cannot be mitigated in the time available.
- It is irreversible, the evidence is thin, and the requester will not accept a smaller first step. Here the no is to the shape, not the goal, and you still say what you would build (Reversible vs Irreversible Decisions).
How to do it
Most important first.
- Start by restating their problem, better than they did, so they know you heard it: "Repeat purchase is slipping and you think competitors' loyalty schemes are part of why."
- Name the fact the decision hinges on: "What I cannot tell yet is whether customers who leave are leaving for points or for something else."
- Propose the smallest way to check that fact, with a date — a reward code to lapsed customers, a read of why people left, a fake door. Weeks, not a quarter (The First Version That Teaches You Something).
- Say in advance what result would make you build the full thing: "If lapsed customers come back noticeably more with a reward, points are worth building and I will scope them properly."
- If it must ship now regardless, offer the trade in plain words: "If this goes in this quarter, the returns-page rework moves to next quarter. Which matters more?" (Naming the Trade-off)
- Write the agreement where both the requester and the PM can see it, so it survives the next meeting (Writing for Stakeholders).
- Know your real no's in advance — legal, security, promises to customers — and use plain words for them without the experiment.
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 goal you share: "I want repeat purchases up too, and I think we can find out quickly whether points are the way."
- Replace the verdict with a question and a cheap answer: "Before we commit the quarter, can we send a reward code to customers who have not ordered in 90 days and see how many come back? It is about a week of work."
- Say what each result would mean before you run it: "If a lot of them come back, a points programme is probably worth it and I will scope it. If almost nobody does, they left for something else — delivery times are my next suspect."
- Make the path to yes visible: "Either way, we decide by the end of the month with numbers in hand rather than opinions."
- "We do not have time for an experiment — competitors already have this." Competitors having it tells us it exists, not that it works for them. The test is two weeks and the build is a quarter. If the test says yes, we lost two weeks and gained a scope we trust.
- "Just tell me whether you can build it." I can build it. What I cannot tell you yet is whether it will bring customers back, which is what you actually want. Two weeks gets us most of the way to that answer.
- "You engineers always find reasons not to do things." Fair to be suspicious. Here is exactly what would change my mind, and I will build it if the numbers say so.
What can go wrong
- The rigged experiment: proposing a test designed to fail so you win the argument. People notice, and it poisons every proposal after it.
- The endless test: always one more experiment before committing. At some point the evidence is good enough and the bet should be placed.
- Agreeing to the test and never reporting back, so the requester concludes it was a stall — and next time goes around you.
- Going around the PM: negotiating scope directly with the head of marketing, leaving the person who owns the roadmap to find out afterwards (Working With a Product Manager).
- Hiding behind capacity: "we do not have time" when the real reason is "I do not think it will work". Say the real reason; capacity can be bought, and then you are building it anyway.
- "Never say no" means say yes to everything. It means your answer is always a path forward, and sometimes the path is very short.
- "This is about being nice." It is about keeping the decision tied to evidence. A polite answer without an alternative is still a refusal.
- "Proposing an experiment overrides the PM." Propose it to the PM first, or together; the roadmap is still theirs.
- "The test will prove who is right." It reduces uncertainty about one fact. The decision still has other inputs, including strategy the test cannot see.
Knowing whether it worked
- The requester agrees to the smaller test and later brings you their next idea directly, rather than going over the team.
- The test runs, is reported on the date promised, and the decision after it is made quickly, whichever way it went.
- Across a few quarters, ideas you proposed tests for do get built when the tests said so. If they never do, your tests are stalls.
- People who ask you for things describe you as the engineer who "finds a way", not the one who "pushes back".
- On a small team a no is a lunch conversation and the test runs the same week. At 10x team size requests arrive through a roadmap process, the requester is not in your standup, and the alternative has to be written down to exist.
- At 10x shoppers, cheap tests get more powerful: a reward code to a slice of lapsed customers answers the question in days rather than weeks.
- As you get more senior, your no carries more weight and costs more when it is wrong. Senior engineers need the alternative more, not less, because a room defers to a flat refusal from them.
- If the full version was right all along, the test delayed it. You traded weeks for certainty, and sometimes the weeks were the more valuable thing.
- It is more work than yes or no: you have to understand their problem well enough to design a test for it.
- Some requesters experience any alternative as resistance, and the relationship costs the same as a refusal would have.
- Running the test commits you to its result. If it says build points, you build points — including when you still privately think it is a bad idea.
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.
- GENERALOffering a cheaper way to find out works across teams and seniorities. It flips when the request is a hard constraint — a legal requirement, a signed contract, a security fix — where the honest answer is a plain yes or a plain no.
- ROLE-SPECIFICA junior engineer proposes the alternative to their lead or PM, not directly to the head of marketing. A senior engineer is expected to propose it in the room, and should know that their doubts are heard as a veto more than they intend.
- STAGE-SPECIFICAt a startup the founder's bet may be the strategy, and the test only shapes the scope. In a large company the test itself may need approvals that take longer than a small build, which changes which alternative is actually cheaper.