How to Evaluate Your User Feature Requests

Do you often receive feature requests through your support desk?

If your company sells software or other services, there's a high chance that people will come to you with their ideas for what they'd like to see you do next. The question is, what do you do with those suggestions?

To begin with, you can't take action on every single request. Software companies in particular often end up drowning in feature requests and it's just not feasible to fit everything into your development schedule. No one wants to be in an “over-promise, under-deliver” situation.

It's important to have a process in place to evaluate feature requests. We do this ourselves at JitBit - we get some awesome suggestions from our users, but we need to have a good system to ensure that we prioritize the features that will work best.

Here's how we evaluate:

Free download: Get our checklist for evaluating feature requests here

Free download: Get our checklist for evaluating feature requests here

JitBit's feature evaluation process

If you haven't checked it out already, JitBit has an ideas forum where our users can submit their feature suggestions or vote for requests made by other users. It's also used to report bugs or give other kinds of feedback.

We also often receive suggestions or feedback via our helpdesk tickets. When we get those, technicians will create a new idea and post it to the forum, so that other users can view it and vote or give feedback.

In essence, this is step one of managing the feature request evaluation process because every suggestion is being put through one central place for others to see. Instead of sifting through dozens of emails or helpdesk tickets and trying to find patterns among the requests, we can put them directly to our users to gauge the response.

This step is important because we might be surprised! Sometimes we think that surely a particular suggestion will have wide support, only to find that a different suggestion we didn't think would be as popular has more interest. This centralized way of managing feature requests saves us from requesting feedback every time some other way (such as by sending out emails) and means we don't miss any ideas.

With that said, of course we can't build every feature request that comes our way. Here's our process:

#1. Find the low-hanging fruit

If something is a quick win or easy fix, those almost always will get taken care of. This “low-hanging fruit” should be obviously beneficial, meaning that it will provide value to a great number of our users.

Our answer to these requests is to proceed right away, without any further evaluation.

What if it's not an easy fix? Then we go through the next few steps:

#2. Will it benefit the majority of customers?

Everyone has their ideas for how something can be made to better suit their particular circumstances, but sometimes an idea might be just a bit too specific to that user. We always ask whether a feature request will have broad appeal across the majority of our customers, or whether it's only useful for a small segment.

Chances are, if the feature won't be useful for the majority, then we won't consider it any further.

You can't add every feature request - will it benefit the majority of users?

#3. Will it bloat the user interface?

Our goal is to keep simplicity at the front of our user interface, ensuring that more users find JitBit an easy tool to use. Sometimes those “nice to have” features just add bloat. They make the interface less user-friendly and can create a state of overwhelm for users.

For us, it's important to nail a core group of key functions. This includes the “must have” features that will be on most people's lists. We're keenly aware that “more” doesn't always mean “better” when it comes to software.

Bloat adds complexity and potential roadblocks for users. You might have experienced this yourself – you take a look at a large software program and are immediately struck by its size. Sometimes that makes finding that one thing you want to do difficult. Which leads us to our next point…

#4. Will it complicate learning for new signups?

One secret to getting more buy-in for a software product is to solve a key problem and do it very well, and as simply as possible. Why add steps if they're not absolutely necessary?

Like many other software companies, we offer a 21 day free trial of JitBit and it's important that those new signups have a smooth experience. Complicating their learning process with additional features that aren't absolutely necessary could turn them off.

Customer expectation of software tends to be that it should be intuitive and easy to pick up. We expect to be able to sit down at a laptop and run through how a program works in a few simple steps. If a feature request is going to add barriers to that process, then we will usually rule it out.

#5. Is it possible?

At this point, we're looking into whether the feature is technically possible to build and if so, how much effort it will require. The payoff has to be worth the effort, so for example, a key feature like asset tracking or email integration would go on the list, even if they were technically difficult to pull off.

If the answer is that the feature is technically difficult and not particularly “must have,” we probably won't take it any further.

#6. Can the problem be solved another way?

Sometimes we get feature requests that we already have a solution for, but perhaps the customer is unaware the feature is there (or that there is a workaround). If this is an ongoing issue, we might decide that we need to surface the feature in the UI.

This is usually an easy fix for us as it's not really a new feature request at all. It's just a matter of establishing priority in the UI and ensuring that it reflects the priorities of users.

#7. Evaluate our answers

If we've evaluated our answers to those questions and found that there is still doubt, we turn to our customers to have the final word. We'll post to the ideas forum and look to see which requests get “upvoted” or “downvoted.” We engage in conversation with users as they make comments on the ideas.

If the final answer turns out to be “no,” we still might invite the customer who suggested it to try our “source codes” version, where they can make changes themselves. It's another option to ensure we're doing our best to help customers because they can in effect customize their experience.

Download our checklist for evaluating feature requests here

More thoughts on feature requests

We stick to the process above as we've found it to work well for us over the years, but of course, ours isn't the only way. Here are a few more ideas about feature requests and how to prioritize them:

1. Estimate the profit from building the feature. Evaluate the cost to do so versus the potential revenue, perhaps from gaining new users.
   
2. Evaluate the availability of your resources. It often takes a lot of resources to build a new feature, so make sure you've checked in with your team and understand how much they already have on their plates. How much extra might this new feature require?
   
3. Evaluate risks. Does the new feature request introduce any risks? For example, sometimes a feature can inadvertently affect other features in your software. Or, sometimes features can unexpectedly blow the budget or cause delays.
   
4. Evaluate feature requests against your overarching product vision - the guiding goal behind it. Does the request serve that goal, or veer off on a tangent?
   

Final thoughts

If you get a lot of product or feature requests coming through your service desk or other channels, it's important to have a process to evaluate them.

Many companies get caught up in trying to please everyone, but that's really not possible. If you try to handle every feature request you get, you're likely to be swamped very quickly.

Put your feature requests through a fair evaluation. We've shared ours here, but put together something that works for you. How will you separate the truly promising ideas from the rest?