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.
Listen to this article:
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?
You can also access the content of this article on my YouTube channel.
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.
Post a Comment or Ask a Question
The last sentence has me thinking about how Product Management methodologies, particularly the Product Owner role, would scale- and translate to the governance of democratic countries.
Perhaps we could be structured equivalent to a company with a portfolio of services and products? In a way, we have that with Ministers and social administrations. But it seems that way too often decisions are a majority vote — without sufficient expertise — or easily swayed by public opinion. How often do Politicians in power apply these principles and say no? Higher stakes and the four-year election period somewhat enforces short-term thinking, but still. What if the governance instead would be structured to identify different Target Groups user needs and connect them to clear goals?
The forever increasing complexity of the world we live in makes me think our systems and processes are no longer sufficient. Maybe combining Technocracy with management methodologies would be more effective.
Philosophical perspectives and rhetorical questions aside, do you think we could take these methodologies and principles from the IT and the business world and modify them to work on such scale?
Been a passive reader for many years. Thanks for the high-quality content you put out.
Hi Robert, Thank you for sharing your thoughts. I believe that effective leadership requires the ability to choose the right leadership style thereby taking into account the needs of the people present and the situation you are in. I write about this topic more in the article “How to Choose the Right Product Management Leadership Styles” and I discuss it in more detail in my book How to Lead in Product Management.
Hope this helps!
Hi again Roman. Thanks for your response and the link. However, I still wonder if you think that what you teach can be used to manage other things than services and products? Not just adapting leadership styles based on context. For example, if you got the chance to help decide how a country should be run, would you trust much of your current knowledge and Methodology to be transferrable to this much larger scale? Personally I think much of it is quite universal but curious to know if you have thought about it.
Hi Robert, You might find the book We the People: Consenting to a Deeper Democracy an interesting read. Hope this helps!
The thing that always stands out in my mind when dealing with this kind of thing, whether it’s stakeholders or other gatekeepers, is a combination of empathizing with them but not bending to help them meet what they want. Instead, I go for reframing and a lot of patience as much as possible.
If someone has the impulsive thought that I won’t be meeting their need(s), I’ve found that giving them a reframing and then waiting for them to organically soften their stance has given me the most effectiveness with the least amount of difficulty. This won’t work 100 times out of 100, but it’s like the 95/5 version of the Pareto principle in my experience.
Thank you for sharing your experience Brandon. It’s great to hear that reframing has worked well for you. I like that you mention patience, and I agree that to help people change their mind, we have to give them the necessary time.