Simple rules to validate a feature request (and the importance of saying no)

Validating a feature request is probably one of the most critical decisions for a product manager. Especially when the request comes from an important customer.

No matter which customer is making the request, the product manager should carefully analyze and validate the requirement before taking any hasty action.

It’s true that product strategy should be flexible and open to customer feedback, but it also should be consistent over time.

Before impacting the product strategy and roadmap to get done whatever the customer demands, product managers need to think things through.

It is always inviting to jump to immediate solutions, especially if it is an important customer and if it is willing to pay for the feature.

Sometimes, it is better to turn down a feature request and offer an alternative approach to the problem, in order to maintain your product’s consistency.
While it might seem counter-intuitive, you are protecting your customer's best interests in the long run by protecting your product strategy and roadmap, even if you have to say no to some of their requests.

How to validate a feature request?

I like to use the following value matrix as a simple rule to run the first quick filter.

The value matrix will only work as a decision-making framework if you have a strict definition of what value means. Having a customer insistently asking for the feature does not necessarily represent value.

You need to understand the problem your customer is trying to solve, the real impact of the feature for your customer's business, and the intersection between the value for your customer and the value for your product strategy.
Use the 5 whys approach to try to understand what problem the customer is trying to solve. If you cannot get to a well-articulated problem definition after that process, you probably should stop there and turn down the feature request.

In case you get to a well-articulated problem, try to understand the real impact for your customer’s business and your product strategy.

Once you have a clear understanding of the value and an estimation of the cost to deliver, it is easy to decide between “Yes, do it!” or “No, don’t go there.”

But what about the undefined area of the intersection Low Value/Low Cost and High Value/High Cost?

The Low Value/Low Cost features are the fill-ins. Add them to your product roadmap with low priority if it is for an important customer and doesn’t affect your product strategy.

The High Value/High Cost are the tough ones. They will probably affect your product roadmap and you will need to review the entire product strategy and priorities.

As always, a decision-making framework will only work if you are honest with the input variables. Don’t use it to rationalize an arbitrary decision. Try not to minimize the complexity of hacking the cost variable and try not to overstate the value/impact just to please the customer.

By accepting requests that don't have a real impact and compromising your product strategy, you won't be creating value for your customers in the long run.

Follow me on Twitter https://twitter.com/lucas_lodeiro