5 Tips for Saying No to Stakeholders
Saying no is a firm part of our job as product people: Trying to please everyone and taking on board every idea is hardly a recipe for achieving product success. But saying no can be tough, especially when we are faced with a senior, assertive stakeholder. This article offers five practical tips to help you say no in the right way.
You can also listen to the audio version of this article and watch the video below:
Imagine that you are talking to John, a senior salesperson who’s been involved with the product for a while. John mentions the upcoming product release and says, “You really must add the enhanced reporting feature. I’ve spoken to several customers, and they have all confirmed that it is absolutely crucial.” You know, though, that it is impossible to add the feature to the development effort. The dev team is struggling with the current workload, and moving the date is not an option.
What’s more, you suspect that John’s request may be motivated by the desire to meet his sales targets. But John is a well-connected and influential individual who doesn’t like to be told that he is wrong. How can you decline his request without offending him and losing his support?
Don’t Feel Bad about Saying No
Declining a request can be hard. You might not want to disappoint John in the example above, you might worry that saying no will anger him and lead to conflict, or you might not want to be seen as a naysayer but somebody who has a can-do attitude and wants to help.
Saying no, however, is part and parcel of a product person’s job. If you said yes to every idea and request, you would end up with a feature soup, a product with an uncompelling value proposition and a poor user experience. As Steve Jobs once said, “Innovation is saying ‘no’ to 1,000 things. You have to pick carefully.”
If you believe, however, that it would be impossible for you to say no to John, then this may indicate that you are not properly empowered, that you lack the authority and respect required to be in charge of the product and be responsible for its success. If that’s the case, explore how you can strengthen your product leadership. Refer to my article “Boost Your Product Leadership Power” for more guidance.
Empathise with the Stakeholder
Having decided that you can’t accept John’s request, you might be tempted to share your view with the individual and say, for instance: “Sorry, John. But there is no way that I can add the feature to the current release. The development team is struggling to implement the agreed features, and, as you know, we can’t push out the date.” This might seem like a reasonable answer: It’s direct and it offers an explanation. But would it be effective?
If John does not feel heard and understood, it will be hard for him to accept no as an answer, no matter how valid your arguments are. Instead, he might feel rejected and react with disappointment or anger. He might think that you don’t appreciate his views and don’t care about his needs. Consequently, John may no longer fully trust and support you.
To avoid this situation and maximise the chances that John can receive a no, empathise with the individual before you offer an answer. Find out why the feature is important to John. What is his personal, vested interest in getting the feature included in the release? Why does it matter to him? Only if John feels understood will he open up to your perspective, listen to your arguments, and accept that you can’t add the feature to the release. The following listening techniques will help you with this:
- Give your full attention to the individual. Maintain eye contact and show the person that you are interested in what she or he has to say.
- Keep an open mind even if you disagree with what you are hearing or if you dislike the individual. Listen with the intention to understand, not to answer. John might be right, after all, and you should add the feature to the release.
- Pay attention to the person’s body language. Non-verbal information — like voice pitch and volume, gestures, facial expressions, and eye movement — expresses the speaker’s feelings, which help you uncover the individual’s underlying interests.
- Ask clarifying and probing questions to check that you have correctly understood what was said and encourage the other person to provide more information. You might say, for instance, “Can you please help me understand why adding the feature is important to you?”
Reframe the Conversation
Stakeholders often request specific features without necessarily being fully aware of the problem it addresses. But value is hardly created by adding a single piece of functionality — at least as long as a product is young or changing. Instead of debating an individual feature with John, reframe the conversation. Explore which user or customer problem the functionality would help address. How would implementing the feature benefit these individuals? Why do some customers view it as crucial, to stay with the example above? And would there be an alternative way to achieve the desired impact?
Additionally, consider if the feature is aligned with the product goal of the current development effort, the outcome you want to achieve, for example, to enter a new market or to increase engagement. Will addressing the user problem help you meet this goal and create the desired benefit?
If the answer is yes, then you should consider adapting the development effort. You may decide to add the feature to the release, assuming that you make appropriate adjustments like reducing or removing other features or moving the delivery date. But if the answer is no, then you should decline the request.
Don’t Rush the Decision
It can be tempting to quickly make a decision just to be done with it. While you don’t want to procrastinate the decision, rushing it is usually a bad idea.
Say that the conversation with John has turned difficult. He is adamant that the feature must be added, and he doesn’t want to accept your view. What’s more, he suggests that you don’t understand what the customers want, and he threatens to escalate the issue if you decline his request. In such a situation, it’s natural to feel difficult emotions like confusion, worry, and anger.
When this happens, it’s best to pause the conversation and to postpone the decision to regain a cool head and allow the difficult feelings to subside. You might say to John, “It’s really important to me that we find a good solution. But I am feeling upset right now, and I need some time to reflect on what I heard you say. Let’s please continue the conversation in the afternoon.”
Additionally, consider if you can and should make the decision on your own. If the decision has a bigger impact, if you require other people’s input to make the right decision, or if you want to secure their buy-in, I recommend scheduling a meeting with all the key stakeholders and the development team representatives in order to discuss and evaluate the feature request and make a joint decision. You might even find that you need to run an experiment and collect relevant data, for instance, by interviewing users or releasing a feature fake, before you can make the decision.
Try to Find Common Ground, but Don’t Split the Difference
While saying no is sometimes unavoidable, I recommend that you explore if there is an alternative way to meet the stakeholder’s underlying need. Say that your suspicion turned out to be right: John’s request is, at least partly, motivated by the desire to meet his sales targets and claim a bonus.
If that’s the case, find out if you can help him achieve his goal without having to add the feature — assuming that you believe that it is right for you to help John pursue this goal. Would it be helpful, for example, to develop a sales pitch that shows that the product addresses some of the customer needs without providing the extra feature? Or is there another solution you can develop together with John?
Don’t make the mistake, though, to simply split the difference and suggest to John that you will partially implement the feature as part of the current release — unless this would actually meet John’s underlying need and not sacrifice sustainable pace for the development team.
Do what is necessary to maximise the value your product creates but don’t attempt to please individual stakeholders. Be kind and firm. Remember: Successful products are not built on weak compromises or the smallest common denominator.
Learn More
You can learn more about leading stakeholders by attending my product leadership workshop, which is also available online, and by reading my book How to Lead in Product Management.
