5 Ways To Prioritize Features Your Customers Request
January 30, 2015 | By Dave Schneider | 3 Comments">3 Comments
Customers always seem to want new things.
And if you’re like me, you always want to give it to them.
It’s part of good customer service, and we know that great customer service drives referral marketing.
However, chances are you have some degree of limited resources, and you cannot give them everything they want immediately.
Which brings us to the important concept of prioritization.
At my current startup, NinjaOutreach, a prospecting and outreach software tool, we are always running into prioritization issues. This is because our product is extremely feature driven and we only have one developer working full-time.
So, with each new customer request, we have to ask ourselves the following five questions to properly rank it among dozens of requests we have.
And to make things more complicated, in many cases there is not always a clear answer.
Nonetheless, if you abide by this logic, you have a solid chance of taking your product in the right direction.
1. How many people will this affect?
The obvious first start is to understand how many people this feature change will affect. A feature change that does not affect many people, will likely not be appreciated by many people either.
For example, some of our customers have requested a specific type of data field, like Instagram followers. This is a very logical and understandable request, but it is probably only relevant to 10% or so of users.
On the opposite end of the spectrum, other users have asked for a more advanced filter including location and first name availability.
It should be clear that a filter that everyone can use will be more impactful, and therefore is more likely to be prioritized higher.
2. How big will that effect be?
The next question I ask is on the size of that impact. You can impact a lot of people, but if it is a smaller amount per individual, the overall value is still relatively small.
A perfect example are UI changes.
UI changes are great in that they benefit everybody, and presumably will make the software more intuitive for all current and future users. However, in my experience with UI changes, with the exception of very large-scale ones, they go relatively unnoticed.
Therefore, even though everyone benefits from UI changes, the changes are so minute in detail that they rarely result in a significant value adding experience for the user.
On the contrary, there may be a feature such as bulk email, which for us is the ability to email multiple people at once. Although not everyone is using the software or outreach, such an ability would literally save hours for those who are using it.
That’s a big change.
In fact, it would be such an improvement, that it may even entice current users to begin using the software for outreach.
Therefore, I am more inclined to implement a large-scale feature like this, than a series of small UI changes.
Of course, this is not a rule, because eventually enough small UI changes can add to a big overall UI change, so it is always a balance.
3. Does it differentiate you from the competition?
Another thing to consider is whether or not competitive products offer the same feature.
When I can offer something that my competitors do not, it makes my product stickier. This is because if the person wants this specific feature, they will have to use our tool to get it.
For example, a new feature we have been working on are automatic follow-ups. Most of our competitors do not offer this feature, or at best they only offer follow-up reminders, so we would be one of the few software’s in our niche offering this feature.
Therefore, even though as I stated before, perhaps not everyone is using the software for outreach, and perhaps even less are interested in follow-ups, those that really love that feature would be very sticky to the software if we offered it.
4. Will it improve retention?
Churn is often the killer among software companies. This is because we often bill monthly and therefore need to keep our customers happy.
Some features are just inherently stickier.
One of my previous examples was the follow-up feature, which is sticky because it is difficult to find elsewhere.
Another type of feature that can improve retention is something that increases engagement. For us, this might be a chrome extension add-on that a person can use during their day to day web surfing. Unlike the follow-up feature, this would be used much more frequently, and therefore is more likely to keep the individual engaged with the software.
The more a customer is engaged with the software, the less likely they are to churn off.
5. Will it entice new people to buy it?
Some of the most overlooked features are the ones that current customers are not requesting.
I like to pay special attention to the features that nonusers are requesting.
Why?
Because if someone is already a user of the software, to a large degree they have decided that it is solving their problem and doing a good job. That is not to say that they will never churn off, but if you have a relatively low degree of churn, it is not super likely, at least not in the near future.
Therefore, I like to consider features that will break down the barrier for new users.
For example, if somebody wants to start using NinjaOutreach tomorrow, they are likely going to want to do some sort of import since they are coming from a previous tool. Therefore, the import feature is absolutely necessary for them.
Another example, for us, is the team collaboration feature, which allows multiple people to use the same account at once. Naturally if someone is already using NinjaOutreach without this feature, they have decided that they can live without it. However, there are other people, who work on larger teams and will say explicitly that they cannot use the software, unless it has been collaboration.
Conclusion
As you can see, there are no hard and fast rules to deciding what feature you should build next. Not only do some of these questions lead to different answers, but you also have to take in consideration the magnitude of a feature request, in terms of resources. For example two features might not have nearly the same impact, but if one can be done in a few days, and another will take a few weeks, I may attack the one that will only take a few days, to maintain momentum and forward progress.
All the same, starting with these five questions is a great start.
- How many people will this affect?
- How big will that effect be?
- Does it differentiate you from the competition?
- Will it improve retention?
- Will it entice new people to buy it?
At the end of the day, if there is one thing I can say for sure, it is that speaking to both users and nonusers about your software and understanding what features they would like added is the best way to make an informed decision.
Personally, I always end every call, by asking for 1 to 2 value add features.