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 blog post is over 1 year old. It's possible that the information you read below isn't current and the links no longer work.

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

Domain expertise in Product Management (Nov 16)
When you're hiring software product managers, hire for product management skills. Looking for domain experts will reduce the pool of people you can hire and might just be worse for your product.
Strategy Means Saying No (Oct 27)
An oft-overlooked aspect of strategy is to define what you are not doing. There are lots of adjacent problems you can attack. Strategy means defining which ones you will ignore.
Understanding vision, strategy, and execution (Oct 24)
Vision is what you're trying to do. Strategy is broad strokes on how you'll get there. Execution is the tasks you complete to complete the strategy.
How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.
Developer Experience Principle 5: Easy to Trust (Oct 9)
A developer building part of their business on your product needs to believe that you're going to do the right thing for them and their customers.
Developer Experience Principle 4: Easy to Get Help (Oct 8)
The faster you can unblock a stuck developer, the better their experience will be.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.