Product Management – Handling Feature Requests

“The customer requested that we implement a big button that when interacted with, will do this or that.” — a Product Manager at some point.

These types of requests come in every day. Someone is in pain and they are a paying customer. They have a pretty good idea of what they want. They pressure your support and product teams, and get their feature developed.

Two years later, they still refuse to use it.

Feature Requests

In many cases we rely on customer feedback for conceiving and developing new ideas. The weak points in this process are conformism, bias, ignorance, and the lack of imagination.


Coming from both directions, conformism happens when a customer attempts to use a new product the same way as he used an old one. Whether it’s your older versions or a different product – old habits die hard.

When working on a certain Anti-Spam product, I remember a large number of customers looking for “the slider.” Probabilistic Anti-Spam engines always had a slider for setting their aggressiveness. When introduced a deterministic product with no sensitivity measurement they grew very skeptic and pressed for the development of such a slider for their configuration. In order to conform with their expectations, a slider was developed. The customers were happy although it was never moved by anyone.

Instead of conforming to old ideas and ways, it is important to identify what is or isn’t relevant for your product. An irrelevant feature will cost in the long run from both maintenance and support.


In many cases your team will be used to developing features a certain way. The product will have its existing code-base and your developers would know it by heart. After a couple of years, there will be a certain way of solving problems and a certain DNA to the proposed solutions. This bias might warp features from being usable and might also bring some unhappy customers that asked for A and got B instead.

After working on a product for some years, we’ve gotten used to deploying all of our solutions on the server-side. Deploying client changes was extremely painful and customers would take a long time to upgrade. Even customers requesting a feature would say that upgrading a client was simply not an option. This brought an extremely limited mindset.

After years of working this way the entire company was biased about client changes. New versions were scarce and limited in their features. It took us a lot of work to change that mindset and bring a revolutionary version every now and then.

In reality, these lackluster versions contributed to our clients’ inability and unwillingness to upgrade. When the product you deploy has new and exciting versions coming out every year, you’ll be implementing it in a way that allows upgrading – you would simply want to be a part of it.

Eliminating bias is important. Asking yourself “what is the ideal solution” before asking “what do I think will be acceptable” is important.
When you know the ideal solution first, you know exactly what damage you bring by compromise. You also will have a solution closer to the ideal, when you do compromise.


One paradox in having customers defining your features is that they don’t know your product as well as you do. They might not use it as-intended, and might not know about many features already in place. By blindingly following customer pains you may end up putting them in a more complex situation as well as weigh-down your own product. You must first try and observe what the customer is doing before you can judge the feature itself.

There is a certain magic to customers using your product in unexpected ways and there’s a lot that you could learn from observing that. Many of the best features a product can have come from these types of hacks.

Abstraction and Drilling-Down

One of my favorite concepts when learning Product Design was that of abstraction from focus groups. In most cases a person will come and ask you for, let’s say a jug with two handles. The request will be in the form of a proposed solution which you will need to abstract in order to understand what kind of problem you’re really solving.

There are only a couple of questions you need to remember to ask whenever anyone asks for anything:

  • What are you trying to solve
  • Why is this the proposed solution
  • What is the best way to solve this problem

Keeping in mind that you are nonconforming, have no bias, are not ignorant, and very creative – your proposed solution will be better.

You will first abstract to what the problem is (and agree on this with your customer,) you will then drill-down and come up with the ideal solution. After having the ideal, you will naturally need to decide what compromise needs to be done to make it a reality. With the realistic solution in hand – you will have your feature.

One thing that you should always keep in mind during this process is that sometimes the sales department will need this useless feature that makes no sense. It will sometimes help in keeping customers and getting new ones. It will sometimes help in soothing customer pains. Even in such cases, follow a standard process. Suggest the optimal solution and a compromise, and by doing so you’ll know exactly what the damage is when you’re “taking one for the team.”

One thought on “Product Management – Handling Feature Requests

  1. Hi there to every one, the contents existing at this
    web page are really awesome for people experience, well,
    keep up the nice work fellows.

Leave a Comment

Your email address will not be published. Required fields are marked *