Product Managers have to constantly make decisions. This means having to say ‘no’ a lot during the Product Development journey in order to prioritise the tasks that truly add the most value to the customer. With the Product team, you have finite resources to develop your product, and if someone wants you to add X to the roadmap, doing so will have to come at the expense of Y. It’s up to the Product Manager to evaluate whether or not the sacrifice is worth it based on value added and estimated results.
The following blog looks at out how to master the art of saying ‘no’ in a way that you can maintain positive relationships with your stakeholders, without compromising on delivery and quality.
Saying no feels difficult and uncomfortable. But why?
Well, even as children we are taught that saying no is disobedient or rude. And this learned behaviour is often carried with us through into our adult and professional lives. When you accept a new job in particular, you are keen to say ‘yes’ to everything, and will often spend extra time perfecting your work and going the extra mile. However, once you step into that Product Management role, you need to unlearn the habit of being a ‘yes person’, and quickly get comfortable saying ‘no’!
If you continue actioning everything that each one of your stakeholders says, you will end up building a product that is not going to solve any problems for your customer, because everyone will have different ideas, and ways to do things. By trying to please everybody, you’re going to end up creating a less valuable product, that has no clear direction or goal, and that doesn’t accurately align with the end goal or business vision.
Saying no is key to delivering true value to customers. But how do you say no without looking like a blocker?
This first step is almost like a precursor to your inevitable conversations in which you’re going to have to say no. To set yourself up for success you should ensure that you have an explicitly clear Product Mission, Vision, and Strategy, which aligns with the overall business mission, vision, and strategy. As part of this, you should be collating data on important KPIs which you can use to show the impact of your Product on those goals and targets. By having this to hand, you can pull on these data points to demonstrate why certain features and fixes are priority over other things, and can help you illustrate why, in some cases, you need to say no.
Even if you already know what the stakeholder is going to ask or suggest, never say ‘no’ too quickly or abruptly, and refrain from interrupting them. Allow them the time and space to outline their point and explain it, whilst using affirmative body language and by paraphrasing and repeating what has been said to show you are paying attention and have listened. It’s really important that you take the time to discuss and listen to stakeholder requests to demonstrate that you understand and empathise with them and their issue.
When you jump straight to rejection without giving legitimacy to your stakeholder’s request, you deprive that person of feeling heard, which is a fundamental characteristic of a collaborative and psychologically safe work environment. Despite saying ‘no’ you still need your stakeholders to continue to come to you with ideas in the future, and giving them time to discuss their ideas is a key way to maintain this safe space.
During the conversation, you should ask clarifying questions to ensure you understand the value the change would deliver, who will be affected by the change, and the problem it solves. You can then compare this to the overall Product and Business strategy and use key data points and KPIs to demonstrate how at the current time, the suggestion doesn’t currently align as well as other methods you are exploring. Be completely transparent with how you prioritise workload and take the time to explain cost vs ROI to them but be careful not to necessarily discard their ideas altogether. After all, their idea might be valuable later down the line. So, if a Stakeholder was to come to you with a suggestion to improve downloads, but you’re prioritising improving retention and reducing churn rate, you can soften your argument by saying something like:
“That’s a really strong idea, and one that we’re actually considered implementing to attract more customers and increase our downloads. When we came to look into this further, we collated some data and found that whilst we are already hitting a steady 500 downloads per week, our churn rate is really high, sitting at about 42%. Before we look at attracting new users, we want to make sure that our platform has high usability and is optimised to ensure we are retaining our users so that people who download the app, stay with us. XX% of our sales come from retained customers so it’s a really important area to focus on. Once we’ve identified the issues here and ran the necessary fixes, which should be by April, I’m happy to look into this with you again and put together a user attraction strategy.”
This clearly demonstrates that you have listened to their request, and you have explained, using data, why you can’t prioritise that request right now.
At the end of your conversation, you should recap your stakeholders key points, reiterate your reasoning, and then say no, and where applicable give a timeline of when you might be able to revisit the idea. The most important part of this is to then thank them for coming to you with the idea and reinforce that ideas are always welcome and considered. This encourages a collaborative and psychologically safe space where all ideas are listened to, and everyone has a voice. You don’t want to say ‘no’ and then make stakeholders feel like they shouldn’t contribute anything in the future.
In the words of Steve Jobs: “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the 100 other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done.”
The key point here is that saying ‘no’ is part of your job as a Product Manager and is fundamental to your role in prioritising the features, fixes and updates that will add the most value to your customers. It’s a hard lesson to learn that ‘it’s okay to say no’ but it is an important one.