How to say no to your stakeholders
A stakeholder is anyone who has an interest or is involved in a product, and often they are the people who are asking you to do things with your product. Sometimes you'll not be in a position to do what they ask, so you'll need to say no. The question is, how do you say no?
Saying no to people comes hard for some, however, it needs to be a keyword in the vocabulary of a product manager.
It is simply impossible to please everyone who wants your product to do something.
You can easily be approached in the morning and asked if you can make something red, and then in the afternoon approached by someone else who asks to make the same thing blue.
You have to say no to someone! The question is how?
Let's see if you recognize this scenario:
The Head of International Sales stops by your desk and says that in order to get a new big client on board we need to add the data visualizations to the product before the end of the month as it will be the thing that will wow them and make you stand out from the competition.
At the same time, the development team are flat-out dealing with last-minute testing on the latest release.
What do you do?
Don't panic!
The chances are that you won't need to make an immediate, on-the-spot decision. And in reality, the decision isn't always just down to the product manager. You are able to consult with the team, or other stakeholders, to flesh out the information you have at your disposal before you make your decision.
Buy yourself some time to gather the necessary information and agree to come back to the person within an appropriate timeframe.
If ultimately you need to say no, then ...
It's nothing personal
This is a valuable lesson to remember. It might be hard to say no to the Head of International Sales, but you're not rejecting them or their idea, you might just not be in a position to help get the data visualizations feature live in the time period they're asking.
All parties are seeking to find ways to do what they need to do for the organization, rather than find a way to upset each other. Keep things professional and you can all move forward.
Show you empathize
Empathy is one of the product manager's superpowers and it's something that can take you a long way. You need to ensure that your stakeholder has had the opportunity to say what they wanted to say and the outcome of this should be them knowing that you've heard their viewpoint.
If they don't think you've heard them, then they won't react kindly to you rejecting their request, which can cause them to try to go around you to get what they want and also not trust you going forward.
Reposition the conversation
The decision that needs to be made is often not a direct response to the request itself, but a result of a wider reason that might not be immediately apparent to everyone, so if you have the opportunity to reframe the conversation then you have the chance to gather more information for all parties.
A conversation about why the feature is so important to users might prompt ideas on how this could be met within the timeframes. A discussion relating to how the competition approaches the problem might result in an existing feature being a suitable alternative.
Is it a firm no, or a not now no?
Are we never going to deliver data visualizations, or are we simply not going to deliver data visualizations by the end of the month?
There's a big difference between the two and the responses you give will be completely different.
If you're never going to deliver it then you'll need to back up the decision with data that confirms why this decision is being made. "We can't deliver this because the platform does not support them and would need to be rewritten which will take months".
If you're going to deliver them just not immediately, then you should be in a position to provide supportive information on where in the roadmap the feature is likely to be, so that this can be communicated to the potential client.
Give one reason for saying no
An example used by Mountain Goat Software in their post on saying no goes like this:
If you say "I’m sorry but I can’t do that. We’ve already planned this sprint. I’d need the team to have another planning meeting, and they won’t like that. And I’m confident that what we’re currently working on is a higher priority." then which part of the argument is the other person going to focus on?
They’ll go after the argument that the team would need to do another planning meeting and won’t like it. They might offer to make the meeting less unpleasant by doing it over lunch and I’ll buy the pizza. Now the conversation has changed to a discussion about whether to conduct a meeting rather than over the merits of the feature. That’s a more difficult argument to win.
Explain the result if you say yes
Sometimes, just pointing out the consequences of saying yes to the other person will allow them to say no to themselves and avoid you having to do it yourself.
"If we change the team's focus now then we put the current release at risk, which as you know can cause a problem for all our clients and run the risk of some customers leaving."
However you go about it, you need to approach it in a way that doesn't burn any bridges and seeks to find the best outcome for the organization. After all, that's what you're there for ... delivering value.