How to manage scope creep without saying no
No need to be the bad cop. Just ask better questions.
Early-stage enterprise deals are nervy affairs. The prospect is excited, the champion is pushing internally, and the last thing you want to do is introduce friction. So when they ask for a custom feature, you say yes. Then yes again. Then yes to the thing that requires three other things to be true first.
By the time you’re six months into implementation, you’re underwater and the customer is disappointed in a product that was never designed to do what you promised. The relationship is worse than if you’d said no in the first place.
The counterintuitive truth is that customers don’t remember that you said no. They only remember that you didn’t deliver. Here’s how to avoid it.
This post covers:
How to reframe a feature request before you react to it
How to use your existing customer base as a reality check
How to pressure-test requests with data before they make it onto a roadmap
How to build a backlog that makes customers feel heard
How to phase solutions so deals close, without commitments you can’t keep
Most custom requests aren’t actually custom
Whenever a customer asks you for something that sounds custom, your first question should always be, “What problem are you trying to solve?”, not “What do you want?”, or “How do you want that to work?”
Most custom feature requests are solutions your buyer has half-designed in their head and gotten overly-excited about. Your job is to put on your PM hat and walk them back from the edge by clarifying the problem rather than engaging in the solution.
Many requests are workarounds for something your product already handles differently. In that case the gap isn’t in your product, it’s in how they understand it. A good discovery conversation followed by a tailored demo or training session closes that gap without a single line of custom code.
Use your customer base as a reality check
Turn the feature request into a benchmarking moment by saying something like: “Most of our customers solve that problem like this _________ . How does that compare to how your team operates?”
Doing this accomplishes two things. First it grounds their request as an outlier in a broader reality, which signals that this may not be as universal a need as they think. Second, you show that you see patterns across accounts, which demonstrates the depth of your understanding and builds credibility.
If their answer is “actually that’s the same for us,” you may have just diffused the whole request. If their answer is “we actually do it differently,” you’ve just learned something useful and can move onto the next test.
Pressure test with their own data
Customers tend to overweight the importance of edge cases because they consume disproportionate mindshare — the unusual is more exciting than the mundane. Your job is to re-balance this against the 90% of their business that already runs smoothly but never comes up in conversation.
3 questions to ask to do this are: