5 Tips for Saying NO to Stakeholders
Audio version of the article: https://episodes.castos.com/5e296c8fcbc2e2-83044581/5-Tips-for-Saying-No-to-Stakeholders-12-01-2021-08.mp3
You can download the audio version here:
Saying no is an integral part of our job as product managers: trying to please everyone and take every idea into account is hardly a recipe for success in product development. But it can be difficult to say no, especially when we are faced with an authoritative, self-confident stakeholder (stakeholder, co-owner, key partner, leader, etc.). This article offers five practical tips to help you reject correctly.
As an example, let’s say you are talking to John, a senior salesperson who has been working with a certain product for a while. John mentions an upcoming product release and says, “We need to add more granular reporting. I have spoken with several clients and they all confirmed that this is extremely important. ” However, you know that adding an additional feature to the development process is currently not possible. The development team is struggling to cope with the current workload, and moving the release date is not an option.
Moreover, you are suggesting that John’s proposal may be motivated more by his desire to fit into the sales plan. John is an influential person with connections who doesn’t like to be disagreed with. How can you turn down his offer without hurting him and losing his support?
You can also read the content of this article on my YouTube channel…
Don’t blame yourself for saying no
It can be difficult to decline a request. You probably do not want to disappoint John in this situation, because of your concerns about the negative reaction to the refusal and the possible emergence of conflict, because you want colleagues to see your willingness to help, and not consider you a person who always says “no”.
However, saying no is an integral part of a product manager’s job. If you say yes to every idea and request, then you will receive feature soup, a product with vague benefits offered and a vague user experience. As Steve Jobs once said, “Innovation says no to a thousand things. You need to choose wisely. ” (“Innovation is saying ‘no’ to 1,000 things. You have to pick carefully.”)
If you think you cannot say no to John, it most likely indicates that you do not have the proper authority. Perhaps you lack the authority and respect you need to be in charge of a product and its successful implementation. If this is the case, you should learn about ways to strengthen your leadership in product curation. Check out my article “Boost Your Product Leadership Power”for detailed recommendations on this topic.
Express understanding of the stakeholder position
When you come to the conclusion that you still cannot satisfy John’s request, you may be tempted to share your opinion with him and say something like, “Sorry, John. But I cannot add this feature to the current version. The development team is struggling to implement the features that have already been agreed, and as you know, we cannot move the deadline. ” The answer may seem like a reasonable one: it is straightforward and contains an explanation. But will it be of any use?
If John doesn’t feel he is heard and understood, it will be difficult for him to accept a negative answer, no matter how compelling your arguments are. Instead, he may feel rejected and experience feelings of frustration or anger. He may think that you are devaluing his opinion and that you do not care about his requests. Consequently, John will no longer be able to fully trust you and will not want to support you.
In order to avoid this situation and increase the chances that John will accept the rejection, express understanding of his position before giving your answer. Find out why adding this feature to release is so important to John. What is his personal interest? If John feels that he is understood, he will listen to your point of view, your arguments and will accept the fact that it is not possible to fulfill his request. The following listening techniques can help you with this:
Pay maximum attention to the interlocutor. Maintain eye contact and show the person that you are interested in what he or she has to say.
Save impartialityeven if you disagree with what you hear, or if you dislike the person. Listen with the intent to understand, not respond. At the end of the day, John may be right and you should add this feature to the release.
Pay attention to the person’s body language. Non-verbal information such as voice pitch and volume, gestures, facial expressions, and eye movement expresses the speaker’s feelings, which helps you uncover the person’s main motives.
Ask clarifying and leading questions to make sure you understood what was being said and to motivate the other person to give you more information. For example, you might say, “Could you help me understand why adding this feature is important in your opinion?”
Bring the dialogue back on track
Stakeholders often request the addition of certain features, not always fully realizing the problem that they are aiming to solve. While the released product is young or in the process of change, its value is unlikely to depend on the addition of one single feature. Instead of discussing specific features with John, move the conversation to the main task. Find out what user or customer problem this feature can solve. How will people benefit from implementing this feature? Why do some customers, in our example, consider it important to add a detail reporting feature? And is there an alternative way to achieve the desired result?
Also, consider if the feature is consistent with the purpose of the product at the current stage of development, with the result that you want to achieve, for example, enter a new market or increase engagement. Will solving the user’s problem help achieve this goal and create the desired benefit?
If the answer is yes, then you should consider reallocating development efforts. You may decide to add this feature to the release, given that you will make the appropriate changes, sacrifice the reduction or removal of other features, or move the release date. But if the answer is no, then you should decline this request.
Don’t make hasty decisions
It may be tempting to settle an issue quickly, just to get it over with. Despite the reluctance to postpone the decision until later, it is still better not to rush.
Let’s imagine that the conversation with John turned out to be difficult. He is adamant that the feature needs to be added and does not want to take your point of view. Moreover, he doubts that you understand what the customers want and threatens to exacerbate the problem if you decline his request. In such a situation, it is natural to experience complex emotions such as confusion, anxiety, and anger.
When this happens, it is best to pause and postpone the decision to regain your composure and allow the difficult feelings to subside. You can tell John, “Finding a good solution is very important to me. But now I am upset, and I need time to reflect on your words. Let’s continue the conversation after lunch. ”
Also, consider whether you can and should make the decision yourself. If the decision matters, if you need to involve other people to make the right decision, or if you want to enlist their support, I recommend that you schedule a meeting with all key stakeholders and representatives of the development team to discuss, and, after evaluating the feature request, accept collective decision… You may even find that you need to do research and collect relevant data, such as polling users or releasing a fake feature, before you can make a decision.
Try to find a general solution, but don’t compromise
While it is sometimes impossible not to say no, I recommend that you explore if there is an alternative way to meet the basic needs of your stakeholders. Let’s imagine that your suspicion is confirmed: John’s request is, at least in part, motivated by a desire to fulfill his sales plan and receive a bonus.
If so, see if you can help him achieve his goal without adding this feature – provided that you really want to help John achieve that goal. Would it be helpful, for example, to develop a sales proposal that shows that the product meets some of the customer’s needs without introducing additional features? Or is there another solution you can find with John?
However, don’t make the mistake of compromising and asking John to partially implement this feature as part of the current release – unless it really addresses John’s basic need and hurts the pace of the development team.
Do whatever is necessary to add value to your product, but don’t try to please individual stakeholders. Be polite and firm. Remember, successful products are not built on questionable compromises or the lowest common denominator.
The translation of the article was prepared on the eve of the start of the course “Systems Analyst. Advanced “ …
We invite everyone to take part in a free demo lesson of the course on the topic: “TK according to GOST: who needs it at all?”