The Subtle Art of Saying No

I can’t remember a single project I worked on that we had enough time to implement extra nice features and all stakeholders’ ideas. It was always a hard decision between what to pick up and what to put in the long waitlist. Because of that, knowing how to say no to people in a proper way is a skill quite important in a product manager.

In my opinion, one important thing to know when saying no for someone is how to express it in a way the person you are talking to can digest it properly. What do I mean by that? Well, we are people, and each one of us has a different personality, a different prospect of thing and, let’s be honest, we can be quite selfish too and only see our side of the story.

When I start working with someone, I try to understand who this person “works”, her/his personality, and find out the best way to have a good relationship with this person. By doing that, when I need to explain things to this person, I do it in a way that the information can be received gently and give her/him time to process what I am saying.

In this approach, I add a good explanation of my reasons, what the development team has in their hands already, and what is the impact of each prioritization scenario. It is always good to show that you tried a different perspective to see how could you help to fit this person’s requirements in the product. That your decision was not random.

There are also the cases that the stakeholder’s or the client’s idea should not be considered at all. It is common to receive requirements that would make the product so complex, or drive the product to a too generic concept, or just that does not make sense at all. In those cases, it is also important to explain why you are saying no. Maybe you need a new product, new marketing research, a better understanding of the problem you are trying to solve. It is also typical to receive solutions ready, and this can bring lots of misunderstandings and problems to the product. Try to focus on the problem you are trying to solve, always, and then generalize it to see all the options you have to solve it. The development team can always be helpful in this part, they can have brilliant ideas on possible solutions together with the product manager.

I worked in some hard and complex products and projects, and I have no idea how many times I had to say no. Even then, I always had a really good relationship with clients, stakeholders, business owners, and so on. Although I was saying no, I was always trying to help on how to find a temporary or alternative solution for them.