Five guidelines to prioritize feature requests

As a product manager, you are very likely to have more feature requests than what you can put out in a given release. In my case, a good product manager’s job at release planning is figuring out what to eliminate from consideration – you have to make hard decisions – that is what you are paid to do.

Please note that my background is working on products that have mass market appeal and did not have to deal with things like customer funded development – where a customer throws money at you to get a feature that only they will use.

Here are the five guidelines I have used effectively ….

1) How MANY customers will ever USE it?

We held a strong line on this – if the feature was meant just for the selected few (no matter how much money these customers had), we said No to the customer. You may say – no way, it will not work in my case. My reply – have you tried – Have you told your customer No and told him why? – if not try it.

I will give you an example – we had a very well known consumer company in Japan as a customer – they had bought a few licenses but had the promise of buying a whole lot more licenses – they had a lot of money. We visited them in Japan, they visited us here, met with our executives etc. – they tried to push their agenda hard on us and they had all sort of ideas as to how the software needs to work. We questioned them hard to get to the bottom of their underlying problems – why, why, why do you need to do something. They had some great ideas and some that applied only to them – we readily agreed to do the former and rejected the latter with solid business reasons why we won’t do it – not enough customers have the need.

They respected us at the end – their feedback was that we were the first vendor to have grilled them on their requests and were bold enough to turn them down, as opposed to other vendors who were ready to do whatever they wanted. They realized that we were a company that knew what we were doing and our willingness to grill them, told them that we wanted to make sure we were solving their problems the right way.

2) How OFTEN will customers USE it?

Is this something a customer will use once a year, once a month or something they would use everyday. Why does this matter? Remember the phrase “death by thousand cuts” – if something that needs to be used everyday is not supported or is very inefficient to do, it kills user productivity. This may not be something that will make a press release when you launch a new release or in your product demo, but this is something that will get you a standing ovation from your existing customers. Believe me, I have experienced this multiple times where the smallest change scored the highest in customer satisfaction. Stuff such as choosing the right default values, remembering the last used options fall into this category.

Taking how MANY customers would use it and multiplying it by how OFTEN they will use it, you get what I define as Velocity of a new feature.

VELOCITY = How MANY customers will use X How OFTEN they will use

Features with highest velocity should be serious contenders to make into your new release.

3) Will this open up new markets?

It could be something that could be asked by your smallest customer – but it could be this brilliant idea that could change the rules of the game and open up a completely new market for you. You as a product manager need to make this call.

I have been asked in the past if we implemented feature requests only from large customers with lots of licenses – my response always has been – size does not matter, quality of the idea does. This is what product managers get paid to do – take such ideas and make a business out of it.

4) Is this considered table stakes by the market?

There could be features you would need to compete in the market – if you don’t have these basic things, you are not even considered a player. These ones should be obvious if you know your market. For example, pivot tables or charting are considered table stakes for a serious spreadsheet application.

But tread this one with caution – this is where sales can take you for a ride. They will say “we cannot compete because we don’t have this X, Y and Z” and the list could be endless. For those being raised by sales, ask them to put you in touch with customers who would not buy without this feature – then from the customers get to the real problem that is solved by the feature – for all you know, you may have an innovative way to do it, or can come up with one that might change the rules of the game.

5) Is the feature a building block to the real thing?

This could be something determined by R&D (architectural changes) or some other user facing feature that is needed to support the final feature.

If you consistently use these guidelines, you end up making a business case why you want to turn down a feature request – this even works with executives because it is now based on facts and not opinions. After all this, if some higher up overrides your decision, it is not in your hands, but you know you did your analysis.

8 thoughts on “Five guidelines to prioritize feature requests”

  1. Not sure my last comment saved! I agree with much of this Gopal…! You have to have a strong and clear product & business strategy otherwise it’s all too easy to start getting pulled in the wrong direction by the next exciting prospect. We all have limited resources to work with so to succeed, it’s essential to build the features with the highest impact.

  2. Agree with so much of this. You have to understand WHO requests are coming from and every request has to be stacked up against the product & business strategy. It’s surprising that saying “no” can actually lead to a better relationship. You have to have a clear vision for your product otherwise it’s very easy to get pulled around by the next exciting prospect.

  3. Thank you for sharing this – very interesting insights. What I took from your post was that it’s going to be different factors for every business, but that strategy is obviously key.

    I’m a big believer that you don’t just need to build a product your customers love, you have to build the product your business needs…that’s why you need a clear strategy.

    Few notes on each point:

    1) How many customers will ever use it?
    I’ve been in the situation you have described here. It can be all too easy to get pulled around by a loud customers or demanding stakeholder. I find that capturing and understanding the requests and priorities from all the customer groups and internal teams (like sales, engineering, support, leadership etc…) allow me to make balanced and informed decisions.

    2) How OFTEN will customers USE it?
    We have an open feature request area for our customers. Because it’s completely separate from support, we tend to capture a lot of day-to-day annoyances that we would not otherwise hear about. Our users can then vote for, discuss and prioritise their requests which gives us a deep understanding as to how integral the request is to the system as a whole (i.e., how often it’s likely to be used).

    3) Will this open up new markets?
    A great and very strategic point! We tag up our feature requests so we can easily filter out requests which will help facilitate future sales and business growth. Using a single system allows us to capture this information directly from customers and through our sales & client-facing teams.

    4) Is this considered table stakes by the market?
    Agree! You have to handle sales requests carefully. In a lot of industries, there are often features you *need* to facilitate a sale (doesn’t necessarily mean the feature actually gets used!!) but it’s about the perception and the marketing of your product.
    We find a lot of feature objections tend to disappear once we have someone using the product so we tread carefully, gather the requests and priorities of prospects then it’s always easy to see if there is actually something we need to act upon.

    5) Is the feature a building block to the real thing?
    Yes, you should always bring data to the decisions. This helps massively when you have others you need to convince of your direction and roadmap.

    Take a look at as our system solves these issues very elegantly!

    You might also like this:

  4. Some great points in there. Completely agree that prioritisation and understanding how feature requests fit into the company strategy as a whole are vital…that’s a key part of product management that’s very difficult to get right. I feel we have to build a product our customers love but also one that our business needs.

    We have all our customers and internal teams prioritise their feature requests and we also segment all of that information so we can understand exactly what’s important to our Enterprise users vs smaller account and what’s important for each team from management to sales and support. That way we can ensure we are working on things in our product that align with the direction we need to take the business in. You only have so many developers so you need to make sure they are building the right stuff!!

    Totally with you that you can’t be beaten about by one big potential lead or large customer. So easy to fall into that trap until you get mechanisms in place that allow you to say no.

    We also find time & time again that it’s the small improvements that have the biggest impact with customer satisfaction. Interesting to see you find that is often the case too.

  5. Prioritize on revenues. Revenues only show up if the functionality provides value to a customer base large enough to pay for it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: