How to say no as a Product Manager?

Grumpy cat PM who didn’t learn how to say no

A friend once said they think product managers are the most hated individuals in an organization. I disagree.

While I didn’t concur with my friend’s statement, I could understand why they said so. If you’re a product manager or have worked with product managers, you would know how often PMs have to turn down requests from stakeholders.

‘I will discuss this feature suggestion with my team and get back to you.’

Or

‘That’s a great suggestion! However, my sprint is completely locked now. How about we pick this discussion up some other day?’

Or

‘Sorry, but we cannot take this up in the current quarter.’

All of these are just different (read: bad) ways of the PM saying no. And this must happen at some point or another. Why? Because as the PM, you own the product, know the vision, and define the way forward. And if there’s any suggestion or request by a stakeholder that doesn’t align with that vision, you must say no.

You might be thinking there’s a contradiction in what I have said so far. Communicating no to stakeholders yet not being the most hated person in the organization. Who is Khadija kidding?

But I’d rest my case on two assumptions:

1. If you are disliked in your organization for saying no then you do not understand how to say no
2. If you hate people who say no to you then your suggestions are not being turned down properly

When I began my career as a Product Manager, I found saying no extremely hard. Why?

1. I was friends with most business teams who sent me feature requests
2. I could sense the annoyance amongst team members when I turned down their asks

Business teams chasing the PM who just said no

I didn’t know how to say no. However, I have learned it the hard way. And this does not necessarily make me the most liked product manager, but it certainly convinces the other party enough for them to not hold a grudge against me.

What’s the secret to this art of saying no? It’s straightforward: empathy.

Let me break this down in a few simple steps:

1. Take a step back

When faced with a request from business teams, I have often seen product managers like myself getting overwhelmed and saying no immediately. Sometimes, we say no; other times, our body language becomes incredibly defensive. This shows two things to the other person:

1. We are unempathetic (and trust me, no one likes people who can’t empathize)
2. We have immediately built impenetrable walls around us (in other words, we seem unreasonably stubborn)

Imagine a business stakeholder comes up with a feature request and urges you to make it a part of the current sprint.

However, this time, instead of saying no almost immediately, you take a step back and appreciate the stakeholder for coming up with a feature suggestion.

‘Hey, Sophia! That’s an excellent solution to solving our users’ pain points. Thanks for bringing this up.’

2. Listen and respond

Show them you’re taking time to understand what they have just said.

‘If I understood your request correctly, we need to bring the most-selling products to the top of the homepage. How do you think we should define top-selling products? Either we can do it in terms of units sold or revenue generated.’

3. Build transparency

Remember to keep the conversation data-driven, outcome-oriented, & focused on:

a. Resolving user pain points

b. Meeting business objectives

‘Got it. Let me share with you the 4 features we are building in the current sprint. They aim to enhance our customer experience and reduce complaints by 90%. Similarly, for the business, rolling out these features is expected to increase our revenues by 20%.’

4. Define priorities

Once you have explained the what and why aspects of what is being built, draw a clear picture of where the stakeholder’s suggestion/request stands compared to the already prioritized features that are being built.

‘As you can see, these features would be an absolute game-changer for us! The ranking feature, while absolutely incredible, is a medium-level priority for us’.

5. Define the future

So far, you’ve only done 50% of the job of saying no. Now, if you leave it hanging there, the stakeholder is going to go out of this conversation unsure when their feature will be prioritized.

Yoda after having his feature request turned down

Your team members expect you to define the future as a product manager. Hence, as the last step, you need to paint the future for the business stakeholder.

‘To map it out in terms of timelines, I see it being moved into the ideation phase somewhere around the second week of the next month. I’ll briefly discuss the idea with my squad and get back to you with some more concrete timelines by the end of next week. Does that work?’

That’s it! You have:

1. Shown your team member that you appreciate their input in building the product
2. Instilled in them an appreciation for you as you didn’t only listen to their point of view but also asked a follow-up question to drive the discussion
3. Given the clarity on what you’re building and why you’re building it right now
4. Laid down the plan of action regarding the stakeholder’s feature suggestion and thus, set realistic expectations

Hence, you can be a likable product manager who says no when it is needed. To sum it up, you should always empathize with the other person, listen to them, provide transparency on your current situation, and map out the future, so they’re not left guessing.

Just performing these simple steps the next time you say no to anyone would make a huge difference.