How to Prioritize Feature Requests Without Guessing
To prioritize feature requests, do three things in order. Put every request in one place. Attach evidence to each one (who asked, how many, how badly it hurts). Then score the requests against a small set of criteria you agreed on beforehand. Skip the evidence step and the scoring is only a tidy way of presenting opinions.
This guide covers that process, how to choose between RICE, MoSCoW and a simple value-versus-effort grid, and the mistakes that quietly wreck a backlog.
TL;DR
- Collect requests in one place first. Scoring ideas scattered across email, chat and calls rewards whoever shouts loudest.
- Work in two layers: an evidence layer that validates the problem, then a scoring layer that weighs feasibility and strategic fit.
- Pick the framework to fit your team: a value-versus-effort grid for small teams, RICE for larger ones with data, MoSCoW for fixed-scope releases.
- Use 4 to 8 criteria, with at least two about users and two about the business.
- Close the loop. Mark statuses, say no clearly, and archive ideas that never gain support.
Table of Contents
- Why scoring alone does not work
- Step 1: Put every request in one place
- Step 2: Add evidence before you score
- Step 3: Choose a framework that fits your team
- Step 4: Sanity-check the ranking
- Step 5: Show your decisions
- Keep the backlog clean
- Our perspective
- Run the process on one board
- FAQ
- Sources
Why scoring alone does not work
A request is a proposed solution. Behind it sits a problem the customer may or may not have described well. Marty Cagan of the Silicon Valley Product Group has described how product managers show him elaborate spreadsheets that weight cost, complexity, risk and customer importance for a long list of requests. His point is that the real work is product discovery: finding something valuable, usable and feasible. Ranking requests is not that work.
The data backs up the caution. Pendo research, summarized by Dovetail, found that 80% of software features are rarely or never used. Much of that waste comes from building what was asked for without checking the need behind it.
So the process below has two layers, and the order matters:
- Evidence layer: is this a real, recurring problem for people we want to serve?
- Scoring layer: given that it is, how does it compare on reach, impact, effort and strategic fit?
Step 1: Put every request in one place
You cannot prioritize what you cannot see. Requests normally arrive through support tickets, sales calls, Slack threads, social posts and personal emails. Each channel gives you a different sample of your users. Sales hears from prospects, support hears from frustrated users, and neither hears from the quiet majority.
A single board fixes most of this. Each idea gets one entry, and people who want the same thing vote on it instead of sending a duplicate email. The vote count becomes your first, cheap demand signal. If you want a deeper look at intake channels, our guide on how teams collect user feedback through always-on channels covers it, and a feature request template helps people describe the problem rather than just the solution.
Two habits keep the board usable:
- Merge duplicates quickly. Ten posts asking for the same thing should be one idea with ten votes.
- Ask for the job, not the feature. "I need to export last month's data for my accountant" tells you more than "add a PDF button."
Step 2: Add evidence before you score
Votes are a start, not a verdict. Before an idea goes into scoring, give it a short evidence note. Four questions are enough:
- Who asked? Are they in a segment you are trying to win or keep?
- How many? Votes, support tickets and sales mentions, counted once per person.
- How painful? Is there a workaround, and how ugly is it?
- What does usage data say? Does behavior in your product back up the claim?
Decide up front who a release is not for. SVPG's guidance on personas says trying to please everyone is a common mistake, and that saying no becomes possible once the team agrees on its target segments. A request from outside those segments can be real and still rank low.
Step 3: Choose a framework that fits your team
There is no perfect framework. A roundup of product prioritization frameworks from monday.com makes the same point: the right choice depends on team size and product stage. Small teams do well with a lightweight value-versus-effort matrix. Larger teams need the structure of RICE or Opportunity Scoring. Early-stage products lean on opportunity scoring to find product-market fit, and mature products lean on Kano analysis to optimize.
| Framework | Best for | What you need | Watch out for |
|---|---|---|---|
| Value vs. effort grid | Small teams, quick triage | Rough estimates | Gut-feel "value" scores |
| RICE | Ranking many requests with data | Reach and effort numbers | False precision on Impact and Confidence |
| MoSCoW | Fixed-scope releases and sprints | Agreed release goal | Everything becoming a "Must" |
| Kano | Mature products | Survey responses | Needs customer research time |
RICE scoring
RICE stands for Reach, Impact, Confidence and Effort. The formula, as given by monday.com, is (Reach × Impact × Confidence) / Effort. It is better for quantitative ranking when you have enough user data.
A worked example with invented numbers, for illustration only:
| Request | Reach (users/quarter) | Impact (0.25 to 3) | Confidence | Effort (person-months) | Score |
|---|---|---|---|---|---|
| CSV export of reports | 800 | 1 | 80% | 1 | 640 |
| Slack notifications | 400 | 2 | 100% | 2 | 400 |
| Dark mode | 1,500 | 0.25 | 50% | 1.5 | 125 |
CSV export wins even though dark mode reaches more people, because the impact per person is small and confidence is low. Notice what the score does not tell you: whether CSV export solves the right problem. That is the evidence layer's job. For the pitfalls in more depth, see our write-up on RICE feature scoring.
MoSCoW
MoSCoW sorts work into Must, Should, Could and Won't for a given release. It is useful for setting scope boundaries. The usual failure is category inflation, where stakeholders label everything a Must. One MoSCoW reference offers a test: if the release is unusable or not worth shipping without the item, and no workaround exists, it is a Must. The same page suggests capping Musts at around 60% of capacity.
Bring the evidence note to the workshop, so that a Must has to be argued with data. Our guide to MoSCoW prioritization for project teams shows how.
A simple scoring model of your own
If RICE feels heavy, build a short scorecard. Guidance from Nielsen Norman Group suggests 4 to 8 factors, with at least two user-oriented criteria (such as share of users affected or severity of pain) and two business-oriented ones (such as strategic alignment or return on investment). A five-criteria version might be:
- Share of target users affected (1 to 5)
- Severity of the problem (1 to 5)
- Fit with this quarter's goal (1 to 5)
- Revenue or retention upside (1 to 5)
- Effort, scored in reverse (5 is easiest)
Agree the definitions of each number before anyone scores. Otherwise "3" means something different to every person in the room.
Step 4: Sanity-check the ranking
A ranked list is an input to a decision, not the decision. Before you commit, look at the top ten and ask:
- Does this list serve one clear outcome, or is it a grab bag?
- Which items are quick wins that make the list look good but do not move the main goal?
- What would we regret not building if a competitor shipped it next quarter?
- Is any item here because a senior person asked loudly?
It also helps to ship in slices. NN/G's case study of the Vanguard mobile app describes a crawl, walk, run approach: the first version delivered 75% of top tasks, and client feedback shaped later iterations. You do not need to settle a feature's final form in the first release.
Step 5: Show your decisions
Prioritization falls apart when users cannot see what happened to their idea. Silence breeds duplicate requests and resentment. Give every idea one of a few clear statuses: under review, planned, in progress, shipped. Say no when the answer is no, and explain it in a sentence. A public roadmap turns the result into something customers can read, and a now, next, later format avoids promising dates you cannot keep. If requests also arrive by email, reply templates for support teams keep the answers consistent.
To stop roadmap and backlog from drifting apart, see our five-step playbook.
Keep the backlog clean
Ranking gets less useful when the ideas you compare have little evidence behind them. Prune on a schedule. Archive ideas with no new corroborating signal for several months, and tell the people who posted them. Keep the fresh, evidenced ideas in front of you. The old ones can come back if demand returns.
Our perspective
We built Petira because we kept seeing the same pattern: feature requests spread across emails and chats, and a product team guessing which ones mattered. Our view is that the board comes first and the framework second. Once every request sits in one place with votes, comments and a status, even a basic scorecard beats a sophisticated model fed by a memory of who said what.
We also think cost should not punish engagement. Every plan includes unlimited users, ideas and votes at a flat rate, so you never have a reason to discourage customers from voting. And votes are a signal, not an instruction. Treat them as the start of your evidence note, then do the discovery work to understand the problem behind them.
— Aron
Run the process on one board
If you want a place to try this, Petira gives you a public feedback board with voting, comments, statuses from under review to shipped, a public roadmap, and CSV and JSON export. You can import existing feedback from Canny, Fider or a CSV file. There is a Free plan at €0 per month, Pro at €19 per month (€190 per year) and Team at €49 per month (€490 per year). See the plans and pricing, or the Petira homepage for an overview. If you are weighing tools, our comparison of 12 feedback tools' pricing lays out the numbers.
FAQ
What is the simplest way to prioritize feature requests?
Plot each request on a two-by-two grid of value to users against effort to build. Do high-value, low-effort items first, plan the high-value, high-effort ones, and question the rest. Back the "value" axis with votes and customer evidence instead of opinion.
Should I build the most-voted feature first?
Not automatically. Votes show demand but not the underlying problem, the voter's segment or the effort involved. Use them as one input alongside impact on your target users and strategic fit.
How many criteria should a scoring model have?
Aim for 4 to 8, as NN/G guidance suggests, with at least two about users and two about the business. Fewer than four is too thin to separate ideas, and more than eight makes scoring slow and invites argument.
How do I stop everything becoming a Must have in MoSCoW?
Set a ceiling on how much capacity Musts can take, around 60% according to one MoSCoW reference, and require evidence for each one. Define a Must as something without which the release is unusable or not worth shipping, with no workaround.
Sources
- Product Roadmaps, Silicon Valley Product Group
- Personas for Product Management, Silicon Valley Product Group
- How to Prioritize Product Features, Dovetail
- Product Prioritization Frameworks: The Complete Guide For 2026, monday.com
- MoSCoW Prioritization Framework, WhichFramework
- The 6 Steps to Roadmapping, Nielsen Norman Group
- Prioritizing User Needs: Vanguard Mobile App, Nielsen Norman Group