Introduction
Every founder eventually faces a steady stream of feature requests from customers, investors, and their own team. Saying yes to all of them is the fastest way to end up with an unfocused, bloated product that does many things adequately and nothing exceptionally.
Why Saying Yes Too Often Is Dangerous
Every feature added is also a feature maintained indefinitely — it needs to keep working as the codebase evolves, it adds surface area for bugs, and it adds cognitive load for new users trying to understand the product. The cost of a feature doesn't end at launch; it's paid continuously afterward.
A Framework for Evaluating Requests
Ask three questions: Does this align with the core problem the product solves? Has more than one independent customer asked for it unprompted? Would building it require compromising the experience for users who don't need it? A request failing more than one of these is usually safe to decline, at least for now.
How to Decline Without Losing the Relationship
The framing matters more than the decision itself. Explaining the reasoning — "we're focused on X right now because it serves the broadest set of users" — and offering a genuine alternative or workaround preserves the relationship far better than a flat no or vague "maybe later."
When to Actually Say Yes
The requests worth saying yes to are the ones that surface repeatedly, independently, across different customer segments, and that align with where the product is already heading. These patterns are usually visible within a quarter of consistent feedback tracking.
Conclusion
A product roadmap is defined as much by what's declined as by what's built. Founders who protect their roadmap's focus, with a clear and respectful reasoning process, end up with a sharper product and customers who still feel heard.
Frequently Asked Questions
How do I decide whether to build a requested feature?+
Ask whether it aligns with the core problem the product solves, whether more than one independent customer has asked for it unprompted, and whether building it would compromise the experience for users who don't need it.
Won't declining feature requests upset customers?+
Less than expected, if the reasoning is explained clearly and a genuine alternative or workaround is offered. A flat no with no context damages the relationship far more than a well-reasoned decline.
What's the real cost of saying yes to too many features?+
Every feature added needs ongoing maintenance, adds bug surface area, and adds cognitive load for new users — the cost continues long after the feature ships, not just at launch.