How to prioritize feature requests: votes, RICE and revenue

You will always have more requests than capacity. The goal isn't a perfect ranking. It's a choice you can defend, including to the users whose request didn't make the cut.

What signals should you use to prioritize feature requests?

Each common signal answers a different question, and each one misleads in its own way.

Use them together. Where they agree, decide fast. Where they disagree, that's the conversation worth having.

Why aren't votes enough on their own?

Votes measure who showed up to your board, not your whole customer base. Other blind spots:

• Old requests pile up votes just by being visible longer.
• Duplicates split demand. "Dark mode" with 30 votes and "night theme" with 12 is really one request with up to 42 (anyone who voted for both counts once). Merge first, as covered in how to handle duplicate feature requests. The duplicate request finder helps with a messy backlog.
• Votes ignore cost. A request with 40 votes that takes three months may be worth less than one with 15 votes that takes two days.

Clean vote counts are still your best signal for breadth of demand. Just don't build top to bottom.

How do you weight requests by revenue?

Attach account data to each voter: plan and what they pay. Then total it per request. Take a fictional invoicing app:

• Recurring invoices: 52 voters, $3,000 a month in combined revenue
• Custom invoice fonts: 30 voters, $900 a month
• Single sign-on: 4 voters, $2,500 a month

Votes alone put SSO last. Revenue shows four accounts paying almost as much as 52. Neither number decides alone, but SSO is clearly a real conversation, not noise.

Two cautions. Note when one account makes up most of a request's revenue, because building for one customer is a different decision from building for a segment. And track deal-blockers from prospects separately, since they don't show up in current revenue.

How do you combine votes, RICE and revenue?

1. Clean the list. Merge duplicates and close requests that are stale or already solved.
2. Shortlist. Take the top ten by votes and the top ten by revenue. Combined, that's at most 20 items, and usually fewer because the lists overlap.
3. Score the shortlist with RICE. Ground Reach in analytics, treating vote counts as a floor, and set Confidence by how much evidence you actually have. The RICE framework guide walks through scoring, and the RICE calculator does the math.
4. Check against strategy. Does it serve the one or two goals you set for this quarter? If not, defer it and write down why.
5. Commit and say so. Move chosen items to Planned and tell the voters. See how to run a public roadmap users trust.
6. Revisit on a schedule. Monthly for small teams, or at the start of each cycle.

Score only the shortlist. Scoring 200 requests with RICE takes days and produces false precision.

What are the common mistakes?

• Building the top-voted list in order. It rewards the loudest users and ignores cost.
• Letting the biggest customer write the roadmap. Serve them, but check whether anyone else has the same problem.
• Ignoring bugs and debt. They rarely get votes. Reserve capacity for them instead of making them compete with features.
• Not recording why you said no. Six months later, nobody remembers, and the same debate starts again.
• Re-ranking every week. Constant reshuffling means nothing ships. Set a cadence and hold it.

Doing this with Sikia

Sikia suggests merging duplicate requests as votes with each user's quote attached, which keeps vote counts closer to real demand. Statuses on the board (Open, Planned, In progress, Shipped, Closed) build the public roadmap. Its MCP server includes a top_requests tool, so you can pull the most-requested items into Claude Code or Cursor while you plan.

FAQ

Should I let users vote on feature requests?

Yes, as one input. Votes are a cheap way to see breadth of demand, as long as you merge duplicates and don't treat the ranking as a commitment.

What's the simplest prioritization method for a small team?

Plot shortlisted requests on a value-versus-effort grid and start with high value, low effort. Move to RICE when the shortlist gets long or the debates get heated.

How often should I re-prioritize feature requests?

At a fixed cadence, such as monthly or at the start of each cycle. Re-prioritize sooner only when something big changes, like a major customer leaving.

What should I tell users whose request I won't build?

Tell them directly, with the reason and any workaround. A clear no keeps more trust than a request that sits open forever.