One of the biggest challenges for product managers is working out which feature requests will help your company grow and which will be an expensive mistake. This involves working out whether the feature request is needed by the market – rather than just by a few vocal customers – as well as considering whether building that feature is feasible and fits your company’s strategy.
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%.
Dealing with roadmapping challenges
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.
This is a quote from one of the Mind the Product respondents. Too often product managers are asked to roadmap feature requests without sufficient information.
Customer research such as surveys or customer interviews take time. Plus feature requests are hard to collect, organise and qualify. They come through multiple channels, you’re not sure if anyone has already suggested them, and you don’t know how to roadmap them without making awkward judgement calls.
Don’t let roadmapping feature requests ruin your day.
It doesn’t have to be this way. In the next section we’ll look at some ways you can more easily roadmap feature requests.
Consider quickly prototyping the feature
When the team invites real users to try a prototype, they’re collecting data about the users’ needs, which provides a solid footing for the design
— Jared Spool about Design Sprints
Quickly prototyping the feature is a great way of working out whether customers will love it – or not. It’s also a useful way of deflecting advice from senior members of the team that you’re pretty sure doesn’t fit with your team’s strategic vision for the product. It’s hard to argue with real data.
However, if you’re being asked to roadmap feature requests without user research then trying to get your company to prototype the feature will likely be tough. On a par with Elon Musk colonising Mars. Perhaps prototyping a new feature simply isn’t feasible given your company’s small and super busy development team, or the complexity of the feature, or time constraints.
In this case, you could try the following.
Do user research on the cheap
Any user research is better than none. If you don’t have anyone responsible for user research on your team just do it yourself. It’s not like you have anything else do do, right?
Send out a quick 3-5 question survey to your customers, trial users and perhaps even ex-customers (they might not answer, but if they do you could get some gems). Ask questions such as:
- How would you describe our product to a friend?
- What was going on that made you sign up?
- What challenge did you think our product would help you solve? Has it helped with that challenge?
- Is there a feature that you couldn’t live without?
These should give you an idea of how your customer is using your product and what they think about it. Once you have this information, it’s much easier for you to see if a specific feature is going to be useful or not.
Any user research is good user research – like this short survey.
I’m guessing you already know a fair bit about who your customers are. Just make sure you are also clear about how they use your product. This can often be in unexpected ways so don’t just go with your assumptions. I find that a mixture of looking at your data and reaching out to customers with a quick question or two will provide a decent picture.
Once you know the various use cases for your product, and which are the most lucrative, you’ll have a better idea of which feature requests will help your customers. Some feature requests might help everyone. Others might help certain use cases, which could still be good news if you want to grow that specific market.
Consider using a feedback suggestion board
These are a great user research tool, and increasingly popular. You can use them in two ways:
Create a public suggestion board for your customers
Too often we think we have a good idea, but we’re starting on the supply side. We’re looking for excuses to build the thing that we want to build, and the real trick to going deeper with product is to learn to move backward and get into the demand side and ask: Why is this the right time? Why is this important? What matters right now?
— Ryan Singer, Product Manager at Basecamp.
Instead of getting feature requests through multiple channels, invite your customers to add feature requests to a central suggestion 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 mess around collecting feature requests yourself. Those feature requests are prioritised by your actual customers. This means you avoid the problem of prioritising feature requests from customers that shout the loudest.
Another benefit of a public suggestion board is that you can test out feature ideas from on high. If your CEO has a feature request they want implemented simply pin it at the top of your suggestion 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.
This is the suggestion board for Sitebulb, a desktop website crawler, provided by Feature Upvote.
Create a private suggestion board for your team
If you don’t like the idea of going public with feature requests, then what you can do instead is draw on the experience and insights of your entire team. Create a private suggestion board and invite team members to add and vote on feature requests. You can plan to do this on a special ‘ideas day’ or longer-term. It’s up to you.
The benefit of this approach is you get to qualify feature requests based on knowledge drawn from the whole company. So this takes the weight off you. You don’t have to make a judgement call all by yourself.
Be clear about the feasibility of feature requests
Just because you potentially could add a feature request doesn’t mean you should. Ask yourself these questions before building any new features:
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
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.
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.
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.
Don’t blow up your budget with new features that won’t help you grow your company.
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?
Once you’ve answered these questions you’ll have a much better idea of whether a feature is feasible to build, now, considering the cost versus the potential return.
Take the emotion out of the process
Roadmapping feature requests shouldn’t be the hardest job you have to do. But it can be. You’re all to often under resourced, forced to make value calls, and faced with people who can take rejection of their idea very personally.
Prioritization can be polarizing because it’s often perceived as choosing one person’s ideas over another’s. When people have something personal invested in an idea or feature that’s on the chopping block, emotions can run high.
The way round this conundrum is to get user research and data on your side. Priorities are easier to filter when you have facts.
People are never going to stop being emotional (we’re human – it’s great!). But when faced with evidence most of us are willing to listen and accept the resulting roadmap, even if it’s not what we suggested ourself.
Then, when that new feature is a hit, we’ll forget our vision ever differed from yours.
Want to try out a suggestion board?
Give us a go at Feature Upvote! We offer a 30 day free trial, no sales call guaranteed.
Try us, see if you like us. If you do, fabulous, if you don’t, fair enough.
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