A client in Southeast Asia asked for a small addition to their onboarding flow. It sounded straightforward in the call. Two days of work, maybe three. I said I would scope it properly and come back with a timeline.
I did not come back with a timeline. I came back with three options.
The first option was to build what they asked for exactly as described. The second was to build it with one existing component reused instead of recreated. The third was to defer the feature entirely and land the core product on schedule. Each option had a date attached. Each date was different.
The client chose the option I expected them to choose. Then they chose a fourth option I had not written down.
Recognizing scope change in disguise
Most scope changes do not announce themselves as scope changes. They come wrapped in casual language: "while you're in that area," "could we also," "one more quick thing," "this would be so useful." The request feels small because it is small in isolation. It becomes large only when you realize it touches a system you thought was locked, requires coordination with another team, or contradicts an earlier decision.
I learned to ask three questions the moment I hear a request that was not in the agreement.
First: does this touch any existing system or data model? If yes, I am not building something new. I am modifying something live. That carries risk.
Second: does this create a dependency on another team or another vendor? If yes, the work is no longer just my work. The timeline now includes waiting.
Third: did we previously decide against this, or something like it? If yes, understanding why we said no before is more important than saying yes now.
On the Southeast Asia call, the answer to all three was yes. The feature touched their user table. It created a dependency on their identity provider. And six weeks earlier, we had explicitly removed this exact feature from the MVP to make the launch date.
That is when I stopped saying "that will take longer" and started showing them the cost.
Why "that will take longer" fails
Saying a scope change will delay delivery is technically true and strategically useless. The client already knows it will take longer. Longer than what? Longer than the original plan, yes. But longer than never shipping? Longer than staying broken? The comparison does not matter to them.
What the client actually needs to know is what they are trading away. Scope changes are not free additions to the timeline. They are choices to sacrifice something else: a feature, a quality bar, a launch date, or a subsequent feature still in the backlog.
The response "that will take longer" leaves all those tradeoffs invisible. The client hears delay and thinks about what they might be losing. They do not have the data to decide. So they either push back harder or agree to something neither of you meant.
I started instead writing down the specific tradeoff. Not in narrative. In concrete options.
What to put in front of the client
I sent the Southeast Asia client three scenarios.
Option A: Build the feature as requested, including recreating the identity integration from scratch for this use case. The team lands the core product on the original date. The new feature ships four weeks later.
Option B: Build the feature using their existing identity integration and reusing the user-table work from the MVP. All features ship together on a new date, three weeks after the original target.
Option C: Ship the core product on the original date with the feature off the roadmap. They can request it again after launch if it still matters.
Each option was real. Each one was built from actual engineering work and actual dependencies. I did not invent scenarios. I described the actual paths we could take, how long each one took, and what shipped when.
This is the move that changes the conversation. The client stops arguing about whether scope changes are bad. They start choosing which cost they are willing to pay.
Some clients choose A. They want everything and accept the later date. Some choose B. They want it sooner and accept the additional risk. Some choose C. They ship faster and cut the feature. All three decisions are defensible once you understand what they are actually deciding.
The Southeast Asia client did something else. They chose Option B, then asked if Option A could be ready on the Option B ship date if they brought in a contractor on their side to handle the identity integration work.
I had not offered that option. But once they named it, the scope was clear. Someone outside my team would do part of the work. I could plan the rest. We scheduled a handoff meeting, documented the integration contract, and committed to a date.
The feature shipped on time because we stopped pretending the work was small and started treating it as what it was: a real choice with real consequences.
What happens when they pick wrong
Not every client picks the option you expect. Some choose timeline over completeness and regret it later. Others choose completeness and then blame you when the later date arrives and they discover other constraints have shifted.
The protection is in the documentation. When you write down the three options and the client chooses one, you are not guessing at what they meant. You have a record. That record becomes the source of truth if anyone later questions the decision.
More important, the client has already sat with the tradeoff. They chose consciously. That changes how they react when the chosen path gets harder or takes longer. They remember choosing it. They do not remember being told "that will take longer."
The principle that follows
Show the client what scope expansion costs in the terms they already care about—timeline, completeness, or both—and let them decide which cost is worth it. Do not announce the cost as a constraint on you. Frame it as a choice about what they ship and when. This converts an argument into a decision, and a decision into a contract.
Once the client has chosen, the work is no longer negotiable. It is committed. That simplifies everything that follows.
Related posts
- · 5 min readSignal a deadline slip early, before certainty
Tell your client a deadline is at risk three weeks out, not three days. Early signals let them treat it as planning. Late ones feel like hidden failures.
- · 5 min readHow to Disagree With a Client Who Did Their Homework
Four objections to a client's own technical plan, all correct, all accepted. What made them land was not the analysis but the shape of the disagreement.