How to prioritize feature requests (and where RICE breaks)

Every team eventually has more feature requests than capacity, adopts a scoring framework, and six months later quietly stops using it. The framework isn't usually the problem. The inputs are: the requests being scored are a biased sample of what customers actually asked for, and the scores are guesses dressed as numbers.

So this guide is ordered accordingly — fix the inputs first, then score, then decide what the score doesn't cover.

Step 1: score requests, not memories

Prioritization done from memory optimizes for whoever asked loudest and most recently. Before any scoring, you need the actual population of requests: the Slack thread where a customer wrote "honestly we'd pay more for SSO tomorrow," the Zendesk ticket asking for CSV export for the third time, the sales call where the prospect said the missing audit log was the blocker.

That means aggregating feedback from every channel into one place and deduplicating it, so "SSO" is one entry with 23 requesters rather than 23 scattered mentions. Do this manually with a spreadsheet and a weekly sweep if volume is low. We build Modem, which does this part automatically — capture from chat, support, and sales calls, dedupe, and requester lists with company and revenue attached — and it exists because the manual version is the step teams abandon first. The dedupe and the revenue linkage come from the same structure, a context graph connecting each request to the people and accounts behind it; every scoring pass below leans on that linkage. If your volume is a handful of requests a week, the spreadsheet is genuinely fine.

Step 2: attach who, not just how many

Twenty-three requests is a count. Which twenty-three matters more:

• Are they concentrated in one segment (all enterprise, all trial users, all one industry)?
• What revenue do they represent, and is any of it at renewal risk?
• Did any of them describe it as blocking, or was it a nice-to-have aside?

A request from a churning $80k account and a request from a free-tier user are not two votes for the same thing. Weighting feedback by ARR and segment rather than treating every mention equally is standard practice in feedback analysis for exactly this reason (Perspective AI has a good treatment). We cover the mechanics in how to quantify feedback.

Step 3: apply RICE — knowing what it is

RICE scores each candidate as Reach × Impact × Confidence ÷ Effort. It's popular because it's simple and it forces the conversation to name its assumptions. With clean inputs from steps 1–2, Reach stops being a guess (it's your deduped requester count) and Confidence stops being vibes (it's how directly the evidence supports the request).

Run it lightweight: score in a one-hour session, argue only where scores diverge wildly, and don't defend a 3.2-vs-3.4 difference — the precision is fake.

Step 4: know where RICE breaks

Four failure modes show up consistently:

• It ignores strategy. RICE ranks isolated candidates against each other; it has no term for "this is the bet the company is making." Critics argue this makes frameworks local optimization at the expense of strategy (Michael Goitein's essay is the sharpest version of the case). Fix: decide strategic themes first, run RICE within them.
• Impact inflation. Everything gets Impact 2 or 3 because everything feels important, and if everything is high impact, nothing is — a scoring mistake called out in Quackback's prioritization guide. Fix: force-rank Impact so the scale keeps meaning.
• The score as a conversation-ender. The number gets held up as proof of due diligence instead of a summary of assumptions. If nobody can challenge an input, the framework has become theater.
• It can't see retention risk. Reach counts requesters; it doesn't distinguish "would be nice" from "we churn without this." That's what the revenue and segment context from step 2 is for — it sits beside the score, not inside it.

Step 5: decide, record, and tell people

The output of prioritization is a decision, not a ranked spreadsheet. For the top items, write one sentence of rationale ("SSO: 23 requesters, $310k ARR represented, blocks two open enterprise deals"). For requests you're declining, say so — a "not planned, here's why" reply costs a minute and preserves trust in a way silence doesn't.

And when a prioritized request ships, the requester list from step 1 is who you tell. Prioritization that never closes the loop trains customers to stop telling you things.

The smallest version this week

Make one spreadsheet: one row per distinct request, columns for count, segments, ARR represented, and a rough RICE score. Populate it from the last 30 days of support tickets and Slack. Rank it, pick the top three, and write the one-sentence rationale for each. That's a functioning prioritization system; everything past it is automation and refinement.