People make it out to be easier than it is.

The popular view is that product managers should be focused and learn the art of saying No! (to a lot of things)

Most product leaders endorse this in their interviews, podcasts and blogs. But is it easy for product managers to always say no? Does this differ in different organizations and industries? Does it depend on seniority and the leverage one has in the company?

And what are we saying No to?

You need to say No to a lot of feature requests.

Feature requests from customers or your clients or your sales team can fill up your backlog. You need ruthless prioritization to rank them and understand which ones will make the cut. And then say No to the rest of them. OR defer them.

Are you saying no because you do not have the bandwidth to do it? Are you saying no because you do not think the requested feature/enhancement holds value for the customer or the organization? Or are you saying no because it is technically impossible to do so? Or are you saying no because it is not the right time to implement it?

If you are clear and can communicate it properly to the stakeholders, it makes a world of difference. Rather than saying No and not letting the other person know the why.

You need to say No to unnecessary meetings.

Focussed time is one of the most important assets for any individual. You have to protect it at all costs. Product Manager by virtue of their role will get pulled into a lot of meetings. It is always good to know which ones will bring value and which ones are blatantly unnecessary.

Unnecessary project status calls — I would rather get a Slack/teams message to know the status rather than attend a 30-minute call.

Defect discussion call — I would join this only if the defect solution needs a Product Manager validation.

Remember, it is always tempting to be invited to all the meetings and have a say in things. It may feel good if people ask your opinion on every possible thing, but it may end up stealing your valuable time to do actual PM work.

Sometimes you don't have the option to say No to a feature or product request — It can happen. You are not Steve Jobs. And all of us may not work at companies that have huge leverage and power to say No at all times. There are financial and organizational compulsions which may require you to say Yes to a product feature request. Present your case, but understand when to disagree and commit.

In my job as a B2B PM: Out of 10 feature requests, I need to say No to 2 of them (after judging them based on various parameters). I need to say Yes to 3 of them. And defer 5 of them to a later sprint or release. Now this may vary wildly across different domains and organization types.

When people say No, they say it in multiple ways :

1. Outright No. I can't do this. No explanations were given.
2. I can't do this. Not giving a real answer, but just a broad answer. Lack of bandwidth. Other priority items. Lack of people to do it etc.
3. I will not be able to do this. Real answers were given. They were showing empathy with your problem, but explaining the exact reasons for not taking it up. Also, let the person know if they can take it up later.
4. Ghosting. They are not replying.

Normally you should take approach 3, but at times point 2 makes sense in case you are inundated with requests. Sometimes, you don't reply because you want to buy time. This should be used so that people don't distract you with unnecessary requests.

I have found that it requires practice and intuition to understand when to say No and when to say Yes. One should lean towards focus as a Product Manager and have the courage and backing to say No.

Written by Pushkar Anand