The Yes Problem
Most agencies say yes to every client request because they're afraid of losing the relationship. We used to do this too. The result: projects that bloated by 40%, timelines that slipped by months, and products that tried to do everything but did nothing well.
Learning to say no - specifically, learning to say no in a way that strengthens rather than damages the relationship - was the single biggest improvement in our project delivery.
The ICE Framework
We score every feature request on three axes: Impact (how much does this move the core metric?), Confidence (how sure are we this will work?), and Effort (how long will this take?). The score is (Impact × Confidence) / Effort. Anything below 4.0 gets pushed to the backlog with an explanation.
The Conversation Scripts
For low-impact requests: "I love the thinking behind this. Let me show you how it scores against our core metrics so we can decide together whether it belongs in this sprint or the next phase."
For high-effort requests: "This is a great feature. In our experience, it adds 2-3 weeks to the timeline. Here's a lighter version that delivers 80% of the value in 3 days - should we start there?"
For scope creep: "Adding this means one of these three things gets pushed out. Which one should we defer?" This forces a trade-off conversation instead of an add-on conversation.
The Results
Since implementing the ICE framework and structured pushback conversations, our projects come in an average of 3 weeks faster, client satisfaction scores have increased (not decreased), and the products we ship are more focused.
When to Say Yes
Not every request should be scrutinized. If the request aligns with the core product vision, comes from direct user feedback, and fits within existing sprint capacity - just do it. The framework is for protecting against requests that feel urgent but aren't important.