Feature voting lets customers upvote requests on a shared board so you can see which problems matter to the most people. It is a good way to collect demand and a poor way to make decisions on its own: raw counts favour vocal users, split across duplicate posts and leave out everyone who never visits the board. Used well, votes are one weighted input alongside revenue, strategy and effort. This guide covers how voting works, the biases to correct for, how to weight votes, and the situations where you should not use it at all.
How does feature voting work?
Feature voting works by giving customers a shared board where each request is a post and each person can add one vote to the posts they care about. Before submitting something new, a customer searches or browses the existing requests, and if theirs is already there they vote on it instead, often adding a comment about their situation. The product team reads the board, merges duplicates and moves posts through statuses such as Under review, Planned, In progress and Shipped, and everyone who voted is notified when the status changes. Over time the board becomes a ranked, public list of customer demand. Customers can see what others want, support can point to a post instead of retyping an answer, and product can see how much support a request has before deciding what to do with it.
What a vote actually tells you
A vote says 'this matters to me enough to click'. It does not say how much it matters, whether the person would pay for it, or whether the proposed solution is the right one. Treat a vote as a pointer to a problem worth investigating, and read the comments for the context the count leaves out.
Anonymous or identified votes
Anonymous voting lowers friction, so you get more votes. Identified voting, where each vote is tied to a logged-in user and their account, gives you fewer votes that you can do far more with: you can see which customers asked, weight them, and notify them later. For B2B products identified voting is usually worth the friction, and single sign-on from your app removes most of it.
What biases does feature voting introduce?
Every vote count is shaped by who shows up and how the board is designed. None of these biases is a reason to abandon voting, but each one should change how you read the numbers.
The loudest customers
The people who vote are the people who visit your board, and they are not a random sample of your customers. Power users, community regulars and customers with time to spare are overrepresented. A few very engaged accounts can make a niche request look like a groundswell, while your quietest segment, which may also be your largest, barely appears.
Incentives can widen that gap if they reward activity rather than useful contributions. Does gamification increase feedback volume? covers how to point rewards at the right behaviour.
Vote inflation and campaigns
Votes can be organised. A customer asks colleagues to vote, an account manager asks a prospect's team to pile on, or someone shares a post in a community and it collects votes from people who have never used the product. None of this is dishonest, but it measures mobilisation rather than need. Count votes per account as well as per person, and look at who voted before reacting to a spike.
Duplicates split demand
The same need gets posted five ways: 'CSV export', 'Export to Excel', 'Download my data'. Each post collects a fraction of the votes, and none of them looks important. Merging duplicates while keeping every voter attached is one of the highest-value maintenance jobs on any board.
Early posts collect more votes
Posts sorted by vote count stay at the top partly because they are at the top: new visitors see them first and add to them. A request posted last week competes with one posted two years ago. Offering newest and trending sorts, and comparing requests by votes over a recent window, reduces the effect.
Requests arrive shaped as solutions
Customers vote on the solution someone proposed, not the problem underneath it. Ten votes for 'add a dark mode toggle to the editor' may be ten people with a readability problem that has several possible fixes. Ask what they are trying to do before you commit to the literal request.
The people who never vote
Churned customers, prospects who chose a competitor and users who do not know the board exists all have views the board cannot show. Read voting data alongside lost-deal reasons, churn conversations and support themes.
How should you weight feature votes?
Weight feature votes by the attributes that reflect the value of the customer behind them, most often revenue, plan or segment, and renewal timing. The simplest version is revenue weighting: each vote counts in proportion to the voter's account MRR or ARR, so a request backed by a few large accounts can outrank one backed by many trial users. Segment weighting gives more weight to the customers you are building for, your ideal customer profile, and less to segments you are moving away from. Renewal weighting surfaces requests from accounts that renew soon. Whatever you choose, count each account once per request so a large team cannot multiply its weight, keep the raw vote count visible next to the weighted score, and write the rules down. Weighting only works when the team trusts it, and nobody trusts a formula they cannot see.
Renewal timing is also where votes become a retention tool. The section on feature voting versus NPS below explains why identified requests from accounts renewing soon make a more useful churn-risk list than a survey score.
A worked example
Take two hypothetical requests. Request A has 60 votes, almost all from free and trial users, with no paying account behind it. Request B has 11 votes from 7 accounts on paid plans, three of which renew next quarter. On raw count, A wins easily. Weighted by revenue, B leads, and the renewal timing tells you it is also urgent. Neither number makes the decision, but the weighted view changes the question from 'which is more popular?' to 'which customers need this, and what happens if we wait?'
Watch for the bias weighting introduces
Revenue weighting has a failure mode of its own: it can turn the roadmap into a list of whatever your largest customer asked for. Cap how much any single account can contribute, and keep some capacity for requests that matter to many smaller customers or to the segment you want to grow into.
How do you turn votes into priorities?
Votes measure demand. Priority also depends on how much each request is worth, how sure you are about that, and how much it costs to build. A light scoring model keeps those inputs visible without turning planning into paperwork.
Intercom's RICE model, written up by Sean McBride, scores each idea as Reach multiplied by Impact and Confidence, divided by Effort. Weighted votes are a reasonable input to Reach, and the comments on a post are often the best evidence you have for Impact and Confidence. Effort has to come from the team.
Keep the model small and re-score on a schedule rather than every week. How to prioritize feature requests covers the practical side: centralising intake first, weighting votes, and limiting the scoring model to inputs people will actually fill in.
When is feature voting the wrong tool?
Voting answers one question well: of the requests customers have already thought of, which ones do the most of them care about? It is the wrong tool when that is not the question you need answered.
Before you have enough customers
With a handful of customers, a board produces too few votes to rank anything. Talk to each customer directly; one conversation tells you more than a vote could.
Bugs and reliability
Customers should not have to vote for the product to work. Route bugs to a triage queue with a severity, and keep them off the feature board, or use a separate bug board where votes indicate reach rather than priority.
Strategic bets and new markets
Existing customers vote for improvements to what they already use. They cannot vote for the product that would win a segment you do not serve yet. Direction-setting work needs research, not a tally.
A few very large accounts
If a small number of enterprise accounts make up most of your revenue, their needs are better handled through account plans and a private board than through a public vote where they are outnumbered.
Problems customers cannot see
Usability problems, onboarding drop-off and slow pages often show up in analytics and research long before anyone posts about them. Nobody votes for the confusing step they quietly gave up on.
Is feature voting a better churn signal than NPS?
NPS gives you a number every quarter. A feedback board gives you a named person, a specific blocker and a date. Both are signals; only one tells you what to do on Monday.
NPS is lagging and lossy
By the time an account drops from 9 to 6, the decision to leave is often already forming. And a score with no attached request tells you sentiment moved without telling you which capability caused it.
Sample bias makes it worse: the accounts most at risk are the least likely to answer.
Votes are behavioural and continuous
A user who takes the time to write and upvote a request is telling you exactly where the product blocks their workflow. Repeated votes from one account on the same theme are worth treating as a risk signal: the account is telling you, more than once, where the product falls short of what it needs.
Because it is continuous, you see the trend forming rather than a quarterly snapshot of it.
Use both, but weight them differently
Keep NPS for board reporting and benchmark comparisons. Use the board for prioritisation and for account-level risk flags.
The combination that works: filter open requests by accounts renewing in 90 days, then sort by weighted votes. That list is your retention backlog.
What breaks the signal
Anonymous voting. If you cannot tie a vote to an account, you lose the account context that makes votes a risk signal, and you are back to a popularity contest.
What the renewal filter looks like in practice
An illustrative quarter: forty accounts renew in the next ninety days. Filter the board to their votes and three requests stand out, each voted on by several of those accounts and one of them commented on twice by the same customer. None of the three is in the top ten by raw vote count, because trial users outnumber renewing customers on the board as a whole.
That gap is the point. Sorted by popularity, the board tells you what the most people want; filtered by renewal date and weighted by account value, it tells you what you might lose. NPS cannot produce either list, because a score carries no request attached to it.
Running feature voting in Looph
In Looph every vote comes from a signed-in account, one per person per post, and each board sets who may vote. Votes are not weighted yet; weighting by plan or revenue and voting without an account are coming soon. Sort by Top voted or Trending, keep account context in internal notes, and export the ranked list to CSV. Voting and prioritisation covers the options.
Similar posts surface while someone types a new request, and merging moves votes, comments and followers onto one post while counting each person once; see handle duplicates and merge posts. Followers are notified on every status change. Automatic rate limits and vote-spike alerts are coming soon. The feature voting and feedback boards pages summarise the product side, and the feature request board template is a recommended setup.
Frequently asked questions
Should feature voting be anonymous?
Only if volume matters more than context, which is typical of consumer products or very new boards. For B2B products identified voting is usually better, because it shows which accounts asked, lets you weight their votes and lets you notify them when the request ships.
How many votes does a feature need before you build it?
There is no universal threshold, and a fixed number invites campaigning. Use votes to decide what to investigate, then decide what to build from weighted demand, strategic fit and effort together.
Should customers see vote counts?
Visible counts help customers find popular requests and reduce duplicates, but they also strengthen the advantage of older posts. Many teams show counts and offer a newest or trending sort so recent requests get a fair look.
Can feature voting replace customer interviews?
No. Voting tells you which known requests are popular among the people who visit your board. Interviews tell you why, and surface problems nobody has written down yet.
How do you stop one customer from dominating the board?
Count votes per account as well as per person, cap the weight any single account can contribute, and check who is behind a spike before acting on it.