Requests reach a small team from everywhere. An email, a chat message, a call with a customer, a comment on a board. Bugs land in the same places, and you have your own ideas for the product too. It's easy for the loudest message of the week to decide what gets built.
This is a simple way to handle it, in four steps. It comes from how small teams describe doing it themselves.
1. Keep one list, with names
Every request goes on one list, wherever it came in. Write down who asked and where. If the same problem comes up in different words, it's one entry, and each person counts once.
The names matter more than the count. A name is someone you can ask a question, and someone you can tell when it ships.
If your list is empty today, start with what's already in your inbox and messages. How to get your first feature votes has more on that.
WorkMirror, who make a mileage log for company vehicles, do this for requests they hear in conversation. Staff add the vote for the customer with their email address, so the customer hears about it when it's released. Read their story.
2. Ask what they're trying to do
A request is usually someone's guess at a fix. Before you count it, reply and ask what they're trying to do, or what they would use it for.
The answer often changes what you're looking at. Three requests that look different turn out to be one need. A missing feature turns out to be a setting they didn't find. Or the request is exactly right, and now you know why.
WorkMirror see the same thing in comments. Several requests that looked separate all pointed back to one need, tracking units that aren't assigned to a car yet.
3. Decide once a week
Pick a fixed day to go through the list. Bugs that stop people from working don't wait for that day. Fix those first, and keep them out of the ranking.
For everything else, look at three things.
- How many separate people asked.
- Who they are. A paying customer, a deal waiting on it, someone thinking of leaving.
- Whether it fits what the product is for.
Pick one or two. Leave the rest on the list. A need that's real tends to come back, and the next person who asks is one more name on the same entry.
Sometimes the count decides it. WorkMirror had avoided building a phone app, until that request had 45 votes and the next one had 11. But they have many small customers and a few large ones, so the count alone isn't enough. Their sales reps also add requests from prospects who need a feature before they buy. The list also helps them say no. A complicated integration that nobody else asks for can stay unbuilt.
Your own ideas don't need votes. Requests tell you where people get stuck. Where the product goes is still yours to decide. It helps to write down, in a few lines, what the product is for and what it won't do. Then you have something to point to when you say no.
4. Tell them what you decided
When something ships, tell the people who asked. A short note that says it's the thing they asked for is enough. How to tell customers their request shipped walks through it.
When the answer is no, say so, and give the reason. "Not now, we're working on X first" is a real answer. A request that sits for a year without one tells people nobody reads the list.
When this doesn't fit
Some teams do it differently.
- Some keep no list at all. They read what comes in and trust that the important things come back on their own. That works when you talk to every customer anyway.
- Some sort by votes and build from the top. That fits a large audience where you can't know each person.
- Bigger teams often name one person to own incoming requests, or set aside a fixed share of each week for them. In a team of two or three, that person is usually the founder already.
If you run a community
A board for a game, a mod or a creator community changes a few things. The crowd is bigger, you can't talk to everyone, and votes matter more.
- Ask people to vote on an idea that's already there, instead of posting it again.
- Give supporters more say if you want to, for example by Patreon tier or Discord role.
- Say openly what you won't build. Some game studios keep a public list of ideas they have already decided against.
- Answer where people asked, which is often a Discord channel.
The fixed day and telling people what you decided work the same way.
Doing this in Featurevote
- Vote on behalf of records a customer's vote with their name and email, so a request from a call or an email counts, with a name on it.
- When someone posts on your board, it checks for similar requests first and suggests voting on one of those. Duplicates already on the board can be merged, and each person's vote counts once.
- Turn on Known issues and bugs get a list of their own, where people say Me too instead of reporting the same bug again.
- Home lists the people waiting for a reply, and Reply sends them a private email.
- Mark as Completed emails everyone who voted and left an email address.
- For a community, Patreon and Discord can give supporters' votes more weight.
All of this is on every Featurevote plan, including the free one. Start a free board.