Stakeholders
Don't reject an unrealistic request — re-price it
Saying no to a user spends goodwill and ends the conversation. Naming the cost and offering an alternative keeps both the relationship and the constraint intact.
The advice I gave on LinkedIn: “Based on my experience working with several projects, managing expectations is key to handling unrealistic requests. This should be approached carefully; it’s important to avoid outright rejection of requests. Instead, clearly explain the technical constraints and potential impacts on the project timeline and quality. Always strive to offer alternative solutions that align with project goals and user needs, taking into account capacity and timelines.”
I’d repeat that. What’s worth looking at more closely is what “avoid outright rejection” is actually doing under the hood.
A flat no feels honest, but it does two unhelpful things at once: it spends the goodwill of the relationship, and it ends the conversation while the user still wants the thing. They don’t walk away agreeing the request was unrealistic — they walk away feeling blocked. The constraint was real, but the way it was delivered turned a scoping problem into a relationship problem.
The move that works isn’t softening the no — it’s converting it into a price. “That’s possible, and here’s what it costs in timeline and quality” keeps the constraint completely intact while handing the decision back to the person who asked. Most unrealistic requests aren’t a refusal to accept limits; they’re made without visibility into the limits. Show the cost and the request often revises itself.
So I try never to reject a request — I re-price it, and I bring an alternative. The alternative is the part that proves you were solving with them, not defending against them. “Not that, but here’s something close that fits the budget” respects the goal even while declining the specific ask. You protect the timeline and the trust at the same time, which a clean no never manages.
This note grew out of a contribution I made on LinkedIn.