How to Say No as a PM: Advanced Tips

Techniques to stay sane as a PM and product leader

It’s the most common failure pattern in PM - for IC PMs and product leaders like:

The PM attempts to say yes to everyone.

Of course, you’ve heard this before. It’s a meme at this point:

S/O to my buddy Bart for the Meme.

But it’s actually something with a lot of truth behind it.

All of us greys in Product Management have seen it. Here’s how it roughly goes:

The PM prides themselves on being a team player and wants to ingratiate themselves with everyone. So he says yes to everyone.

For a short while, things seem to go well. Everyone likes Mr. Yes PM.

Then a few months later, and Mr. Yes is in a sorry state.

In the process of pleasing everyone, Mr. Yes walks themselves into a corner where they have several happy internal stakeholders (“she shipped my feature!”) but have not solved the core user problems and moved the metrics.

The end result is a dying, shriveled caricature of Mr. Yes.

From my vantage point, it’s clear from these stories that it is not an exaggeration to say:

How you process feedback determines your success as a PM.

So I wanted to give your some tools to process that feedback better.

It’s Something Many of You Have Asked

Many of you have reached out to me recently with a situation something like this:

The CEO has lots of ideas of what we should build.

But what he wants us to build change every two months.

And once we build his ideas, he questions why we built them in the first place.

What should we do!?

No, it’s not that your CEO is evil. Or sucks. Or doesn’t understand product management.

Remember he (or she) was likely the first product manager at the company. He’s been involved in every major product decision for years. He remembers tests you haven’t dreamt of.

And he has a much wider vantage point than you of what customers, other departments, and other investors say about what to build.

On the flip-side:

He also tends not to be in the details of working with you.

And he doesn’t know your smaller learnings.

That’s why this problem is so universal.

And so many thoughtful PMs believe something like:

I need to get better at saying no.

You’ve got to get good at saying no stakeholders that are much more senior than you on a daily basis.

That’s why I was horrified when I took a look at the most common advice online.

The 7 Myths of Saying No

A quick survey of the Google results of ‘How to say no as a PM’ unveils a barrage of misleading advice.

I’m not sure how the PM literature is so off base here. It’s leagues away from my experience.

It seems like the SEO teams got a hold of this topic and diluted it from any semblance of advice from someone who has actually practiced product management.

So let’s break it down.

There are 7 particularly misleading myths about saying no floating around out there.

Myth 1 - “Know your stuff so you have sound reasoning ready”

This lazy advice is a kind of sigma grindset mentality that you should “just work harder,” and do more to “talk to your customers” and “understand the numbers” so you can deflect every request like a Jedi.

I know just the customer anecdote to explain why that idea won’t work!

In reality, as a PM, the entirety of the organization is constantly pushing ideas on you as if they know exactly what will accelerate the growth of your product area.

You can’t possibly be prepared for the litany of feature requests your stakeholders will throw at you.

This is especially acute when it comes to things like offsites.

Your leadership is going to throw tons of product ideas at you.

You can’t just magically have the right evidence in front of you.

You need to be able to process ideas real-time and address them in the moment.

Myth 2 - “Whenever possible, show it’s not ‘not forever,’ just for now”

This type of advice is akin to the old adage:

Put it in the backlog

It’s lying to yourself and your stakeholders. There’s many ideas you’re just never going to do - at least as long as you’re at the company and in charge of that product team.

It’s better to not just string everyone along that it’s up for priority, but instead to give people a clear no.

This also prevents stakeholders from feeling like:

They’re so slow. They never get to my request.

It’s playing a long-term game instead of a short-term one.

Cut the cord - nicely.

Myth 3 - “Don’t say ‘I’”

This is some of the oddest neuro-linguistic programming advice out there.

It seems well-intentioned: make it about the data, the market needs, the user problem, the corporate vision, the market data, and the user anecdotes.

That’s what matters in product decision-making after all right?

It does make sense that you should lead with some convincing reason why you’re saying no.

But the idea of not saying I is exactly the wrong mindset to go about doing that.

It leads you down the road of acting like the evidence that you are supplying is indisputable.

The reason this falls apart is: what happens with in 6 months you learn something that invalidates the reason you said no before?

What happens if in 2 years you reverse course and actually build the thing?

Both those things actually happen often if you’ve been a PM for a long time.

As a result, it’s important to take responsibility for any “no” decision.

The better template to think through is:

I don’t believe we should prioritize that now because…

After all, as a PM, you aren’t the ultimate decision-maker anyways. The stakeholder can always escalate to executives and the CEO to go over your head.

In those cases, it’s better to have explained why you thought not to build it.

Myth 4 - “Leave room for hope”

This advice strays into the territory of “stringing your stakeholder along.”

This is a great way to have the stakeholder stab you in the back, by saying that you couldn’t deliver for them.

It’s much better for them to say something like:

She explained that it was low impact because…

If they think they’re going to get the feature eventually and never get it, they’re going to blame you.

This is a great way to find yourself “voted out” of the role.

Myth 5 - “Try Not to Say ‘No’ When You Say No”

This is another one of those pieces of goobley-gook neuro-linguistic programming advice that’s appropriate to totally ignore.

There’s no upside to not being direct. (Well, you can be too direct - and we’ll get to that later.)

But leaving your stakeholder with a vague impression that you might do it is a good way to send mixed messages.

Every stakeholder who’s worked with PMs expects them to say no sometimes. It’s better to make clear it is one of those times.

You just need to do it diplomatically - which we’ll cover more later.

Myth 6 - “Show how you prioritize product decisions”

This advice is perhaps the most common out there. And it makes sense. The idea is:

Show them your RICE score. Show them your optimization function.

It feels like the right thing to do.

But your stakeholder doesn’t care about your prioritization formula.

They care about why you not chose to prioritize their genius idea.

So it’s better to focus on what else you are prioritizing, instead of the mechanics of why.

I find these conversations usually just end in disillusionment about the prioritization framework.

And another discussion about a new prioritization framework isn’t going to help you build better products.

Myth 7 - “It’s all about the conversation”

Saying no to the wrong stakeholder can result in getting your resources taken away (it’s happened to me), people bad-talking your work in other areas (it’s happened to me), and people generally not wanting to work with you (it’s happened to me).

It feels good in the moment:

I said no!

But the actual single conversation isn’t the most important thing about saying no.

It’s more about the entire context of the interactions: what power they come to the table with, how the discussion proceeds, and how you follow up.

You can’t neglect the pre- and post- conversation.

Today’s Piece

So, clearly there are a lot of myths about saying no. How do you actually do it well?

Welcome to the web’s deepest dive on how to say no.

Over 4,000+ words, we’ll cover:

1. The quality of evidence scale

2. Conversational kung fu and the art of follow up

   • Including the VALUE framework for saying no

3. Changing your mindset to accepting and inviting “conflict”

4. The most common mistakes PMs tend to make when saying no

Let’s go through each.