Prioritising feature requests means triaging first (duplicate, out of scope, needs detail, real), then ranking the real ones with a framework that weighs impact against effort. Vote counts alone are a poor signal, because the loudest requesters are rarely your most valuable customers, and every list will contain items you will never build.
This page is one part of a larger guide. For the whole subject in one place, see feature request tools.
Why is triage the first step, not prioritisation?
Prioritisation frameworks compare things that deserve comparing. Most incoming requests do not deserve that yet. Run every new one through triage first.
- Duplicate. Merge it into the existing request and carry the vote across, rather than leaving two half-supported entries competing for attention.
- Out of scope. Say so, plainly, and close it. A request that fights your product's direction should not sit open collecting votes.
- Needs more detail. A one-line request ("make it faster") is not yet a feature. Ask what the person is trying to do, then reopen the triage once you have an answer.
- Real. Specific enough to build, consistent with your direction, not already covered. Only this category moves on to a framework.
A feature request board earns its keep here: mix duplicates and settled decisions in with active requests, and the whole board reads as noise.
Which prioritisation framework should you use?
Four are in common use: RICE, ICE, MoSCoW and the Kano model. They cost different amounts of admin, and for most small products only one or two are worth the time.
| Framework | What it measures | Effort to run | Who it suits |
|---|---|---|---|
| RICE | Reach, impact, confidence, effort as a single score | Medium, four numbers per request | Teams with enough requests to need a ranked list |
| ICE | Impact, confidence, effort as a single score | Low, three numbers per request | Small teams, fast weekly triage |
| MoSCoW | Must, should, could, won't, as a fixed release scope | Low, a label not a score | Deciding what ships in one release, not ranking a backlog |
| Kano | Whether a feature delights, satisfies, or is just expected | High, needs customer survey data | Products with the volume to run structured customer research |
How does RICE actually work? A worked example
RICE scores a request on four numbers: reach (people affected), impact (how much it moves the needle for them), confidence (how sure you are of the first two), and effort (time to build it). Reach times impact times confidence, divided by effort.
Illustrative example, invented for this post. A small team gets a request for CSV export. They estimate reach 40 (customers who'd use it this quarter), impact 2 (on a 0.25 to 3 scale), confidence 0.8 (decent evidence from support tickets), effort 3 (person-weeks): 40 times 2 times 0.8, divided by 3, is 21.3.
Compare a full permissions system: reach 15, impact 3, confidence 0.5, effort 8. That's 15 times 3 times 0.5, divided by 8, which is 2.8.
CSV export wins by a wide margin on these invented numbers, not because it's more exciting, but because it's cheap and the team is confident about its effect. That is the value of RICE: it forces effort and confidence into the open.
How does ICE work? A worked example
ICE drops reach: impact, confidence and effort are each scored, usually 1 to 10, and multiplied rather than divided.
Illustrative example, invented for this post. Same CSV export request: impact 7, confidence 8, effort 3 (high because low effort is good), gives 168. A dark mode request scores impact 5, confidence 6, effort 6, giving 180. Dark mode edges ahead, but the scores are close enough that these are really tied. That is what ICE is good for: a fast gut check, not a precise ranking. Read a wide gap as signal, a narrow one as noise.
Is RICE or ICE worth the overhead for a small product?
Not as a running weekly process. RICE assumes real reach data, meaning usage analytics or a decent volume of requests to estimate from, and guessing four numbers per request to produce a spreadsheet nobody reopens is busywork dressed as rigour. The honest use is occasional: run ICE, not RICE, once a quarter over your open board, to catch anything quietly outranking your gut sense. Skip it under ten open requests, where you already know which one matters most.
What is MoSCoW for, and is it worth using?
MoSCoW sorts a fixed batch of work into Must have, Should have, Could have and Won't have, for one release rather than an open-ended backlog. It answers a different question to RICE or ICE: not "which is most valuable", but "what ships this cycle".
Illustrative example, invented for this post. A team scoping their next release: Must have, fix the export bug blocking a customer's compliance report. Should have, the CSV export request above. Could have, dark mode. Won't have this cycle, the permissions system, explicitly, so nobody re-raises it as an oversight.
MoSCoW earns its keep when a release has a real boundary. It is the wrong tool for ranking an open board, because "Won't have" carries no time horizon, and a label with no horizon becomes a polite way to never answer.
What is the Kano model, and when does it earn its cost?
Kano groups features by the reaction they produce, from survey answers rather than internal estimates: basic (expected; its absence causes real anger), performance (more is proportionally better), and delighter (unexpected, and what gets talked about).
Illustrative example, invented for this post. For a support tool, "the page loads" is basic; its absence is a five-alarm complaint. "Faster search" is performance, roughly linear. An AI-drafted first reply to a new request is a delighter; most people don't expect it, and the ones who get it mention it.
Kano needs a structured survey, each feature rated on how a customer feels if it exists and if it doesn't, to produce a real answer rather than a guess wearing its vocabulary. That is genuine overhead: designing the survey, gathering responses, coding results. It earns its cost on a mature product weighing a few expensive roadmap bets. For a small product triaging a weekly stream of requests, use the plain English version as a gut check, and skip the formal survey.
One payment, no subscription, unlimited products.
Why do raw vote counts mislead?
A vote count answers "how many people clicked", not "how much does this matter". Three ways it goes wrong:
- It rewards visibility, not value. A request posted early, or shared by someone who emailed their whole team a link to vote, accumulates votes for reasons unrelated to the feature's worth.
- It treats every voter as equal. A vote from your highest-tier customer and one from a free trial that never converted count identically on a raw tally, though they aren't remotely equivalent.
- It says nothing about cost. The most-voted request is often also the most expensive to build, and a vote count carries no information about that.
Use votes as one input to triage, to catch requests that are quietly popular, not as the ranking itself. A framework, however coarse, does a job a raw count cannot: weighing value against cost in the same number.
What do you do with the request that ten people want and you will never build?
This is the case every prioritisation guide skips, and it happens on every board with real usage. Ten people asking is real signal. It still might not be worth building: it may conflict with your product's direction, those ten people may not be the customers you're building for, or the cost may never clear the bar.
Do not leave it open collecting votes it will never convert into work. An open request that will never ship is a quiet promise you're not keeping, and it makes your board a worse source of truth than an honest no. Close it, publicly, with a real reason.
How do you say no publicly without losing the person?
Reply on the request itself, so the reasoning is visible to everyone who voted, not just the requester. State the actual reason, cost, direction, or a conflict with something already committed to, rather than a vague "not right now" that reads as a door left ajar. A deferral you never revisit is worse than a clear no.
Thank people for the specificity of the request, not for their patience. Telling them clearly it won't happen, with a reason, closes the loop better than silence. Silence is what actually costs you the person: they don't stop wanting the feature, they stop trusting the board does anything.
A public no, with a reason, sitting next to every other decision made in the open, is evidence the process is real. Collecting requests without ever declining any is avoidance with better manners. If you haven't read how to collect feedback from customers, the collection step is where this process starts.
Frequently asked questions
What is the simplest way to prioritise feature requests?
Triage every request into duplicate, out of scope, needs more detail, or real, and only run a framework over the real ones. For a small product, a quarterly ICE pass over open requests, plus MoSCoW when scoping an actual release, covers most of what a small team needs without turning prioritisation into its own project.
Should I let customers vote on feature requests?
Voting is useful as one input to triage, to surface requests that are quietly popular, but it should not be the ranking itself. A vote count says how many people clicked, not how valuable the feature is or what it costs to build, so treat it as a signal to check, not a scoreboard to follow.
What's the difference between RICE and ICE?
RICE adds a reach number, how many people a request affects in a given period, to impact, confidence and effort, and divides rather than multiplies. ICE drops reach and is faster to run. RICE suits teams with real usage data to estimate reach from; ICE suits a faster, coarser gut check on a smaller list.
When should I use MoSCoW instead of RICE or ICE?
Use MoSCoW when scoping a specific release with a fixed deadline, to decide what's in and out of that cycle. Use RICE or ICE when ranking an open-ended backlog with no release boundary attached. MoSCoW answers "what ships this time"; RICE and ICE answer "which is more valuable".
Is it bad to close a feature request without building it?
No, the opposite. An open request that will never ship is a quiet promise you're not keeping, and it makes your board less trustworthy over time. Closing it publicly with a specific reason, cost, direction, or a conflict with an existing commitment, is more honest than leaving it open, and it's what keeps people willing to ask again.