Product managers talk and listen to many stakeholders, because they want to understand the needs and desires of the market. An important part of that process is sharing, especially the strategic product road map.

Sharing this information does two things:

It lets the customer know that you are willing to let information flow both ways. This help them share more specific details (the kind product managers really need) and not feel like they are providing information for free.

Sharing also lets them see the future plan for the product and how their future plans fit with what has been mapped out.

While there are certainly benefits to sharing the road map with customers (and even sometimes prospects), it comes with drawbacks, too. Every customer has needs that are specific to their business. They frequently look to the product manager (and the product road map) to help them resolve those needs.

In many cases, that information is valuable in helping the product manager address the needs of an industry or vertical market, or even a type of user. Unfortunately, it can also lead to adding features to the product that serve only a few users. These choices are sometimes unavoidable, but, over time, they can lead to bloat, misdirection, and mediocrity of the product.

As a result of reviewing the road map and not seeing what they want on it, or in the time frame that they want it, customers make requests to raise the priority of a particular feature or to add a new capability to the product that was not being considered. This is where “no” comes into play for product management (see Rule 2 by Brian Lawley). Saying “no” lets product managers focus on delivering superior products, rather than ones that are merely sufficient.

Let me use the following to illustrate the value of saying “no.”

This is a real experience I had with a customer who repeatedly requested a feature that was very low on the priority list. No other customer (or prospect) had asked for anything similar, so it remained low on the list because it didn’t align well with where we were planning to take the product.

Every conversation I had with the customer team included a question about when they would get the feature that they had been asking for so long. Early on, I would provide a response that is common amongst product managers: “We have captured the requirement for your requested feature, but it is not assigned to the next release.” While this settled the discussion for the moment, it only delayed revisiting it the next time there was a release announcement.

Ultimately, I drew a line in the sand and told the customer that even though the feature was important to their business, I did not see that it would ever be in the product. Despite the customer team initially being quite upset and frustrated with my response, and getting a call from their CEO about her disappointment about the state of the product and its ability to meet their needs, telling them “no” was the right decision for them and the product.

I spoke with the customer team again several months later with a decidedly friendlier outcome. They told me that because I had told them that they wouldn’t get the feature (rather than the feature being delayed), they had decided to invest in building the capabilities they needed in-house and were very happy with the results. And they were happier with my product too.

They had the feature they wanted, exactly how they wanted it, and within the time frame that they wanted. And all of this was made possible because of the power of “no.”

“No” can be taken wrong by many customers, it may have worked here but it won’t work with all clients.
I have used different language very successfully “Your request is captured but It has not gotten interest from other clients. So it’s not currently scheduled to be worked on in the near future.”
This sends the same message without being too harsh.

I like your approach Jordan. Acknowledging that the customer’s suggestion is a good one yet not committing to doing it allows them to feel heard and validated and is less harsh than simply saying “No” outright.

I think that you can often do better than simply saying “no”. If their request is unique because they are not following standard industry techniques, you could make them aware of alternative ways to use the product to meet their needs. Or perhaps it would be a priority to a third-party to add the capability as an extension to your product or as a professional service, and tie the third-party closer to your product.