Blog · October 16, 2026 · 6 min read
How to prioritize feature requests when you’re a small team
Once people start using your product, the requests never stop. Here’s a simple way to decide what to build next, without a product manager, a spreadsheet of scores, or building whatever the loudest customer asked for last.
Votes are a signal, not a decision
A list of requests sorted by votes is the obvious place to start, and it’s far better than a pile of emails. But the top-voted idea isn’t automatically the next thing to build. Votes tell you how many people want something. They don’t tell you what it costs, whether it fits where the product is going, or whether the people asking are the customers you want more of.
Treat votes as one input among a few. The goal is a short list you can defend, not a perfect ranking.
Ask four questions of every top request
Take the ten or so most-requested ideas and ask the same four questions of each:
- How many people want it? Votes and duplicate requests from email or support count here, but count people, not messages: one customer who asks five times is still one person.
- Who wants it? A request from your best-fit customers, or from people about to pay, weighs more than one from people who will never upgrade.
- How big is it? A rough size is enough: a day, a week, or a month. Small teams consistently underestimate “just add a setting”.
- Does it fit? Does it make the product better at the one job it does, or pull it toward something else?
You don’t need a formula. Frameworks like RICE (reach, impact, confidence, effort) are useful for larger teams comparing dozens of projects; for a team of one to five, these four questions usually make the answer obvious.
Look for quick wins and hidden themes
Two patterns are worth looking for before you pick anything big.
Quick wins
Popular and small is the best combination there is. If something has a dozen votes and takes an afternoon, do it this week. Shipping a few of these early builds trust that the board is actually read.
Themes
Several smaller requests often describe one underlying problem. “Export to CSV”, “Google Sheets sync” and “API access” might all mean “I need my data in my reporting tool”. Grouping them can show that a theme is far more popular than any single idea suggests.
Say no, kindly and in public
Some requests won’t ever fit, however many votes they get. Leaving them open forever creates false hope and the same question in your inbox every month.
It’s better to reply once, explain why, and close or archive the idea. Most people respect a clear “not for now, and here’s why” far more than silence. If your board allows it, keep the explanation visible so the next person sees it before asking again.
Close the loop
Prioritizing isn’t finished when you pick something. Mark it Planned so voters know it’s coming, move it to In progress when you start, and to Completed when it ships. A public roadmap does this for you, and it’s the simplest way to show people that asking was worth it, which means they keep telling you what they need.
A short routine works well for small teams: once a week, read new requests and merge duplicates; once a month, run the four questions over the top of the list and update the roadmap.
In short
- Collect requests in one place so votes and duplicates add up.
- Shortlist the top ten, then ask: how many, who, how big, does it fit?
- Ship popular small things quickly, and group related requests into themes.
- Say no clearly to things that won’t fit.
- Keep the roadmap current so people see what happened to their idea.
UserNote gives you the first and last parts for free: a feature voting board your users can vote on without signing up, and a public roadmap that updates as you change an idea’s status.