Does feature request voting do more harm than good?

The idea of a portal for collecting feature requests isn't nothing new.

It's born out of the question how do we collect and manage feature requests. More importantly, what is the best way to find out which requests are important?

So you as the product manager whip out your trusty spreadsheet and start contacting your customers. You hear their thoughts on what features should be there in your next big release.

You can use a combination of forms and spreadsheets to collect this information. Better yet you might use a feature voting tool like Suggested

But the question is whether feature voting is the best way to guide your product roadmap. Let's dive into some of the problems.

1. Voting treats all customers as equal.

If you customer base varies, which is usually the case if you're a SasS product with tiered pricing. It makes sense the weighting of each customer's request should be different.

If an enterprise customer is paying you more in MRR then a smaller company it might make sense to prioritise the larger customer.

A more extreme example: it doesn't make sense to prioritise the feature requests of a trial user, or a free user over a paying user.

This is a big downside of using votes, as each vote has equal weighting.

So what do you do?

Easy. You segment the votes of your customers based on their MRR, or another dimension. This is an effective strategy to look at which features should be more important.

2. Customers may have a genuine problem, but they don't know the best solution

Allowing your customers to submit feature requests is like opening a can of worms. They may have a very specific idea of what they want, but it probably isn't the best solution. Ideas aren't the problem, it's more about whether it's the right idea to solve the problem.

Two different customers may have the same problem. But the feature request ideas they've submitted could be completely different!

So how do you as a product manager manage this?

The best solution is to start a conversation with the customer, and dig into the problem. If they're submitting a feature request, then there is some genuine problem they've encountered. Your job as a product manager is to dig into the truth, and surface the best solution.

Your customers will be delighted when you've proposed a better solution, after listening to their input.

3. The implicit promise of implementing a customer's feature request

If you deploy a feature voting portal, customers who submit ideas might think it will be implemented in the future.

As more of your customers start using the feature voting portal to add their ideas, and vote on others, the requests start to pile up.

What happens when the top most asked for feature request isn't actually going to be implemented, because it falls outside the scope of your product?

The problem is that customers have an expectation that their ideas are good, and will be implemented (especially if they're paying customers!). But from your team's point of view it doesn't make sense. So their feature request, along with the many votes on it, is stuck in limbo.

So, what's the best way to manage your customer's expectation, without coming off as their views don't matter.

As with most things, it's all about clear communication with your customers. Make it clear that your feature voting portal is to ask for their ideas. Not a binding agreement to actually build what they've asked for.

With Suggested's moderation tools you can pre screen any new ideas. With moderation turned on, their feature requests are not published straight away. Instead they are pushed to a virtual inbox, where you can review it, and have a conversation with the customer to find out more. If it doesn't make sense to implement, you can inform the customer directly.

4. Your customers don't appreciate the complexity in building a feature

A customer asks for a brand new feature. It solves a problem they have, and would make the product they're paying for far more useful to them. They're one of your bigger customers.

As product manager, the request looks reasonable enough. So you talk to your engineering team to see what it would take to implement. After listening to your engineers, it turns out that building the feature would require serious engineering effort. It's a no go for the moment.

Although this feature request has others voting for it, the number of votes vs the engineering effort is not worth it.

The problem here is that your customers aren't aware of the effort and the trade-offs you have to make to build their feature, and make it a reality.

How do you as product manager navigate this tricky problem?

Again, this comes down to two things: managing expectations and clear communications with your customers.

It turns out people are quite understanding if you explain to them clearly the cost of building a certain feature, and the trade offs that you have to make.

Using a feature voting portal like Suggested, you can talk to your customers directly in the comments section and explain why a feature is unrealistic.

Conclusion

Do we ignore what our users have to say?

No.

Do we implement every feature request they ask for?

No.

Product management is more nuanced than that. Of course you should listen to your users, but you shouldn't take every idea they have as gold.

Feature voting tools have their place in a product manager's tool belt. It gives you a better, data driven approach to getting the pulse of what your customers need. But it should be used to complement your existing processes to improve your product.

More broadly, feature requests and votes should be taken as one signal among many others to make decisions about your product roadmap.