One of the biggest challenges for product managers is working out which feature requests should inform your product roadmap.
You need to work out whether the feature request is needed by your market – rather than by a few vocal customers – as well as consider whether building that feature ranks highly on the cost/benefit matrix. To do this you need to be organised about feature request tracking.
In a Mind the Product survey, 49% of product managers said their foremost challenge is being able to conduct proper market research to validate whether the market truly needs what they’re building.
When they looked at only the responses from enterprise software PMs, this figure jumped up to 62%.
Feature requests as valuable research information
I’m trying to make decisions about how to improve the product with no data about which features of the product are most valuable to users.
Most product managers have a great source of information that users are desperate to tell the company about: their feature requests. Customer feature requests show why the product isn’t working for them and how it can do better.
It’s easy to get frustrated about feature requests. They can be variable in quality and time-consuming to reply to, track and organise. Sometimes they show a serious lack of knowledge about your product and company vision.
However, if you track and organise feature requests in one central place, you have valuable research material that can be used to inform your product roadmap.
How to collect and prioritise your feature requests
To start working out which feature requests should inform your product roadmap, you first need to organise and qualify those requests. You can do this is a number of ways, but the easiest way is to keep track of how often certain requests are made. This way you have some idea of the popularity of a feature request.
A suggestion made 1.5 thousand times is of more interest than a suggestion made twice.
One of the easiest ways to see which feature requests are most popular is by voting.
You can use spreadsheets to keep track of ‘votes’ for a specific suggestion, but you will need to be prepared for a considerable amount of administrative work. Another option is to create a customer feedback board.
How to create a public customer feedback board
Instead of getting feature requests through multiple channels, invite your customers to add feature requests to a central feedback board, or upvote feature requests that have already been added by someone else.
The beauty of this approach is that you don’t have to spend time collecting and voting on feature requests yourself. Feature requests are organised and prioritised by your actual customers.
Another benefit of a public feedback board is that you can test out feature ideas. If your CEO has a feature request they want implemented simply enter the idea into your feedback board and see if it gets any comments and votes. If it doesn’t get any votes and slips down the board then you have a neutral way of telling your CEO they may wish to reconsider.
How to create a private feedback board
If you don’t like the idea of going public with feature requests, then create a private board. You can then give access to your customer support team who can proxy vote. Or you can give access to specific customers. Look to make your board private through a password or Single Sign-On.
A private feedback board means you can organise and track customer feature requests without making this information public.
Consider adding granular detail to your feedback board
Sometimes it’s enough to see which feature requests are the most popular with your customers. If you are repeatedly asked for the same feature by a significant number of customers, then perhaps you should at least consider adding it to your product roadmap?
However, not all customers are of equal value to your company, for financial or strategic reasons.
If you want more granular detail about what different customers want, then consider using tags to show who is requesting what. You could identify users as #freetrial and #customer to see what is potentially stopping some users signing up with you. Or group users into categories like #teachers and #admin to see what different customer segments need from you.
Should you be building new features?
Just because you potentially could add a popular feature request to your roadmap doesn’t mean you should. Ask yourself these questions before you add a new feature to your roadmap:
1. Should you fix bugs rather than add a feature request?
An inevitable side-effect of frequently adding new features to your product is that quality suffers. The more features you add, the more bugs could creep into your product. Your customers might be much happier if you stopped adding new features and instead made existing features more solid. Low quality can be a significant contributor to customer churn.
Steve McLeod, Feature Upvote
2. Will adding a new feature actually compromise the user experience?
Products that become too complicated can be really hard to use. Customers start looking for something simpler. Sometimes you need to remove a feature to make your customers happy.
3. Should you invest in more marketing or improved onboarding?
Perhaps what you have is a content problem. Not a product problem. No one is going to buy your product if they don’t know about it or fail to understand why it will make their life better.
Investing in marketing or onboarding can offer much higher returns that adding a new feature.
One of the most common [recurring patterns] is the belief that it is just one missing feature that is holding back a product from the commercial success it deserves. As soon as that feature is coded the sales are going to come pouring in! When they don’t, then maybe it was that other missing feature that our competitor has. It is a horizon that keeps receding until you run out of money or enthusiasm. But, in my experience, poor sales are almost always due to insufficient marketing.
4. Maybe your product itself needs to change
Time to get tough: is your product itself still viable? Or are you trying to scrub up a mouldy potato of a product that should have been chucked out years ago?
This could be the case if technology has moved faster than your product. Or the market has become so saturated it’s impossible to operate.
5. What is the cost of a new feature in terms of people and processes?
- Who do you need to build the new feature?
- And market and talk about it?
- And maintain it?
- And answer support questions about it?
- Do they have availability?
- Are they on holiday or honeymoon?
- Would they rather have hot oil poured over their heads that take on another task?
In terms of processes:
- How are you going to build the new feature?
- Does it fit with your usual processes or would you need something new?
- How much is it going to cost to implement a new process?
Not sure how to tell customers you won’t be building the feature they want? Read our article: How to say no to a feature request (5 tips).
You now have an idea of the most popular feature requests made by your customers.
You might even know which requests are most popular with important audience segments.
You’ve thought about whether you should be adding any new features this week/month/quarter, or work instead of issues like bugs and marketing.
Your next step is to analyse the most popular features in terms of a feature prioritisation grid (this article is a good introduction to a ‘lean’ prioritisation matrix)
Once you’ve done this, go ahead! You can add the feature to your product roadmap, happy in the knowledge that you have customer-based evidence to support you.
Just make sure you update the status of a feature suggestion to ‘planned’ or ‘done’. This way your customers can see that you care about their feedback and are actively implementing their requests.
Interested in trying out Feature Upvote for feature tracking?
We offer a 30 day free trial where you can try our product, and see if it works for your company.
What we like about Feature Upvote is its simplicity. We looked at similar solutions, but they were much more complicated than they needed to be.
Sitebulb, desktop website crawler