Handling feature requests is often less about deciding what to build than about deciding what not to build. This article covers a framework for making that call.
Why saying no is harder than saying yes
Deciding to build something is relatively easy to justify. You can point to a high volume of requests, a clear business impact, or low implementation effort, and people generally accept the reasoning.
Deciding not to build something means telling a real customer, who took the time to ask, that their request won't be acted on. Without putting a reason into words, it's easy to default to leaving the request in "considering it" indefinitely, and the list of unresolved requests just keeps growing. Deferring a rejection decision doesn't make its cost disappear, it just makes the cost invisible for a while.
Three questions for deciding what not to build
Writing down explicit criteria, rather than relying on gut feel, cuts down on inconsistency in these calls.
- Does it fit the product's direction? A request can be perfectly reasonable and still sit outside the core problem the product is trying to solve right now. That kind of misalignment is a separate question from whether the feature itself is good.
- How broad is the affected audience? A request can matter a lot to the one person who raised it without being a problem that recurs across your broader customer base. Whether you weight a small number of strong signals or a large number of weak ones depends on your product's stage, we cover the pre-PMF version of this question in "How Should a Pre-PMF Product Handle Customer Feedback?".
- Does it justify the ongoing cost? Beyond build cost, factor in the cost of maintaining the feature afterward, support load, documentation, and so on.
Once you've decided "not this" against these criteria, move the request to rejected rather than leaving it parked as "considering it."
Rejecting is about recording and communicating, not hiding
How you handle a request you've decided not to build matters for trust, both with your team and with customers. In Feedury, rejected is an internal, admin-only status, it doesn't show up on the public board, which only surfaces the four states from open through done. That said, anyone who voted or commented still gets an email notification when the status changes.
The important part isn't quietly forgetting the decision, it's keeping a record and communicating it to the people involved. Explaining the reasoning, even briefly, goes a long way toward avoiding the impression that a request was simply ignored.
What if a rejected request comes back?
Sometimes a request you rejected resurfaces independently from a different customer later on. That's worth treating as a reason to revisit the original decision. It helps to think of rejection not as "we will never build this," but as "this wasn't the priority given what we knew at the time", that framing makes it much easier to reopen the conversation later.
Grouping similar requests and tracking their combined support makes it easier to notice when a previously rejected topic is resurfacing. You can see this in action on the demo board.
Don't confuse "deferred" with "rejected"
Some requests genuinely can't be decided yet: you don't have enough information, or the business timing isn't right. It's fine to leave those honestly parked as "considering it." The problem is different: avoiding the decision itself when you already have enough to decide, and leaving it in "considering it" as a way of not deciding.
Mixing the two turns your "considering it" list into an unclear mix of requests that are genuinely still open and requests that have effectively already been decided against. Periodically reviewing the list and asking, for each one, "are we actually missing information here, or has the decision already been made," is what keeps that list honest.
Wrapping up
Deciding what not to build is just as much a part of product management as deciding what to build. Having explicit criteria, rejecting promptly instead of deferring, and explaining the reasoning, those three habits are enough to keep a request list from growing without bound. We cover choosing a feedback management tool more broadly in "What Is a Feedback Management Tool? A Guide for Indie Developers and Small SaaS Teams".