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.
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.
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:
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.
These are a great user research tool, and increasingly popular. You can use them in two ways:
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.
For tips on getting customers to use your public suggestion board have a look at our blog post: How to get and manage customer feedback.
This is the suggestion board for Sitebulb, a desktop website crawler, provided by Feature Upvote.
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.
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.
— Andy Brice
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?
In terms of processes:
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.
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.
— Richard Banfield
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.
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