To prioritize feature requests, score each one on four weighted factors: revenue impact, customer impact, strategic fit and effort. Then check the ranking against RICE and Kano, because each framework misjudges different requests. Below, six sample requests go through all three, showing exactly where the order breaks.
Key takeaways
- Score every feature request against four fixed criteria: revenue impact, customer impact, strategic fit, and effort, with weights set before you see the requests.
- Run a four-gate pre-filter (duplicates, non-users, already committed, legal or platform constraints) before anything touches your scoring matrix.
- RICE rewards breadth and punishes delighters, Kano rewards delighters and ignores cost, and weighted scoring rewards whatever you weighted; the disagreement between them is the finding.
- A loud customer’s request wins only when you can name the revenue attached to it, the customer is representative, and the ask is a must-have rather than a delighter.
- Re-score new requests weekly on arrival, run the full re-score quarterly, and re-score everything immediately after events like a pricing change.
How do you score a feature request objectively instead of arguing about it?
Replace the debate with a fixed weighted scoring model: define four criteria, agree on weights once, then score every request against the same rubric. The argument moves from “I think this is big” to “what score does this earn on the scale we already agreed.” PMs on the Atlassian Community report exactly this gap: effort is easy from swag estimates, but defining Impact stalls because it mixes new revenue, better UX, and stickiness (Atlassian Community).
Pick four criteria, not ten
Use revenue impact, customer impact, strategic fit, and effort. Four is enough to capture impact to the business and impact to customers without turning scoring into a research project. Ten criteria means nobody scores consistently and the weights become noise.
Set the weights before you see the requests
Decide, say, revenue 35%, customer 35%, strategic fit 20%, effort 10%, in a session with no backlog in front of you. Weights set after seeing the requests quietly bend toward whoever is arguing hardest.
What disqualifies a feature request from scoring in the first place?
Score the wrong requests and the whole exercise is theater. Run every incoming request through four gates before it touches your matrix.
The four-gate pre-filter
Gate 1: Duplicates. Five customers asking for the same thing is one request with five votes, not five requests. Merge them and track the count.
Gate 2: Non-users. A request from someone who doesn’t pay for or use your product gets weighted separately or dropped. It’s not evidence about your roadmap.
Gate 3: Already on the roadmap. If it’s committed this quarter, re-scoring it wastes the session and invites relitigating decisions.
Gate 4: Legal or platform constraints. Anything that violates app store rules, data regulations, or a platform dependency you don’t control is out regardless of score.
Filtering first is what makes a scoring session end with an agreed plan instead of a wall of sticky notes. The same pre-filter applies whether requests arrive by email or everyone contributes from their phone in a live session (how product teams run this).
How do you define ‘Impact’ when it means revenue, UX, and stickiness at once?
Split it. “Impact” fails as a single score because it mixes two different questions: what the feature does for your business, and what it does for the user’s day. Score them separately, then weight them, and the arguments become checkable instead of loud.
Impact to the business: tie it to a number
Pick the metric your team already reports: new revenue, expansion revenue, or retention dollars. If you cannot connect the feature to one of those, its business impact is low by definition, not by opinion. This mirrors the Reach-and-Impact logic in Intercom’s original RICE writeup, where Impact is defined against a concrete conversion or revenue outcome.
Impact to customers: pick one proxy and stick to it
Choose one proxy: hours saved per user per week, or steps removed from a core flow. One proxy, applied to every request, beats a bespoke justification per feature. This is the same discipline you’d want in a brainstorm tool. Prioritas is built for one job: deciding what to do first. See how it compares with Miro.
A 1-5 scale with written anchors
| Score | Business impact | Customer impact |
|---|---|---|
| 5 | Opens a new revenue line | Removes a core workflow blocker |
| 3 | Measurable expansion or retention lift | Saves hours weekly |
| 1 | No clear line to a metric | Cosmetic polish |
Written anchors stop score inflation.
How do RICE, Kano, and weighted scoring produce different priorities for the same requests?
The six sample requests
Take a typical quarterly batch: (1) single sign-on for enterprise deals, (2) a dark mode toggle, (3) an API for partner integrations, (4) faster report load times, (5) a mobile app, (6) bulk CSV import. Same six requests, three frameworks, three different answers.
Scoring them through RICE
RICE multiplies Reach × Impact × Confidence ÷ Effort. Bulk CSV import wins because every account touches it and effort is low. Single sign-on ranks mid: low reach (only enterprise accounts) but high impact. Dark mode sinks despite customer enthusiasm because RICE has nowhere to put “delighter with no revenue.”
Scoring them through Kano
Kano classifies requests as basic, performance, or excitement attributes, so it flips the board. Faster load times and single sign-on rank top as must-haves; dark mode jumps up as an excitement feature. But Kano says nothing about effort, so a two-week delighter and a six-month one sit side by side.
Scoring them through weighted scoring
Weighted scoring with the weights above puts single sign-on first, API second, CSV import third. It is the only method that lets you tune the weights to your quarter.
Prioritas doesn’t do weighted scoring: an idea’s quadrant comes from where it is placed on the impact-effort matrix. For a tool built around voting on value and effort, see Prioritas vs Impactor.
Where each framework breaks down
The disagreement is the finding, not the failure. RICE rewards breadth and punishes delighters; Kano rewards delighters and ignores cost; weighted scoring rewards whatever you weighted, so a bad weight choice silently reranks everything. Trust RICE when reach data is solid, Kano when you need to separate must-haves from nice-to-haves before costing anything, and weighted scoring when you need one defensible number per request and can defend the weights out loud. If the three methods agree on a request, ship it without another meeting.
When should revenue impact outweigh the loudest customer’s request?
Use one decision rule: a loud customer’s request wins only when you can name the revenue attached to it. “Acme wants single sign-on, and Acme is 20% of ARR with renewal in Q3” is a priority. “Acme wants single sign-on” is one data point.
The revenue-named test
Before a single-customer request outranks your scored backlog, it must pass three checks: it maps to expansion or retention revenue you can state in dollars or ARR, the customer is representative rather than an outlier, and the ask is a must-have, not a delighter. Kano’s model is useful here because must-be requirements and performance requirements behave differently from attractive ones; attractive features create satisfaction when present but no dissatisfaction when absent (Kano model).
A loud voice can still dominate a live session. In Prioritas, an idea sent from a phone shows the participant’s name on its matrix card. For another way to run a facilitated session, see Prioritas vs Decideli.
How do you turn scores into a ranked backlog your team actually agrees on?
Score together, not serially
Run the scoring in one live session where every teammate contributes from their own device. Everyone adds ideas, swag estimates, and impact notes from their phone, then places them on the same matrix together. Agreement comes from shared scoring, not from the loudest voice in the room. A wall of sticky notes produces a week of follow-up threads; a scored matrix produces a decision before the meeting ends.
From matrix to ranked list in one artifact
The matrix alone isn’t the deliverable. Convert it into a ranked list ordered by score, with each item’s impact and effort visible, so the teammate who missed the session reads the same priority order you agreed on. If the write-up requires re-reading every note and re-classifying quadrants by hand, the session failed. The output should be one artifact: scored, ranked, and shareable the moment the meeting closes.
How often should you re-score the feature request backlog?
Tie re-scoring to your planning cadence, not to a calendar you forget. Do a light weekly pass: new requests get scored on arrival, and anything already in the backlog stays untouched unless effort estimates change.
Weekly vs quarterly re-scoring
Run the full re-score quarterly, because that is when your weights legitimately change: pricing shifts, a new segment, a strategy pivot. Revenue impact scored in January means little after a pricing change in March. Event-driven re-scoring beats both cadences when the market moves under you.
The failure mode is a backlog scored once and defended forever. A wall of sticky notes from one workshop ages just as badly; scores do too.
How do you communicate a ‘no’ after prioritization without losing the customer?
Show the rubric, share the condition
A ‘no’ lands badly when it looks like a veto. It lands fine when it looks like arithmetic. Share the weighted criteria you scored against, then show where the request landed relative to the ones that made the roadmap. “You scored 2.1 on impact-to-the-business; the three items ahead of you scored 4.0 or higher” is a process the customer can argue with, which beats a rejection they can’t.
Then give the condition that would flip the outcome. If two enterprise customers request the same workflow gap, say so: “Three customers asking moves this from 2.1 to a re-score next quarter.” That converts a dead end into a trigger they can influence.
Log it visibly. A request that sits in a scored backlog with a date attached reads as “queued,” not “ignored,” and it survives the person who took the meeting leaving the company.
FAQ
What is the best framework for prioritizing feature requests for a small team?
There is no single best one; each misjudges different requests. RICE rewards breadth and punishes delighters, Kano separates must-haves from nice-to-haves but ignores effort, and weighted scoring rewards whatever you weighted. Run your shortlist through weighted scoring, then sanity-check the ranking against RICE and Kano. If all three agree on a request, ship it without another meeting.
How many criteria should a weighted scoring model have?
Four: revenue impact, customer impact, strategic fit, and effort. That covers impact to the business and impact to customers without turning scoring into a research project. Ten criteria means nobody scores consistently and the weights become noise. Set the weights once, before any requests are visible, so they don’t bend toward whoever is arguing hardest in the room.
Should effort be scored by hours or by t-shirt size?
T-shirt sizes (S/M/L or a 1-5 scale) work fine for ranking, and swag estimates are usually all you have at scoring time. What matters is using the same scale for every request and writing anchors, like “small: under a week” for a 1. Hours invite false precision; the goal is a defensible relative order, not a project plan.
How do you handle feature requests from your biggest customer?
Apply the revenue-named test: the request wins only when you can state the revenue attached, the customer is representative rather than an outlier, and the ask is a must-have rather than a delighter. “Acme is 20% of ARR with renewal in Q3” is a priority. “Acme wants it” is one data point. Score it like everything else.
Can I combine RICE and Kano in the same prioritization process?
Yes, and the disagreement is useful. Score with weighted criteria to get one defensible number per request, then use Kano to classify which requests are must-haves versus delighters before costing anything, and RICE to check where reach data is solid. When the methods disagree, the mismatch tells you which assumption, reach, cost, or delight, is doing the damage.