How do you say no to feature requests?
Saying no to feature requests is one of the hardest skills in product development because every request feels like evidence of user engagement. The real job is distinguishing between what users ask for and what actually solves their core problem—then communicating that distinction without alienating the person who took time to reach out. Done well, a thoughtful no builds more trust than a lazy yes.
Why most founders say yes too often
The instinct to accommodate every request is understandable: users are giving you signal, and turning them down feels like turning away customers. But each feature you add has two costs that rarely show up in the feature request itself—the engineering time to build it correctly, and the permanent cognitive overhead it places on every future user who has to understand, navigate around, or ignore it. Complexity compounds. A product that tries to do everything for everyone becomes impossible to explain and painful to maintain.
Garry Tan's engineering philosophy captures this well: tie every technical choice to what the real user sees, loses, waits for, or can now do. That framing is just as applicable to product decisions as to code. Before you evaluate a feature request, ask: what does the requesting user actually lose if this doesn't get built? Often the honest answer is 'nothing critical'—they have a workaround, or the underlying need is already met another way. The request was a preference, not a requirement.
The second reason founders say yes too often is social discomfort. Declining feels like rejection, and in early-stage companies where every user relationship matters, rejection feels costly. The solution isn't to get comfortable with disappointing people—it's to reframe the no as a form of service. You're protecting the user's future experience of the product by keeping it focused and fast.
A decision framework before you respond
Before you write a single word of your response, run the request through three questions in order. First: does this request align with the problem this product was built to solve? Not 'could we technically implement this,' but 'is this squarely inside our stated purpose?' If the answer is no, you have a principled basis for declining that has nothing to do with resources or priority.
Second: if five different users asked for this in five different ways, what is the underlying need they all share? Surface-level feature requests are often poor descriptions of deeper needs. A request for CSV export might actually be about sharing data with a manager who doesn't have an account. If you understand the underlying need, you might already solve it—or you might find a better solution than the one the user proposed. Either way, you respond to the real problem, not the proposed implementation.
Third: what would you have to stop doing or slow down to build this? Every feature request competes with your current roadmap. Making that tradeoff explicit in your own thinking—not necessarily in your response to the user—ensures you're making a genuine prioritization decision rather than a reflexive one. If the honest answer is 'we'd have to delay shipping the core capability our best users depend on,' that's important information.
How to actually say no: the structure of a good decline
A good decline has four components, and none of them should be filler. Start by demonstrating that you understood the request at the level of intent, not just feature description. Paraphrase what the user is trying to accomplish. This matters because it signals you actually read the message, and it gives the user a chance to correct you if you've misunderstood.
Next, be honest about your reasoning. Not 'this is on our roadmap'—that's a soft yes that creates false expectations. Not 'we're considering it'—same problem. Something closer to: 'This isn't something we're planning to build because we're focused on [specific problem], and adding this would take us in a different direction.' Users respect clarity far more than diplomatic vagueness, and a clear no lets them make informed decisions about whether your product is the right tool for them.
If there's a workaround or adjacent solution—including a competing product that handles this specific use case—mention it. This is counterintuitive but effective. Pointing a user toward the right tool for their job, even if it's not yours, builds the kind of trust that keeps them talking about you positively. Finally, if the request revealed something genuinely useful about how users think about your product, say so. It doesn't have to be effusive—a single honest sentence acknowledging that you learned something from the exchange is enough.
When to revisit a no—and when not to
The most dangerous outcome of a good no-saying process is false confidence that your framework is right and the user is wrong. Feature requests that come back repeatedly, from different users, through different channels, deserve a second look. Not because persistence should be rewarded, but because recurring requests are the market telling you something your original product definition may have missed. Track these. A simple log of declined requests, searchable by theme, will surface patterns that individual responses obscure.
That said, volume alone is not a good reason to build something. 'A hundred users asked for this' is a data point, not a decision. A hundred users might be asking for something that would make your product marginally better for them and materially worse for the other thousand who never write in. The users who write feature requests are not a representative sample—they're the most engaged, often most power-user-oriented subset of your base. Weigh their input accordingly.
The clearest signal that a no should be revisited is when declining starts costing you the specific users you most want to keep. If a feature request comes from the segment of users whose needs your product is explicitly built to serve, and they tell you this is blocking them, that's a different conversation than a casual suggestion from a peripheral user. Segment before you evaluate. Not all noes are created equal, and not all requesters have equal weight in your product strategy.
“Lead with the point. Say what it does, why it matters, and what changes for the builder.”
— Garry Tan, source
The one thing to do
Before responding to any feature request, identify the underlying need behind it—then either show how you already solve it, or decline honestly with a one-sentence reason tied to your product's specific focus.
Frequently asked questions
Should you tell users why you're declining their request?
Yes, always. A reason—even a brief one—shows respect and gives the user information they can act on. Vague declines create frustration and false hope; clear reasoning closes the loop cleanly.
What if the user pushes back after you've said no?
Hear them out once more, genuinely. If they're adding new information or clarifying a misunderstanding, update your position. If they're simply repeating themselves more insistently, hold the line—changing a principled decision under social pressure damages your product judgment and your credibility with the team.
Is there a difference between saying no to a paying customer versus a free user?
The decision framework should be the same—does this fit our product, does it serve our core users—but the communication may need to be more thorough with high-value paying customers. That doesn't mean saying yes more often; it means explaining your reasoning with more context and following up if their underlying need isn't being met.
How do you handle feature requests in a public forum like a community board or Twitter?
Respond directly and honestly, the same way you would in private—but recognize that your answer is also for everyone reading, not just the person who asked. A clear, principled public decline often builds more confidence than a vague yes. Avoid arguments; state your position once and let it stand.
Sources
- gstack: skillify/SKILL.md — Garry Tan
- Heresy — Paul Graham