How to prioritize feature requests that keep piling up
5 min read
Tracking feature requests solves where they live. It does not solve which one ships next, and that second question is the one teams actually get stuck on. A backlog with three hundred grouped, labeled requests still needs a decision rule, because “build the most-requested thing” only works until two requests are close and a third has one loud advocate, which is most weeks. The frameworks below are not competing answers to the same question. Each one is right for a different kind of request, and using one framework for all of them is usually the actual mistake.
What makes prioritizing feature requests different from prioritizing a roadmap?
A roadmap decision starts from strategy and asks what to build. A feature request decision starts from demand that already exists and asks whether to act on it, and the two pull in different directions often enough that a request can be high-demand and still wrong to build, or low-demand and still worth building because it unblocks a strategic account. Treating every request as a roadmap vote skips that check.
| Framework | What it weighs | Where it breaks |
|---|---|---|
| Raw request count | How many people asked | Rewards catchy naming over real demand |
| RICE | Reach, impact, confidence, effort | Needs estimates nobody has for a fresh request |
| Revenue-weighted | Who asked, by account value | Ignores requests from accounts not yet worth much |
| Public upvotes | Visible, low-effort signal | Only reaches users who already know to look |
What is RICE, and does it work for feature requests?
RICE scores an idea on reach, impact, confidence, and effort, then divides the first three by the fourth to get a comparable number. It was built for roadmap ideas a team already believes in, where the hard part is comparing unlike bets against each other. Feature requests already come with a reach number, the count of people who asked, which is more concrete than the reach a fresh roadmap idea usually has. Where RICE strains on a request is confidence and impact: a team can be confident a request is real and still have no basis for how much it will move a metric, because “impact” for a request that already has a name and a paper trail from actual users is a different kind of estimate than impact for an idea nobody outside the room has seen yet.
Use RICE for requests you are seriously considering and undecided about. Do not run it on every incoming request; the scoring overhead only pays for itself on the ones close enough to need a tiebreaker.
Should you weight by revenue, or by who asked?
By who asked, but not only by revenue. An account near renewal, an account that has escalated before, and an account whose request unblocks a deal in progress all carry urgency that a flat revenue figure does not capture on its own, and a request from a trial signup can still matter if it is blocking a decision that turns into revenue soon. Revenue-weighting is the easiest of these to compute and the easiest to over-trust for that reason: it correctly deprioritizes noise from accounts with no real stake, and it can just as easily deprioritize a request that would land a much larger account still in the pipeline.
What role do upvotes actually play?
A cheap, ongoing signal for requests that already exist, and a poor way to discover which requests should exist in the first place. A vote count only reaches the users who already found the request and thought it worth clicking on, which means a public roadmap’s vote totals reflect visibility as much as demand: an old request near the top of the list keeps accumulating votes partly because it is easy to find, and a newer, equally real request starts from zero. The public roadmap article argues for leaving votes off the roadmap entirely. Treat upvotes as one input that needs grouping and recency-weighting, not as a leaderboard to build straight down. Support tickets vs. feature requests covers the other blind spot in vote counts: a real gap can generate almost no votes if the users hitting it never find the board, while still showing up loudly in support.
When does the loudest customer win, and is that a problem?
Sometimes, and it is only a problem when nobody notices it happening. A customer who escalates often, writes detailed tickets, or has a direct line to someone on the team will get their requests seen faster than a quieter customer with an equally valid ask, and a prioritization process that never checks for this will systematically favor whoever is most persistent rather than whoever has the strongest case. Loud customers are not the problem to fix; their requests are often genuinely important. The fix is a habit: periodically pull the backlog by source and check whether the same handful of accounts account for most of what shipped recently, and ask whether that matches where the real demand actually is.
How do you turn a prioritization decision into a reply?
Every decision here produces both winners and losers, and both deserve a reply that names the actual reasoning, not a status change with no explanation attached. How to decline a feature request covers what to say to a request that lost, in a way that keeps the relationship intact rather than reading as a form rejection. The grouping and labeling work that makes any of this possible in the first place is covered in feature request tracking; prioritization only works on requests that were already recorded and grouped well enough to compare.
FAQ
What is the best framework for prioritizing feature requests? None of them alone. Use raw counts to find the loudest signal, RICE to compare a short list of serious contenders, and a revenue or account check to catch cases where quiet demand from a strategic account outweighs a louder but lower-stakes group.
Should feature requests be prioritized the same way as roadmap ideas? No. Roadmap ideas start from strategy; feature requests start from demand that already exists. Score them together and a well-argued strategic bet with little existing demand will consistently lose to a request that just has more people who happened to ask.
Do upvotes on a public roadmap accurately reflect demand? Only among people who already found the request. Older, more visible requests accumulate votes faster regardless of how much real demand exists behind a newer one, so treat vote totals as one input, grouped and weighted by recency, not a ranked list to build in order.
How often should feature request priorities be re-evaluated? On a fixed cycle, not only when someone escalates. A monthly or quarterly pass that regroups requests and rechecks weighting catches drift, like a handful of accounts dominating what ships, that a purely reactive process never surfaces on its own.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.