Saying “no” lets product managers focus on delivering superior products rather than ones that are merely sufficient.
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.”