If you're building a product you're going to get feature requests. From customers, from sales, from investors, from your own team. Some will be great. Most will be fine. A few will be terrible.
Here's the truth: you can't and shouldn't build everything you're asked for. The real skill is knowing when to say no, and more importantly, how to say it without losing trust.
Saying yes to every request is how products become bloated, directionless messes. You start building for edge cases. You stretch your focus thin. You end up serving nobody well.
Saying no is how you stay focused on what matters—your core users, your core value, and the long-term direction of your product.
If a feature serves one high-maintenance edge case but not your broader customer base, it’s a distraction. Don’t build for outliers unless your business depends on them.
If the feature pushes your product in a direction you don’t want to go—technically, strategically, or ethically—say no. You’re the pilot of the product. Own that.
Be very cautious about building features just to close a deal. If you can’t justify the long-term value or product fit, the short-term revenue isn’t worth the long-term cost.
Some features seem useful but don’t actually solve a real problem. If the ROI on complexity is low, kill it before it adds layers of complexity to your product.
If you’re at 100% and someone’s asking for “just one more thing,” you need to protect your roadmap. Context-switching and overcommitment will wreck your momentum.
Saying no doesn’t have to burn bridges. Here’s how to do it right:
Let them know you’ve heard them. Ignoring a request is worse than rejecting it.
“Thanks for the suggestion—we really appreciate you taking the time to share this.”
Even a brief explanation builds trust. Help them understand the “why.”
“Right now, we’re focused on features that improve X for the majority of our users. This one feels more niche, so it’s not on the immediate roadmap.”
If the request has merit, track it and show them it’s not disappearing into a black hole.
“We’ve logged the request and will revisit it if more customers bring it up.”
Don’t overpromise. Don’t say “we’ll consider it” if you never will. Users appreciate clarity over false hope.
This is exactly why we built FeatureHunter - to give you a clear view of what your users are asking for, who’s asking, and how to prioritize without the guesswork.
When you have a system to track, prioritise, and communicate feature requests, saying no becomes a conversation—not a dead end.
Not every feature request deserves a “yes.” Learn when to say no, say it with confidence, and use tools like FeatureHunter to back it up with data and transparency.
Because the only thing worse than saying no is saying yes to the wrong thing.
- Yann Chatelaine
