When we talk about prioritizing a roadmap, one thing that may happen is we end up saying yes to every request, from everyone. That is, everything is important because everything is added to the roadmap, and then the less important things are postponed. The person who requested has the confidence that “it’s in the roadmap”, although it was pushed up front on the line, and has good chances of being pushed even further if some more important item comes up.  

Why does this happen?

The product manager ends up saying “yes” to all the requests he/she gets for several reasons:

• Need to please everyone: this is a very common problem of product managers, the need for pleasing everyone. When product managers see that the answer “I’ll put it in the backlog” calms down people who are requesting something, they start to use this answer indiscriminately. Then, the roadmap will get huge and very complex to manage. In addition to that, when people realize that “being in the backlog” doesn’t guarantee that it will be done soon, they won’t be happy. :-/
• The data shows that we must do: more and more I see companies focused on making decisions exclusively based on data. Therefore, soon we can be replaced by algorithms that will make all decisions since it is enough to make them all based on data. It happens that data is not always correct. They can be insufficient, or even wrong. Another problem of decisions based on data is the risk of falling of in a local optimum, i.e., a solution that is optimal within a neighboring set of candidate solutions without an opportunity to explore not so obvious solution. The suggestion is to use data as one of the inputs to make a decision, but not forgetting the qualitative data, your intuition and your judgment. 
• But it is such a small feature: every feature, as small as it is, will imply in more code and more interaction. More code means code complexity, as the code gets more complex, it is more difficult to maintain it. More interaction means more complexity for its user to work with, that is, more chances of offering a bad experience to the user. No feature is so small that it won’t bring code and interaction complexity, so think carefully if this additional complexity will bring benefits for your user and for the software owner. 
• The client requested and, if we don’t build it he’ll leave: this is the moment of making tough decisions. If you want to please all your clients, you’ll end pleasing none of them. You have to choose to whom you are building your product. A product cannot have more than two or three primary personas. By the way, the recommendation is to have only one primary persona; having two or three will be quite a work for managing. If the client’s request does not attend your primary persona, you have to have the courage to say no.
• We can always turn this new feature into one more option in the configuration: one more time, we are creating pointless complexity. As we said, every feature implies in code and interaction complexity. Putting all new features as options to be configured in a setup screen will turn this screen into something very difficult to its user. 

• Our competitors already have it: this is a very common mistake, base yourself on competition and not on your client/user. Remember: a product manager has to worry about making the software meet the goals of the company that owns it, at the same time he/she solves a problem or fulfill a need of the clients. It is important to know what the competitor is doing, but if it has nothing to do with your company’s goals, nor the problems or needs of your client, then you don’t have to do the same. 
• The boss wants: there are bosses and bosses. If your boss is extremely up to date regarding the clients, it is important to listen. But if your boss wants a certain feature just because he/she saw it in some competitor or someone told him/her to do so, you should remind him/her of the company’s goals and the problems and needs of your clients that you are trying to meet with your software product.

Learning how to say NO!

In spite of all the reasons we saw here, it’s quite common to see product managers ending up saying yes to each and every feature request. In order to avoid that, a product manager has to learn how to say NO.

Saying NO seems difficult, but not if you have your product goals very clear. Knowing which company goals your product must reach, who is your main client and what is the problem of this client you are trying to solve, you’ll have the necessary arguments to say NO to certain demands. 

Be kind to the person who is bringing the demand and say something like:

Your suggestion is interesting and I can see why you are giving them. However, let me show you what we have already planned in our roadmap, and which are the goals of each item in it. For this reason, we will not be able to pay due attention to your request right now. Remind me in the future so we can talk about this again, ok?

Pass on the responsibility for remembering the conversation again in the future for the person who is requesting the new feature. If he/she does not remember, it is because his/her request was not that important. If he/she remembers, evaluate the request again and, if necessary, say NO again. 

Digital Product Management Book

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my book Product Management: How to increase the chances of success of your digital product, based on my almost 30 years of experience in creating and managing digital products.