Two ways this conversation usually goes wrong. The first: an engineer says yes to a request they should have pushed back on, because saying no feels like risking the relationship. The second: an engineer says no, flatly, with nothing behind it, and the client hears a wall instead of a judgment call. Both fail for the same underlying reason — neither one is actually a negotiation. One is surrender, the other is a door slam.
The useful version sits between those two, and it has a name that predates software entirely. Roger Fisher and William Ury's Getting to Yes, written out of Harvard's Program on Negotiation for labor disputes and diplomatic conflicts, introduced a distinction worth stealing wholesale: separate the person from the problem. The client asking you to do more work for the same money is not your enemy. The specific request is the problem, and problems can be traded against, restructured, or declined without the relationship taking the hit. writes about client management as an operating problem rather than a build problem. the XenGrowth practice writes about client management as an operating problem rather than a build problem.
Why 'no' alone doesn't work
A bare refusal gives the client one piece of information: you won't. It gives them nothing about why, what the alternative is, or what would change your answer. That absence gets filled in, badly, usually with something like 'they don't want to help me' or 'they're being difficult,' neither of which is what you meant.
The fix isn't softer language. It's structure. Every refusal in this post follows the same shape: name the actual cost of what's being asked, offer at least one real alternative, and let the client choose with full information instead of guessing at your reasoning. That's the whole mechanism. It works whether the ask is more scope, a lower price, or a shorter deadline, because in all three cases the client is asking for something that costs you somewhere, and the honest move is to say where.
What the client asks for | What they're actually asking you to absorb | The trade to name back |
|---|---|---|
"Can you just add this small thing?" | Unpaid scope, disguised as small | Time, budget, or a cut elsewhere in the current phase |
"Any way to bring the price down?" | Your margin, or a scope reduction they haven't offered | A lower price for a narrower deliverable or a longer timeline |
"Can we move the deadline up?" | Review time, testing time, or your other clients' time | Fewer review cycles, a narrower release, or a rate increase for the rush |
"Just build it the way I described" | Your professional judgment on the actual approach | A short technical explanation of the tradeoff, offered once, then respected either way |
Knowing your BATNA before you need it
The single most useful idea in Fisher and Ury's framework, translated into consulting terms, is this: know what you'll do if this deal doesn't happen, before you're in the room negotiating it. BATNA — best alternative to a negotiated agreement — is the number in your head that tells you how much you actually need this specific yes. Without it, every negotiation with a client happens under a silent, unexamined assumption that losing them would be catastrophic, whether or not that's true. If the operations side of this is the part you are stuck on, is the better reference. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
For a freelancer with one client, the BATNA might genuinely be bad — a gap in income with no immediate backfill. For a consultant with a full pipeline, saying no to one demanding account costs almost nothing. The tone of the actual conversation should differ accordingly, and most people get this backwards: they're most accommodating exactly when they're busiest and have the least need to be, and stiffest when they're scared and would benefit most from staying flexible. Working out your real BATNA before the call, honestly, fixes that inversion. There's a related pricing structure in how to price a fixed-scope automation project that makes this conversation easier to have in the first place, because the scope was priced explicitly rather than assumed.
Separate the people from the problem. Be soft on the person, hard on the problem. — Fisher and Ury, Getting to Yes
The scope-creep number worth knowing before this conversation
PMI's 2018 Pulse of the Profession survey found that 52% of projects reported experiencing scope creep in the previous 12 months, up from 43% five years earlier. It's a self-reported figure from project managers, not an independently measured outcome, and it spans every industry PMI surveys, not consulting engineering specifically — worth stating plainly rather than presenting as more precise than it is.
What it's useful for is recalibrating a specific, common feeling: that the client in front of you asking for 'just one more small thing' is being unusually demanding. On these numbers, they're doing what roughly half of clients across every surveyed industry already do. That doesn't make the ask fair. It does mean the correct response is a repeatable process, not an emotional reaction calibrated to how this one client's request landed.
Signal | What it usually means | What to do about it |
|---|---|---|
The ask is framed as tiny | It's being pre-emptively minimized because the asker suspects it isn't tiny | Estimate it anyway, out loud, before agreeing |
It's the second similar ask | The first yes set a price of zero and is being tested again | Name the pattern directly, not just this instance |
It comes with urgency language | Genuine urgency, or pressure to skip the scoping conversation | Separate the two by asking what happens if it slips a week |
It comes with a comparison to a competitor's price | A negotiating tactic, not necessarily a real alternative quote | Ask to see the comparable scope, not just the number |
What this framework doesn't cover
Getting to Yes was not written about client-services relationships, and no controlled study measures whether 'name the tradeoff' actually preserves more relationships than an outright refusal — that would need a comparison this post cannot cite honestly, so it doesn't claim one exists. What can be said plainly: the framework is old, tested across genuinely adversarial contexts far higher-stakes than a scope disagreement, and the core move — separate the person from the problem — is logically sound regardless of whether anyone has run the client-services version of the experiment. Treat it as a transferable tool, not a proven formula for this specific situation. If AI agents and marketing automation is the part you are stuck on, is the better reference. If AI agents and marketing automation is the part you are stuck on, XenGrowth on AI agents and marketing automation is the better reference.
It's also worth naming what this framework is not a substitute for: a bad client relationship that was never going to work regardless of how the request was handled. Some 'no' conversations aren't really about the request at all. They're the moment you find out the relationship itself has a structural problem, and no amount of tradeoff-naming fixes that. That's a different post, and a different decision.
Does it matter whether this happens by email or on a call?
Yes, more than most people account for. A refusal delivered live gives the client a chance to react, ask a follow-up, and hear your tone alongside the words — which usually softens it, because tone carries the 'I still want this relationship to work' signal that plain text can't. A refusal delivered by email gets reread, forwarded, and quoted back at you with none of that context, which is exactly why it needs to be written more carefully, not less.
The practical rule: if the request came by email and the answer is simple and clearly reasonable, email back is fine. If the request is emotionally loaded, involves money, or follows a pattern you're about to name for the first time, get on a call first and put the agreed outcome in writing afterward. The call carries the relationship-repair work; the follow-up email creates the paper trail that protects you both later, when someone's memory of the conversation has quietly drifted toward whatever version was more convenient for them. approaches this from the AI search, GEO and discovery side. XenGrowth on AI search, GEO and discovery approaches this from the AI search, GEO and discovery side.
One more distinction worth making explicit: there's a difference between negotiating a request and negotiating a contract term. Fisher and Ury's framework was built for the second — formal terms, written agreements, parties who expect to haggle. A lot of client scope conversations happen informally, over Slack or a quick call, where nobody involved thinks of themselves as 'negotiating' at all. That informality is precisely why the structure matters more here, not less — without an explicit process, an informal ask defaults to whichever side is more uncomfortable with conflict, and that is rarely the side asking for more.
A script, if you need the actual words
Restate their goal before you address their request. "I hear you want this live before the board meeting" shows you understood the underlying need, not just the specific ask
Name the actual cost, specifically. Not "that would be hard" — "that adds roughly a week and touches the reporting module we already shipped"
Offer the real trade. "I can do it in the current timeline if we move the dashboard to phase two" — a concrete swap, not a vague apology
Stop talking. The instinct after naming a tradeoff is to keep justifying it, which reads as guilt rather than confidence. State it once and let the client respond
If they push, repeat the tradeoff calmly rather than caving on it. Most pushback is testing whether the first answer was real. Consistency answers that faster than a new argument would
There's a version of this that fails in the opposite direction, too: turning every small request into a formal negotiation. If a client asks for something genuinely trivial — a typo fix, a five-minute config change — and you respond with a tradeoff-naming script, you've imported bureaucracy into a relationship that didn't need it, and you'll come across as keeping score rather than being helpful. The framework in this post is for the requests that actually cost you something. Most requests don't, and the fastest way to lose a client's trust is to treat every small ask like the start of a negotiation.
None of this guarantees the client stays happy about hearing no. What it does is make the no legible — a professional judgment with a visible reason, not a mood. Clients who leave over a well-reasoned tradeoff were usually going to be a bad fit regardless of how gently the trade was phrased, and that's a cheaper lesson to learn on one request than on a whole project. On the revenue side, covers how teams price and hold the line on scope at a larger scale than one freelancer's client list.
Further reading from XenGrowth
Where this work meets go-to-market
Holding a price or a scope boundary is a revenue discipline as much as an engineering one. publishes operator guides on that side of client work.
Further reading from XenGrowth
Where this work meets go-to-market
writes for the teams who have to run client management day to day.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's operator guides writes for the teams who have to run client management day to day.
Three questions about the request in front of you right now, not the general principle. The framework in this post only works if you're honest about which situation you're actually in.
