How to prioritize feature requests without guessing

Every product team has more requests than time. The hard part isn’t making a list; it’s deciding what to do first and being able to explain why. Without a method, the loudest customer, the newest idea or the last call wins.

This guide gives you a method that works on a list of fifty requests or five hundred, explains the common frameworks, and covers how to tell customers what you decided.

First, make the list trustworthy

Prioritizing a messy list gives messy answers. Before you rank anything:

1. Merge duplicates. If the same request appears ten times in different words, it should be one item with ten voices. Otherwise popular requests look smaller than they are. Our guide on duplicate feature requests covers how.
2. Keep who asked. For each request you want to know how many customers asked, which ones, and how much they matter to the business.
3. Group related requests. “Export to CSV”, “export to Excel” and “scheduled exports” are three requests but one piece of work. Group them into one larger item, sometimes called an initiative or an epic, and prioritize the group.

The signals that matter

There’s no single number that tells you what to build. There are a handful of signals, and the method is to look at them together.

Demand: how many asked

Votes and the number of customers behind a request are the most visible signal. They’re useful, but they have blind spots: they favour customers who speak up, and they favour small, easy-to-describe ideas over deep problems.

Value: who asked

A request from an account that pays a lot, or from the segment you’re trying to win, can matter more than a request with more votes from trial users. If you know each customer’s revenue, add it up per request. It turns “many people want this” into “accounts worth this much want this”.

Recency: is it still alive

A request with a burst of activity last month tells you something different from one that got all its votes two years ago. Recent activity often means the need is growing.

Effort: what it costs

A rough size is enough: small, medium, large. Ask the people who’ll build it. Precision here is false comfort; the point is to spot the cheap wins and the expensive bets.

Fit: does it move the product where you want

Some requests pull the product toward a market you’re not trying to serve. High demand doesn’t make them right. Write down your current goals and check each top request against them.

Frameworks, and when they help

Frameworks give the conversation a structure. None of them decides for you.

• RICE scores reach, impact, confidence and effort. It’s good for comparing items of very different sizes, and it forces you to state your confidence instead of hiding it.
• Value vs. effort puts items on a two-by-two grid. Quick wins (high value, low effort) go first; big bets get a deliberate decision; low-value, high-effort items get dropped. It’s fast and works well in a team meeting.
• MoSCoW sorts items into must, should, could and won’t for a given release. It’s useful when you have a fixed date and need to cut scope.
• Kano separates basics customers expect, features they value more the better they are, and delighters they didn’t ask for. It’s a good reminder that votes rarely surface delighters.

Pick one that matches how your team decides, and use it the same way every time. Consistency matters more than the choice.

A simple weekly method

You don’t need a big quarterly ritual. A short, regular pass keeps the list honest:

1. Triage new requests. Merge duplicates, add categories, reply to anything unclear.
2. Look at the top of the list by demand and value. Which items gained the most votes or the most valuable customers since last time?
3. Size the top candidates. A quick effort guess from engineering.
4. Check fit. Does each candidate support this quarter’s goals?
5. Move a few items onto the roadmap. Not ten. Two or three you’ll actually start.

A worked example

Imagine three candidates at the top of your list this week:

• Scheduled exports. Many votes, mostly from small accounts; medium effort; fits your goal of keeping self-serve customers.
• Single sign-on. Few votes, but from your largest accounts, two of which mention it before renewal; large effort; fits your goal of moving upmarket.
• A small filter on the reports page. A handful of recent votes; small effort; a quick win.

Votes alone would pick scheduled exports. Revenue alone would pick single sign-on. Looking at all the signals, a reasonable plan is: do the small filter now because it’s cheap and recent, start single sign-on because the value and the fit are strong and the deadline is real, and put scheduled exports in Next with a note to customers that it’s coming. Everyone who asked gets a clear answer, and the reasoning is easy to explain.

Weigh the signals your way

Different businesses weigh these signals differently. A self-serve product with thousands of small customers may lean on votes. A B2B product with a few large accounts may lean on revenue. A young product may lean on recency, because the market is still forming.

Write your weights down, even roughly: “revenue counts more than votes, and recent activity breaks ties”. It makes the ranking repeatable and lets others understand it.

Explain the decision

Customers accept “not now” far better than silence. When you decide:

• Planned items go on a roadmap customers can see, so they stop asking “is it planned?”.
• Items you won’t do get a short, honest reply: what you’re focusing on instead, and why.
• Shipped items get announced to the people who asked, by name of the request, not as a line in a long release note.

A public roadmap does most of this work for you, as long as it’s kept up to date.

Common mistakes

• Counting votes only. It rewards the vocal and the easy.
• Ranking ideas instead of problems. Ten customers asking for ten different features may share one underlying problem.
• Re-deciding everything every week. Keep a short list in progress and let it finish.
• Hiding the reasoning. If nobody knows why an item is first, the next loud request will push it aside.

How AntNexo helps

In AntNexo, the AI suggests initiatives from related posts and suggests merges for duplicates, so the list you rank is clean. Each initiative adds up the votes of its posts and, if your app sends it, the monthly revenue of the customers who voted. A priority score combines votes, revenue and recent activity with weights you set in your workspace settings, and you move initiatives onto a public roadmap with Now, Next and Done.

See how the roadmap and priorities work, or what changes for product managers.