You prioritize feature requests by grouping them into themes first, then ranking the themes by the revenue and accounts behind them rather than by how many people asked. A vote count measures who is loudest. Weighting by account value and problem severity measures what is actually worth building.

Most prioritization advice starts one step too late. It hands you a scoring framework — RICE, ICE, a value-versus-effort grid — and shows you how to run each feature request through it. The unspoken assumption is that the feature request is the thing you should be scoring. It usually isn't.

Before any framework earns its keep, there is a more basic decision: what are you ranking? If the answer is "individual requests," you have already inherited the problem that makes prioritization feel impossible — three hundred items, no clear order, and a sense that whoever asked most insistently is quietly setting your roadmap.

Why does counting votes lead you wrong?

Because a vote count answers a question you didn't mean to ask.

Vote counts measure expressed demand: how many people took the trouble to ask, in the words they happened to choose. That correlates with who is engaged, articulate, and comfortable telling you what to build — not with who is affected, what they pay, or how badly the underlying problem hurts. The most valuable customer often says the least.

Two failures follow directly. First, the same problem described three different ways splits into three low-count items, none of which looks urgent, when together they might be the biggest thing on your board. Second, ten mentions from trial accounts outrank three from enterprise accounts approaching renewal, because the count treats every voice as identical weight. Neither failure is fixed by counting more carefully. They are built into counting itself.

This is the same reason a public voting board, useful as it is for transparency, is a weak prioritisation input on its own: it ranks solutions by popularity, and popularity is not severity.

What should you prioritize instead of the request?

The theme behind the requests.

A theme — some tools call it a signal — is a group of requests and complaints that all point at the same underlying problem, regardless of the words used or the solution proposed. "Add bulk export," "can I download these all at once," and "I'm copying rows one at a time every Monday" are three requests and one theme. Prioritising the theme instead of the three requests changes the unit from a solution someone proposed to a problem you have confirmed.

This matters because problems are rankable in a way solutions aren't. A problem has a severity, a set of affected accounts, a revenue exposure, and a trend. A raw request has a count. Once you are ranking themes, the frameworks you already know start working properly, because they finally have a sensible object to score. The mechanics of building these themes out of scattered feedback are covered in how to find recurring problems in customer feedback, and the reason a request and a theme are different objects in the first place is covered in the difference between feedback, a feature request, and a pattern.

How do you weight a theme once you have it?

By attaching the context a vote count throws away. Four dimensions do most of the work.

Accounts affected, not mentions. Count distinct customers behind a theme, not the number of times it was raised. One account raising a problem in eight conversations is one account, not eight votes.

Revenue behind it. Sum what the affected accounts pay. A theme blocking three accounts worth a combined large sum outranks one annoying twenty trial users, even though the trial users generated more noise.

Trend. A theme that has doubled in six weeks is a different object from one that has been flat for a year at the same volume. Acceleration is often a better signal of an emerging problem than absolute size.

Renewal and risk exposure. A theme raised by accounts approaching renewal, or by accounts that have signalled churn risk, carries weight that raw volume cannot see.

None of these require a scoring formula. They require the requests to be grouped into themes and the themes to carry their account context — which is exactly the information a flat request list discards.

Where does RICE fit, then?

As a final-stage tool, not the whole method — and it is genuinely useful there.

RICE (reach, impact, confidence, effort) was built by Sean McBride's team at Intercom in 2016 to compare project ideas against a single goal. It does one job well: forcing you to make your assumptions explicit and comparable, so a decision reads as "X scores higher than Y because of these four factors" rather than "X feels more important." That transparency is worth having.

Its weakness is the one every honest guide eventually admits: it asks you to estimate reach and impact you often cannot estimate, and a precise-looking score built on guesses can be more misleading than an honest ranking by revenue. The fix is not to abandon RICE but to feed it better inputs. Run it on themes, not raw requests, with real account and revenue numbers standing in for the "reach" and "impact" you would otherwise guess. A framework fed measured inputs is useful; the same framework fed gut estimates is theatre.

So the order is: group requests into themes, weight the themes by account and revenue context, then — if you want a comparable score across the top candidates — apply RICE or a simpler value-versus-effort grid to those few. The framework is the last 10% of the work. The unit you feed it is the other 90%, and it is the part every framework guide skips.

What about the request from your single biggest customer?

Handle it as its own case, because it breaks the theme logic in a way worth naming.

When one account represents a large share of your revenue, their request does not need to recur across other accounts to matter — the revenue weighting already makes it significant on its own. This is not a failure of the method; it is the method working. A single enterprise account worth a large sum is a legitimate top priority even as a theme of one.

The trap is the opposite case: a loud request from a mid-tier account that feels urgent because it was raised forcefully, recently, or by someone senior. That is exactly the noise the theme-and-weight approach exists to filter. The test is simple — strip the volume and the recency, look at the accounts and the revenue, and see whether it still ranks. If it only ranked because it was loud, it was never a priority.

Vote-counting vs. theme-weighting, compared

When this doesn't apply

If you talk to every customer and hold the whole request list in your head, you are already weighting by account context intuitively, and formalising it adds process without adding insight. This matters at the volume where you can no longer read everything.

If you are pre-product-market-fit and still discovering who your customer even is, revenue-weighting can mislead you — the accounts you have may not be the accounts you want, and optimising for their themes can pull you deeper into the wrong segment. Early on, a loud signal from the right kind of customer may be worth more than a well-weighted one from the wrong kind.

And weighting is not deciding. A well-ranked list of themes tells you what is worth considering, not what to build. Strategy still vetoes — a high-revenue theme that pulls you away from where you're going is one you may correctly decline. The ranking narrows the field; it does not make the call. How a weighted theme becomes an actual defensible decision is covered in how customer feedback becomes a product decision.

Frequently asked questions

1. Should I stop using RICE entirely? No. Use it on the right unit and at the right stage — on a shortlist of weighted themes, not on a flat list of raw requests. RICE's job is to make a final comparison transparent. It was never meant to be the mechanism that turns hundreds of scattered requests into a shortlist; that is a grouping-and-weighting problem it doesn't address.

2. Isn't revenue-weighting just building for whoever pays most? It's building for whoever pays most among customers with a real, recurring problem — which is different from building whatever a big account casually asks for. Revenue is one weight among several, alongside trend and severity. It stops trial-tier volume from outvoting enterprise need; it doesn't hand the roadmap to your largest logo.

3. How do I weight requests if I don't have revenue data per account? Start with account tier or a rough size band if exact revenue isn't to hand — even "enterprise / mid / trial" as a three-way split beats a flat count. The point is to stop treating every voice as equal weight. Precision can come later; the ranking improves the moment any account context enters it.

4. What if two themes have similar weight? That's where a framework earns its place. When revenue and account context can't separate two themes, apply effort and confidence — the cheaper, more certain one usually wins. This is the narrow, correct use of RICE or a value-versus-effort grid: breaking ties among a weighted shortlist, not ranking the whole board.

5. Does this work for bugs and tech debt too? Partly. Bugs group into themes the same way and carry the same account weighting, so the approach transfers. Tech debt is different — its value is often internal (velocity, risk) rather than customer-visible, so it needs a parallel track and a reserved share of capacity rather than competing directly in the same ranking.

Lane does the grouping and weighting for you: it clusters scattered requests into themes, attaches the accounts and revenue behind each one, and gives you a ranked list of problems worth solving — so any framework you apply is working on the right unit.