To prioritize feature requests, first collect them in one place and merge duplicates, so each request shows every customer who asked. Then score each one on demand (how many customers asked and how badly they need it), value (the revenue or strategic weight behind those customers), and effort (how long it takes to build). Frameworks like RICE and ICE turn those into a single number, but a short weekly review that ranks by demand and revenue, then checks effort, works for most small teams. Tell customers the outcome either way, including when the answer is no.
Every product team has more feature requests than time. The hard part is not collecting them, it is deciding which ones to build, which to park and which to turn down, and doing it in a way you can explain to the customers who asked. This guide covers six common frameworks, when each one helps, and a simple weekly process that works for small teams.
What is feature request prioritization?
The process of ranking customer requests for new features or changes by how much they matter to customers and the business, weighed against the effort to build them, so the team works on the most valuable things first.
It sits between collecting feedback and building. If you have not organized your requests yet, start with the voice of the customer guide, which covers where feedback comes from and how to gather it.
Why prioritizing feature requests goes wrong
- The loudest customer wins. One persistent account can feel like the whole market.
- Duplicates hide demand. The same need arrives as five differently worded requests in email, chat and calls, so it looks smaller than it is.
- Votes ignore value. Fifty free users asking for dark mode and three paying teams asking for SSO are not the same signal.
- Effort gets guessed late. Teams commit to a popular request and only then discover it takes a quarter.
- Nobody hears back. Customers stop asking when requests disappear, which makes the next round of prioritization worse.
Before you score anything: collect, merge, attach
No framework works on a messy list. Three things need to be true first:
- One list. Requests from your portal, support inbox, Slack, sales calls and reviews all land in the same place.
- Duplicates merged. Five versions of "export to PDF" become one request with five customers attached.
- Customers attached. Each request shows who asked, their company and, ideally, how much they pay you.
Calls are where most requests get lost. Our guide to capturing feature requests from customer calls covers that step.
6 frameworks for prioritizing feature requests
1. Votes
Rank requests by how many customers asked or voted. It is simple, visible and easy to explain, which is why public feedback boards use it. Its weakness is that every vote counts the same. Add a need level to each vote (nice to have, important, must have) and votes become much more useful.
2. Revenue-weighted votes
Rank by the total monthly revenue of the customers asking, alongside the vote count. This is the quickest way to stop a large free audience from drowning out the accounts that pay for the product, and to spot requests that block expansion or renewals. Keep an eye on prospects too: a request that keeps coming up in lost deals has revenue behind it even if no customer has asked.
3. RICE
RICE was developed by Sean McBride at Intercom. Each idea gets four estimates and a single score:
- Reach: how many people it affects in a set period, such as customers per quarter.
- Impact: how much it moves the goal for each person, scored 3 (massive), 2 (high), 1 (medium), 0.5 (low) or 0.25 (minimal).
- Confidence: how sure you are about the other numbers, as a percentage: 100% high, 80% medium, 50% low.
- Effort: the work required, in person-months.
RICE score = (Reach × Impact × Confidence) ÷ Effort. It is the most thorough of the common frameworks and forces you to write down your assumptions. It needs usage data to estimate reach, so it fits teams with a few hundred active customers or more.
4. ICE
ICE was created by Sean Ellis for growth experiments. Rate each idea from 1 to 10 on Impact, Confidence and Ease, then multiply the three. An idea scored 7, 6 and 5 gets 210. ICE is fast and good for a first pass over a long list, but the scores are subjective, so two people can rate the same idea very differently.
5. MoSCoW
Sort requests into Must have, Should have, Could have and Won't have (this time). MoSCoW is useful when you are scoping a specific release or deadline, because it makes the trade-offs explicit. It does not rank items within each bucket, so it pairs well with votes or revenue.
6. The Kano model
Developed by Noriaki Kano, the model sorts features by how they affect satisfaction. Basic features are expected, and missing them causes frustration. Performance features add satisfaction the better they get. Delighters are unexpected and create outsized goodwill. Kano is less a ranking method than a lens: it reminds you that a request with few votes can still be a basic expectation that loses you deals.
Which prioritization framework should you use?
| Framework | Best for | Needs | Watch out for |
|---|---|---|---|
| Votes | Public boards, early products | A place customers can vote | Every vote counts the same |
| Revenue-weighted | B2B SaaS with paying accounts | Requests linked to customers and revenue | Ignoring prospects and free users entirely |
| RICE | Teams with usage data | Reach and effort estimates | False precision from guessed numbers |
| ICE | Quick first pass, experiments | Three 1 to 10 ratings | Subjective scores |
| MoSCoW | Scoping one release | A fixed deadline or scope | No ranking inside each bucket |
| Kano | Understanding expectations | Customer interviews or surveys | Not a ranking on its own |
For most small SaaS teams the practical answer is a blend: rank by votes and the revenue behind them, sanity-check the top items for effort, and use Kano thinking to catch basic expectations that do not get many votes.
A 30-minute weekly process for small teams
- Triage new requests (10 minutes). Merge duplicates into existing ideas, tag the product area, and decline anything that is clearly out of scope, with a short reply.
- Look at the top 10 by votes and by revenue (5 minutes). The items that appear on both lists are your strongest candidates.
- Size the candidates (10 minutes). A rough t-shirt size (small, medium, large) from whoever will build it is enough.
- Decide (5 minutes). Move one or two items to Planned. Note why, in a sentence, on the idea itself.
- Tell people. Everyone attached to a request you planned or declined gets an update. Our guide to closing the feedback loop has the email templates.
A worked example
Three requests from a small analytics product, with effort sized by the engineer who would build each one:
| Request | Votes | Revenue asking | Need | Effort | Decision |
|---|---|---|---|---|---|
| Dark mode | 42 | $1,200 MRR | Mostly nice to have | Medium | Later |
| Google Sheets as a data source | 31 | $4,100 MRR | Mostly important | Medium | Plan next |
| SSO with Okta | 18 | $6,900 MRR | Must have for 3 accounts | Large | Plan, break into steps |
Dark mode has the most votes, but the people asking pay the least and mostly marked it nice to have. Google Sheets has strong demand and real revenue at a reasonable size, so it goes next. SSO is the most valuable and the most work, and three accounts say they need it, so it gets planned too, with a smaller first step so those customers see progress.
How to say no to feature requests
Prioritizing means declining most requests, at least for now. A clear no keeps more trust than silence. Reply to the customers who asked, give the reason in one or two sentences, offer a workaround if there is one, and say what would change your mind. Then mark the request as declined so it stops resurfacing in every review.
Common prioritization mistakes
- Scoring before merging duplicates. You will undercount your biggest needs.
- Treating a framework score as the decision. Scores start the conversation. Strategy, timing and dependencies still matter.
- Only listening to the board. Many customers never post. Requests from calls and support tickets need to count as votes too.
- Re-prioritizing everything every week. Review new requests and the top of the list. Leave the rest alone.
- Planning in private. A public roadmap sets expectations and cuts down on "any update?" emails.
How to prioritize feature requests in Murmur
- Requests arrive from your portal, in-app widget, forwarded email and call notes, and Autopilot merges duplicates into one idea.
- Every vote keeps the customer, their company and their revenue, and voters can say whether it is nice to have, important or a must have.
- Sort any list by votes, trending or the revenue asking. The Prioritize view combines votes, revenue, impact and effort into one score, with weights you can adjust.
- Move an idea to Planned, and everyone who asked gets an email. When you approve an idea, Fix with Claude can open a pull request for it.
Murmur has a free plan, and Solo is free for the first 14 days. See pricing or try the live demo.
Frequently asked questions
How do you prioritize feature requests?
Collect every request in one place and merge duplicates, then rank them by demand (how many customers asked and how much they need it), value (the revenue or strategic importance behind those customers) and effort. Review the top of the list on a fixed schedule, decide what to build next, and tell the customers who asked.
What is the best framework for prioritizing feature requests?
For small teams, a simple ranking by votes and the revenue behind them, checked against effort, is usually enough. RICE works well once you have usage data to estimate reach. ICE is faster but more subjective. MoSCoW suits a fixed release, and the Kano model helps you understand which features customers expect versus which delight them.
What is the RICE framework?
RICE scores an idea as Reach times Impact times Confidence, divided by Effort. Reach is how many people it affects in a period, Impact is scored 3, 2, 1, 0.5 or 0.25, Confidence is a percentage, and Effort is measured in person-months. It was developed by Sean McBride at Intercom.
What is ICE scoring?
ICE scoring rates an idea from 1 to 10 on Impact, Confidence and Ease, then multiplies the three numbers. It was created by Sean Ellis for prioritizing growth experiments and is popular because it is quick.
Should you build the most-voted feature requests first?
Not automatically. Votes measure how many people asked, not how much it matters to your business. Weigh votes by how badly customers need the feature and by the revenue of the accounts asking, and check the effort before committing.
How often should you prioritize feature requests?
A short weekly review keeps the list current for most small teams. Do a bigger planning pass monthly or quarterly when you set the roadmap.
How do you weigh feature requests by revenue?
Link each request to the customers who asked and their monthly revenue, then sort by the total revenue asking. A feedback tool that tracks voters and their companies, such as Murmur, does this automatically.
How do you say no to a feature request?
Tell the customer directly, give the reason in a sentence or two, suggest a workaround if there is one, and say what would make you reconsider. Mark the request as declined so it stops coming up in every review.
Collect it, rank it, ship it, tell everyone
Murmur is customer feedback software for small SaaS teams: a feedback portal and widget, AI that captures requests from email, revenue on every vote, and emails to every voter when you ship. Free for one board with unlimited voters.