Product Management
Feature Voting Is Harmful To Your Product
Freshness Warning
This blog post is over 5 years old. It's possible that the information you read below isn't current and the links no longer work.
7 Feb 2019
Feature voting is the worst idea ever invented for product management.
"If I’d listened to what my customers asked for, I’d have built a faster horse." - Apocryphally attributed to Henry Ford.
When a company starts getting feature requests for their product, it often creates two questions. How do we keep track of all this? How do we know which requests are most important?
Thus the idea portal is born. Throw up a form and let customers put in what they want. Let them look through all the existing ideas and tell you which features they’d also use. All at once, we’ve solved how to collect feature requests and how to know which we should work on first. Just sort by the top votes, and you’ll know what your customers really care about. There are even SaaS products you can use that manage the whole process for you.
What you’ve actually done is seriously damaged your product roadmap.
There are many problems with using feature voting to drive your product.
The votes don’t capture "when."
A vote is a binary state. It represents what a customer said they wanted at the point in time they voted on it. By the time you implement it, their business may have changed. They may have found a substitute that solves the problem they were solving with the feature.
Are your priorities the same they were a year ago? A customer’s needs and priorities are in constant flux. They change but the vote doesn’t. Once placed, it’s there.
A vote doesn’t capture how priorities change over time.
Voting puts all customers on an equal footing
Your largest customer’s vote counts exactly the same as a person running a free trial. A customer that is a bad fit for your product will have lots of feature requests but might churn out before you implement any of them. A customer that’s a perfect fit will have few. The needs of new customers differ vastly from customers that have lots of experience with your product.
Customers don’t know what they want
Your customers don’t know what they want and don’t know what’s actually possible. When users ask for "message threading" they’re actually asking for better ways to organize conversations. They’re trying to solve a problem, but giving what they imagine is the solution to it. Their imagination doesn’t know your product vision, your constraints, and your plans.
Message threading might not be the right way to solve the problem they’re having. But if you tell them to vote on it, you’ll end up with it anyway.
It’s your job to design a product for your customers. You can’t abdicate that to a crowd of customers and end up with a coherent product.
Customers don’t understand your tradeoffs
How many times have you heard from your customers, "why did you build Feature X, when obviously Feature Y is so much more important?" This happens because customers don’t understand what’s hard and what’s easy in your product development. They don’t understand what tradeoffs you need to make, and why creating one thing means you can’t do something else.
Imagine two features. One will require a re-architecting of the Flibberty subsystem, will take months, and will impact all development, slowing down your delivery for weeks. The other you can do by adding a new field to a rarely-run database query. When the Flibberty feature gets 1000x more votes than the database feature, but you release the database change feature first, customers are disappointed. They’re disillusioned. They see this as you ignoring their voice, or as you shipping trivial things instead of important ones.
Real prioritization is a series of tradeoffs involving scarce resources and constraints. You might have hundreds of outstanding feature ideas but are only able to deliver 20 features this quarter. You have to prioritize: choose which ones to work on. Your customers don’t need to make tradeoffs at all. They don’t have to limit their choices. They have no constraints. There are no transaction costs involved in clicking a vote button. They can "prioritize" as many things as they want.
Voting gives you bad data
Feature requests in the voting site aren’t all equal. A simple, well-written request tends to get more votes than a complex, poorly-spelled, or confusing one. Even if that later is the better idea.
As the requests pile up, it becomes harder and harder for a customer to find their desired feature in the voting portal. So they create their own, a duplicate of the one they couldn’t find. You end up with lots of similar ideas with no easy way to recognize them or combine the votes across them.
If the requests are sorted by votes, the top vote-getters get seen more often, and thus voted on more often. They’re self-reinforcing: the popular ideas stay popular because they’re popular, not because they’re good.
Feature voting benefits people who are good at lobbying for their pet feature. In large companies, people spam their colleagues with "go vote for this feature please." Do the votes actually mean anything at that point? They don’t reflect an actual customer desire, it’s just a bunch of people helping their friend out.
At best, feature votes are a popularity contest that doesn’t correlate to actual customer need. At worst, the votes are gamed (intentionally or not) and don’t even mean what they purport to mean.
Feature voting is a poor user experience
When you ask someone to give you an idea and ask for their input in prioritizing it, you’re implying that you’re going to listen and take action on that idea. What happens when the top-ranked feature doesn’t get implemented? Maybe it’s irrelevant to your product. Maybe it’s technically impossible to implement. You created a tool with a promise that the customer’s voice would be heard, and you then say no to what they’re asking for in a very public way. You’ve broken the customer’s trust.
Soliciting customer requests without making a decision on them brings harm to the customer. A vote doesn’t actually tell the customer anything. There’s no signal to them whether their vote will result in the feature, or when it will happen. So the customer is stuck in limbo. When a customer asks for something, you owe them a response quickly. Tell them you’re going to build it, or that the product won’t ever do that, or even that it’s something you’re planning but a long way off. That’s information the customer can use to make a decision. It tells them if they’ll need to solve their requirements another way.
Telling them to go off and vote for a feature is deeply unsatisfying. It doesn’t help them plan for the future. All it does is hands off responsibility for making a decision to a bunch of unrelated strangers, leaving the customer’s fate in the hands of some nebulous collection of people.
A vote gives the illusion of giving the customer a voice while taking away all useful information about their request.
So we don’t listen to our users?
Listening to users is huge. It’s important. Doing what they ask you to is absolutely not. What you want is to hear the problem they’re having, not their idea of a solution to it. And a feature voting system actually discourages people from sharing their problems. Instead, they find someone’s idea of a solution and just upvote it.
Your job as a product manager is to understand a business problem and decompose it into smaller problems, some of which your product can solve. You do this by talking to customers, by reading what their problems are in support cases and emails to the company, by looking at how prospects compare you to alternative solutions. You do this by listening and recognizing patterns in the problems.
Focus on the problems they’re having, not the solutions they propose. Prioritize based on the patterns that emerge, not a stacked ranking of disconnected +1s.