Most feedback tools rank requests by upvotes. It feels fair: the most-wanted thing wins. But an upvote count answers the wrong question. It tells you who's loudest, not who's at risk.
The customer quietly renewing a six-figure contract rarely campaigns for votes. The ten free-tier users who will never convert often do. Rank by volume and you optimize for noise. It's the model behind upvote boards like Canny, and the reason we built Crumb as an open-source Canny alternative that weighs requests by revenue instead. Here's how to prioritize feature requests in a B2B product, framework by framework.
The common frameworks, and where they break
Every framework tries to answer one question: which request delivers the most value for the effort? They differ in how they estimate the value.
RICE
RICE comes from Intercom. You score each idea on Reach (how many people it affects in a set period), Impact (a multiplier from 0.25 for minimal to 3 for massive), Confidence (100%, 80%, or 50%), and Effort (in person-months), then compute Reach × Impact × Confidence ÷ Effort.
Where it breaks: Reach counts people, not what they're worth to you. In a B2B product, a request from forty free users outscores one from five people at an account that pays you six figures. Impact and Confidence are judgment calls that look precise once they're numbers. Intercom's own write-up says the score shouldn't be followed blindly; dependencies and table-stakes features are good reasons to override it.
ICE
ICE, credited to Sean Ellis, rates Impact, Confidence, and Ease from 1 to 10 and multiplies them, as Itamar Gilad explains. It's fast, which makes it handy for long lists of small bets.
Where it breaks: all three inputs are opinions, so the score mostly reflects who filled in the spreadsheet. Gilad's fix is to base confidence on evidence rather than conviction. ICE also has no idea who's asking: a request from your largest customer and one from a trial user can score the same.
Value vs. effort
The simplest option: plot each request on a 2×2 of value against effort. Nielsen Norman Group's guide to prioritization methods names the quadrants quick wins, big bets, fill-ins, and money pits, and positions the matrix for quick, collaborative sorting.
Where it breaks: "value" is never defined, so it drifts toward whoever argues best in the room.
The common thread: every framework needs an estimate of value, and none tells you where to get it. For a B2B team, the most objective value signal you already have is the revenue of the accounts asking.
Why weighting by revenue helps B2B teams
In Crumb, a piece of feedback isn't a floating idea; it's attached to the account that submitted it, and every account carries its ARR. So your inbox doesn't show "+12 upvotes." It shows Acme · $48k next to the request.
- It's a fact, not an estimate. ARR comes from your CRM or billing data. Nobody has to guess an impact score.
- It counts accounts, not people. Ten people at one customer are still one customer, so big teams and vocal users can't drown out everyone else.
- It puts renewals in view. B2B revenue renews account by account. Seeing the dollars waiting on a request shows you the risk while you're planning, not after a renewal call.
- It's easy to explain. "Three accounts worth $186k are waiting on this" ends debates that "it scored 7.2" starts.
This isn't "ignore everyone but your biggest customer." Revenue is the first lens; how many accounts are asking, how long they've waited, and segment are the next ones. The point is that the dollars are visible at the moment you decide, instead of buried in a CRM you'd have to go cross-reference.
Where revenue weighting misleads
- One big account. A single large customer can outweigh everyone else. Check how many accounts are asking and whether it's really one buyer's custom need. One big ask is a reason to talk, not an automatic yes.
- Revenue looks backward. Prospects, trials, and free users have no ARR yet, but they may be where your growth comes from. Weigh pipeline and strategy separately.
- Some work never gets requested. Security, reliability, and platform work rarely shows up in feedback and still has to happen.
- Missing data looks like zero. An account with no ARR recorded isn't worth nothing; it's unknown. Fill the gaps before you trust the ranking.
A worked example
Here's a made-up backlog of four requests, with rough engineering estimates for effort.
| Request | Upvotes | Accounts asking | ARR at stake | Effort |
|---|---|---|---|---|
| Dark mode | 41 | 2 | $12k | 3 weeks |
| Slack alerts | 14 | 6 | $96k | 1 week |
| CSV export | 9 | 3 | $186k | 2 weeks |
| SAML SSO | 3 | 1 | $240k | 6 weeks |
Ranked by upvotes, dark mode wins easily, but most of its votes come from free-tier users, and the two paying accounts behind it are worth $12k together. Ranked by raw ARR, SSO wins, but that's one account and six weeks of work.
Divide ARR at stake by weeks of effort and the order changes: Slack alerts ($96k per week of work), CSV export ($93k), SSO ($40k), dark mode ($4k). That's a stripped-down RICE, with revenue as the reach term. The CSV export is three accounts worth $48k, $34k, and $104k, so it's no single customer's wish list.
A reasonable call: ship Slack alerts and the CSV export this cycle. Before committing six weeks to SSO, talk to that account: is it a condition of their renewal, and do other enterprise prospects need it too? Leave dark mode on the board and revisit it if free-tier growth becomes the goal.
How to prioritize feature requests, step by step
- Capture requests with the account attached. A request without an account can't be weighted.
- Merge duplicates and group themes. Five phrasings of "export to CSV" are one request. Group related asks so demand adds up instead of scattering.
- Attach revenue. Sync ARR from your CRM or set it by hand. Mark unknowns as unknown, not zero.
- Rank by revenue at stake, then check reach. Count the accounts behind each figure to catch the one-big-account problem.
- Size the effort. Rough is fine: days, weeks, or T-shirt sizes. Compare value per unit of effort.
- Apply judgment. Strategy, dependencies, security, and deal-critical work can override the ranking. Write down why when they do.
- Decide, then tell people. The accounts that asked should hear the decision, yes or no. That's closing the loop. Then repeat every planning cycle, because ARR and requests keep moving.
How Crumb supports it
- Every request carries the account and its ARR. ARR syncs from HubSpot or Salesforce (Team and up on Cloud, or your own OAuth apps when self-hosting), or you set it by hand. A sync never overwrites an ARR you set by hand, and an account with no ARR shows "not set", never $0.
- The inbox sorts by revenue. Switch the sort to By revenue and requests rank by ARR at stake: the combined ARR of the distinct accounts asking, including duplicates you've merged in. How many accounts are asking and how long they've waited nudge the order within that, and so does AI severity on Crumb Cloud's Team plan and up. Hover the ARR figure to see why a request ranks where it does.
- Initiatives roll it up. Group requests into an initiative and the board shows the ARR at stake across every account with open feedback in it.
- You can ask in plain English. On Crumb Cloud's Team plan and up, "Ask your feedback" answers questions like "What integrations are people asking for?" with citations back to the requests.
Prioritizing by revenue only pays off if the account hears back. When the export ships, the customers who asked get the "it's live" note, so the prioritization they triggered becomes a relationship moment, not a silent backlog item. That's the whole loop: capture in context, prioritize by revenue, ship, and tell them. See how it fits together →
Frequently asked questions
What is the best way to prioritize feature requests?
Pair a simple scoring method with real data about who's asking. For a B2B product, start from the revenue of the accounts behind each request, check how many accounts that is, weigh it against effort, then apply judgment for strategy and dependencies.
What is the RICE framework?
RICE, from Intercom, scores an idea as Reach × Impact × Confidence ÷ Effort. Impact runs from 0.25 (minimal) to 3 (massive), confidence is a percentage, and effort is measured in person-months.
Should you prioritize feature requests by votes?
Use votes as a tiebreaker, not the main signal. In B2B they count people rather than accounts or revenue, and they reward whoever campaigns hardest. Look at the revenue and the number of accounts behind a request first.
What if one big customer asks for a feature?
Treat it as an account decision, not a roadmap vote. Check whether other accounts need it, what it costs to build and maintain, and whether it's tied to a renewal. One large account is a reason to talk, not an automatic yes.
How does Crumb prioritize feature requests?
Every request is tied to the account that sent it and that account's ARR. The inbox can sort by revenue: ARR at stake across the distinct accounts asking, nudged by how many accounts are asking and how long they've waited. Hover the figure to see why a request ranks where it does.