How to prioritize feature requests: count customers, not votes
A feature board gives you a number next to every idea: how many people voted for it. It is tempting to treat that number as a priority list and build whatever has the most votes first. That approach works until it doesn't, and the way it fails is specific enough to plan around.
Why a vote count is not a priority score
A vote count treats every voter as equivalent. In practice, voters are not equivalent in how much their request matters to your business. A request with forty votes from free users who have never paid you anything is not obviously more important than a request with six votes from six different paying customers on your highest-value plan. Raw counts collapse that distinction, because a vote from each group looks identical on the board.
Vote counts are also shaped by who happens to see the board, not just by who wants the feature. A request posted early gets more time to accumulate votes than one posted last week, regardless of how important either one is. A request that is easy to understand from its title tends to collect more votes than one that requires reading the description, even if the harder to read request represents a larger and more urgent problem. None of this means votes are useless. It means they are one signal, not a ranking.
What "count customers, not votes" means in practice
The fix is not to ignore votes. It is to look at who is behind them before treating the count as a decision. Concretely, that means matching voters to your customer records, where possible, and asking a different question than "how many votes": how many distinct paying customers, and which ones, are asking for this.
A request with votes from three customers on your highest plan can be a stronger signal than a request with twenty votes that are almost entirely from your free tier, depending on what you are trying to optimize for. If your goal is reducing churn among paying customers, the first request deserves more attention even though it has fewer votes. If your goal is improving conversion from free to paid, free-tier votes matter more, but you still want to know whether the free users voting are active, engaged users who look likely to convert, rather than inactive signups who registered once and never returned.
A simple process for weighting requests
You do not need a scoring model to get most of the benefit here. A workable process has a few steps.
- Tag voters by account type. If your feedback tool supports matching a voter's email to your customer or billing records, use that to tag each vote as free, paying, or a specific plan tier. If it does not support this automatically, a periodic manual check against your customer list works for a smaller voter base.
- Separate the view by segment before you rank anything. Look at your top requests among paying customers as its own list, separate from your top requests overall. The two lists will often disagree, and the disagreement is the useful part: it shows you where popular demand and paying-customer demand point in different directions.
- Weigh, do not just filter. Excluding free-user votes entirely throws away a real signal about what might drive future upgrades. Weighting a paying customer's vote more heavily than a free user's, rather than discarding the free vote, keeps both signals visible without letting the larger free-tier count drown out a smaller but more valuable paying segment.
- Watch for a small number of accounts asking repeatedly. If the same handful of paying accounts show up across many of your top requests, that is worth knowing on its own. It might mean those accounts are especially vocal, or it might mean your product has a real gap for a specific kind of customer that is worth addressing directly, independent of any single request's vote count.
- Revisit the weighting periodically, not every time you prioritize. Customer segments and plan tiers do not change week to week. Rechecking the weighting quarterly, or whenever your pricing or plan structure changes, is usually enough to keep it accurate without turning prioritization into a data project every time.
Where raw votes are still useful
None of this is an argument against collecting votes. Vote counts are still the fastest way to see which ideas have any demand at all, and they are especially useful for ruling things out: a request with almost no votes after a long time on the board is a reasonably strong signal that it is not worth prioritizing, regardless of who asked. Votes are a good filter for the bottom of your list. They are a weaker guide for the top of it, which is exactly where customer-weighted information matters most.
A short example of how the two rankings can diverge
Imagine a board with two open requests. The first asks for a minor visual change and has accumulated votes quickly because it is easy to understand at a glance and was posted early, drawing votes mostly from free-tier users browsing the board out of curiosity. The second asks for a specific integration and has fewer votes, posted more recently, but every voter is a paying customer on your top plan, and two of them have mentioned in support conversations that the missing integration is the reason they have not expanded their usage. Ranked by vote count alone, the first request wins. Ranked by customer weight, the second one does, and for a team trying to protect and grow revenue from existing paying customers, the second ranking is the one that matches what is actually at stake.
The underlying principle
A feature board measures interest, not value. Converting interest into a priority decision requires knowing who is interested, specifically whether they are already paying you and how much, before you decide what to build next. Counting customers instead of votes does not replace the board. It adds the one piece of context a vote count cannot carry on its own.