Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

Feature voting is harmful to your product

Freshness Warning
This article is over 1 year old. It's possible that the information you read below isn't current.

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 and how do we know which requests are most important?

And 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 use as well. 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’s a lot of 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.

Recently Written

A framework for onboarding new employees (May 15)
There’s no single good way to onboard an employee that works for every role. Here's a framework for creating a process that you can adapt to each situation.
TV hosts as a guide for software managers (May 10)
Software managers can learn a lot from journalists or late night TV hosts and how they interview people.
The Improvement Flywheel (Apr 29)
An incredible flywheel for the improvement of a development team. Fix a few things, and everything starts getting better.
Managers and technical ability (Dec 26)
In technical fields, the closer you are to the actual work being done, the closer your skills need to resemble those of the people doing the work.
Dysfunctions of output-oriented software teams (Sep 17)
Whatever you call it, the symptom is that you're measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.
Evaluative and generative product development (Aug 30)
Customers never even talk to the companies that don't fit their needs at all. If the only product ideas you're considering are those that meet the needs of your current customers, then you're only going to find new customers that look exactly like your current customers.
Product Manager Career Ladder (Aug 19)
What are the steps along the product management career path?
Building the Customer-Informed Product (Aug 15)
Strong products aren't composed of a list of features dictated by customers. They are guided by strong visions, and the execution of that vision is the primary focus of product development.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.