Product Managers learn to say “No”

Learning to say “No” will make you a better PM, and result in you shipping a better product.

Saying No to a “small feature” request, or “just a tiny update” can be tough, especially if it comes from “higher ups”, usually there’s just so many times you can push back.

In his great talk Des Traynor taught us that “Product Strategy is About Saying No”, for a Product Manager knowing to say No isn’t just a good quality, it’s a MUST!

Wouldn’t it be easier if you didn’t have to say “No”, all the time?
What if instead of saying “No” all the time, and becoming the “No person”, you’ll become the “Laser focused PM”?

Below I’ll share how to frame your answers in such a way that would increase the likelihood of the person coming up with the “brilliant idea that will only take 2 hours to implement” to say no to his own idea.

Building blocks of saying No

First you need to understand, internalize and constantly communicate two key points:

1. There’s no such thing as a small feature!
   They are features that haven’t gone through analysis, or shaping, but they aren’t small, and shaping takes time. Take my word, I’ve been burned quite a few times by this myth 🔥
2. Put in place clear boundaries of what the team is set out to accomplish, preferably in what timeframe.
   Team goals/KPIs/OKRs anything you choose to work with, just have clear, agreed upon goals!

Putting the blocks into place

The solution to the first key is simple, whenever someone asks for a “small change” reply that you and the team “need to look into it”.
Don’t agree to anything before breaking it down!
If challenged into why you can’t give an answer on the spot, clarify that it won’t be responsible/professional to give an answer without checking the impact of this change (use testing, analytics, support, and some of the bullets in the image above and Des’s talk as reasons…).

The second key is harder, but that’s a core part of Product Management, before you set out to work on any effort, define the boundaries.
Make it a habit for any team or effort you start to first put in place boundaries.
Don’t just take my word for it check out the Set Boundaries episode from Ryan Singer’s Shape up.

Also in her book “Escaping the Build Trap”, Melissa Perri defines a good Product Manager:

clear, outcome-oriented goals
Escaping the Build Trap

Great we understand that we must establish boundaries, but how do we do it?

Define clear team Objectives/goals/KPIs/Boundaries/Scope

This is a major one, no matter what your organization calls them, you must have some form of goals/objectives. If you don’t have such a thing, work with the team and management to put them in place (easier at first to frame it as an experiment only for your team or only for the this effort/quarter/etc.).

Not defining clear objectives will come back to haunt the team:

1. Prioritization — How can you agree on what’s the next best move if we don’t have a common agreement of what we’re set out to accomplish (and when)?
2. Measuring progress — How will you know in 3 months that you made any progress?
   If it’s because you shipped features, congratulations! You’re in the build trap, go read Melissa’s book.

Time to get laser-focused!

Once the blocks are in place, you internalized that they are no small features and you have clear boundaries in place, saying “No” is way easier.

Let’s take it for a spin:

Someone comes to you with “a game changing idea, that we must try now!!! And… it will take less than a day to implement! We should do this NOW!!!”

1. Don’t get emotional, not excited, not pissed off, it’s part of the job, and it might actually be a good idea, stay calm and say you need to look into it deeper, encourage them to write a few words why this is such a great thing.
2. Ask does this feature fall into the team’s current boundaries?
   If it does, go to #3, otherwise “No” (unless team boundaries are wrong, but that’s a discussion for another post).
3. Is this the most impactful action towards the team’s goals?
   If it is go to #4, otherwise “No”.
4. Is it more important than what you’re working on right now?
   If so, great, “we’ll need some time to shape it, and then we can discuss priorities.”
5. Any other outcome should lead to “No”.

If the other person is super persistent you can try to deflect with “Let’s schedule it for future phases”, however this isn’t a preferred outcome, we’re here to practice saying “No!”, and deliberately choosing what we won’t work on.

Do this enough times with your team, and overtime instead of just saying “No” you can go through this process with the person suggestion the feature, if they agree with the team boundaries they’ll probably reach the same conclusions, but you can also simply say “No”.

Take it for a spin, let me know how it worked.
Try saying “No” at least once!

If you enjoyed this post, check out my other posts about practical Product Management, and don’t forget to follow me.