What is a feature voting board?

A public or in-product list where users submit ideas and vote on the ones they want, so demand for a change is visible instead of anecdotal. It is a discovery input, not a prioritization system.

Should the most-voted feature always get built?

No, and promising that is how boards go wrong. Votes tell you which problems enough people care about to click. Business value, effort, strategy and who is voting all still apply.

How do I stop a voting board filling with duplicates?

Ask for the problem rather than the feature on the submission form. Differently worded requests usually collapse into one problem once you can read the intent, and merging becomes routine rather than guesswork.

How often should a feature voting board be maintained?

Often enough that every item has a current status and voters hear back when one changes. A board people believe is being read keeps getting good submissions; a silent one stops within a couple of months.

How to run a feature voting board

A vote is a signal, not an instruction

The fastest way to ruin a feature voting board is to promise that the top item gets built. Within a quarter you are working for whoever organized the loudest campaign, and every roadmap conversation becomes a negotiation about the leaderboard.

The useful framing is narrower. A board tells you which problems enough people care about to spend thirty seconds clicking. That is genuinely valuable and it is not a prioritization system. Say so publicly, in the board's own description, before the first vote lands.

Votes are weighted by who is voting

Ten votes from trial accounts that churned and ten votes from customers who renewed twice are not the same ten votes. A raw count flattens that difference and quietly biases your roadmap toward people who are shopping rather than staying.

If your board can see who voted, segment before you read the number. The question worth answering is not "how many", it is "how many of the people we want more of".

Ask for the problem, not the feature

Most submissions arrive as solutions: "add a Slack integration". The underlying problem might be that nobody notices when a metric moves, and a digest email would solve it faster. Put one required field on the submission form asking what the person is trying to do, and you convert a feature request queue into a problem backlog.

This also makes duplicates visible. Three differently worded requests often collapse into one problem once you can read the intent behind them.

Connect the board to behavior

A board on its own tells you what people say. Your product analytics tell you what they did. The interesting cases are where the two disagree: a heavily requested feature that duplicates something already shipped and unused points at a discoverability problem, not a build.

Before committing to anything on the board, check whether the relevant surface is already being reached, and watch a few sessions of people who tried.

Close the loop, or the board dies

Boards decay when voting feels like shouting into a void. The maintenance cost is small and non-negotiable: give every item a status, write one sentence when a status changes, and notify the people who voted. Say no out loud when the answer is no, with the reason.

A board with fifty items and honest statuses is more useful than one with five hundred and none. Archiving aggressively is part of running it well.