How to say NO as a PM

PMs, we all know the power of a simple no, but how do you craft the perfect no without setting fire alarms in the building?

2 Likes

Great question!

Once I read a book it suggested saying no without saying no strategy. Let’s imagine an example, one of the stakeholders comes to me as PM with a feature request that can’t be done:

  1. I would make sure that the person no that request is taken into my consideration
  2. I would ask clarification questions to provide a bigger picture not only for yourself but also for the person. These questions should be aimed to cover why actually this is a “no” for the feature.
    For example;
  • Why is the requested item needed?
  • Who will benefit from the requested item? One customer or billions of them?
  • What is the impact on the company? Monetary, qualitative?
  1. After I receive the answers it would be clear to me and the stakeholder that it can’t fit in the Product Roadmap right now.
  2. I will share an honest perspective on the product roadmap. Something like this "This feature will not serve a big customer audience and does not have an impact on the company. Therefore, I will put it in the backlog and we can come to it later when we see that more we can benefit from it ".
  3. I will thank the stakeholder and also kindly ask to keep an eye on the opportunity and agree on the ETA to come back to the topic.

This is one of the potential examples. But in general, I will always explicitly say why NO without saying NO in the beginning and put the next call to action in place.

3 Likes

I too believe in a similar model of working as well.

I start with Prioritization Principles which aligns the stakeholders too to choose a topic of discussion more judiciously.

1 Like

Despite the fact you’ll read everywhere “NO” is the most important tool of a PM, I hardly use it in my work. I even think “NO”, is a word you shouldn’t use at all. Instead of NO, I usually go for “NOT NOW” (assuming your colleagues are not submitting completely insane requests).

Today’s ideas and requirements might not fit the current backlog or roadmap, but might be very useful later on. Therefore I do collect them at the bottom of my backlogs. Only thing is you really need to be clear towards your stakeholders it will not be picked up any time soon, but you’ll keep the suggestions for inspiration in the future.

2 Likes

Interesting pov @robertzalme. But that’s stakeholder management at its finest! :star_struck: It gets me wondering, how do you end up managing those expectations later on down the roadmap?

Excellent stuff, thanks for sharing @anna_albert - seems like saying “No” is not the way to go. In reality, the model should be changed to how do you explain “why not” or as @robertzalme said, " not now".

Maybe I should rephrase my last few words “not any time soon” into something less expectationfull :laughing:

The last thing you want is stakeholders that keep bothering you about stuff you parked in the ‘not now’ lane. But if you use the strategy @anna_albert explains, you’ll probably end up with stakeholders that feel understood and will not hold back to keep dropping ideas at your desk.

Well said @robertzalme and @anna_albert. I’d add that when sharing rationale about “why not”, it’s helpful to start by establishing the assumptions and facts of the situation to make sure that the team is even aligned (e.g. reiterating the current objective, constraints, or relevant data about users that we learned in the past).

I do this in our team because we often found that our different conclusions and recommendations resulted from the fact that we were operating under different assumptions about the situation. When we’ve discovered misaligned assumptions between myself and the team, two common outcomes are that: (1) now that the other team members know my assumptions, they actually agree with my position, or (2) we discover a flaw in my own assumptions, which will actually lead me to change my mind (that could be the devs reminding me about a flaw in our measurements last time, or a constraint in the codebase, etc). Way better to discover these now, rather than later when it’ll be far more costly for us.

So to summarize, rather than saying “no” and not caring about others understanding why, I definitely see value in being open with the team because there’s always an opportunity to learn, realign with each other, and prevent avoidable costs from occurring later on.

2 Likes