3 Tactics for saying ‘No’ as a product manager
During my engineering days, I served as the secretary of the Computer Society of India (CSI). In a CSI event planning meeting, one of my seniors advised me, “Shreyas, you should learn to say ‘No’. I always see you pick every task others ask you to do. If a task doesn’t align with your goals, then don’t accept it — As the CSI secretary, your role is to focus on high-priority tasks, helping the community grow. You should delegate tasks that are not creating a significant impact.” She explained that we tend to spend more time working on smaller tasks instead of prioritizing critical ones and delegating to others.
Fast forward 12 years, and that lesson is the most valuable lesson for me as a product manager (PM). As a PM, your time is precious. You have many tasks to juggle and not much time to execute them. Lack of bandwidth could put you in a difficult position when a new task comes your way that is not aligned with your goals. Saying ‘No’ can be tricky, but there are ways to do it effectively. Here are three tactics to say ‘No’ without damaging your relationship with stakeholders:
- Ask more questions and frame your conversation
- Back up your ‘No’ with data
- Saying ‘No’ by saying ‘Yes’
Ask more questions and frame your conversation
As a PM, you should always ask stakeholders for context and examples to better understand their requests. Asking the right questions will help you prioritize tasks. You want to understand stakeholders’ outcomes rather than output. When you dive deep into their request by asking pertinent questions, you empathize with their pain points and understand what they are looking for. For example, at Spocket, the supplier acquisition team was looking for order management metrics, and they requested a graph from the Data team. This graph will show the number of unfulfilled orders per day (number of unfulfilled orders/total orders received). When I asked them clarifying questions, they explained that they were looking for suppliers with a maximum ratio of unfilled orders to total orders. So they were looking for specific suppliers with unfulfilled orders instead of total unfulfilled orders. It turned out that they wanted to follow up with these suppliers and process orders ASAP. Their KPI was to improve order processing, and currently, they did not know any information on the number of unfulfilled orders per supplier. If I had built their request, I would have wasted the engineering, product and supplier team’s time without achieving the ideal outcome my stakeholders were looking for.
I asked them questions such as
- Why are you looking for this information?
- What do you want to do if I give you this information?
- What are you not able to do when you don’t have this information?
- What is your end goal, and How will you achieve it?
By asking these questions, I was able to frame my conversation and help them identify what they needed. In 95% of the cases, it does not make sense to prioritize stakeholders’ requests without asking them clarification questions because their outcome is different than what they are looking for. Usually, I use the Five Ws framework to come up with clarification questions that uncover the right outcome.
Back up your ‘No’ with data
Saying ‘No’ by leveraging data is the most commonly used tactic in product organizations. PMs can back their statements or opinions with quantitative and qualitative data. Instead of saying a direct ‘No’ to your stakeholders, demonstrate the data you collected, walkthrough cost and benefit analysis or share customer anecdotes collected during customer interviews. I often find that an idea or request coming from a stakeholder isn’t worth pursuing after conducting user interviews; however, you don’t want to reject any ideas or problems right away. You want to validate every opportunity to grow your business. In general, conversations with customers allow you to continuously validate problems or ideas before you start working on them. The above tactics project that you acknowledged stakeholders’ efforts and feedback. You collected the necessary inputs to make better decisions for business and your ‘No’ is not a personal opinion but more in line with business priorities. Another technique I used to influence my stakeholders is to explain the reason behind decision-making. Saying ‘No’ can be difficult; however, showing appreciation to your stakeholder could go a long way! Thus, you want to say ‘No’ but do not forget to thank them. In the end, you want to build a strong partnership with stakeholders.
Saying ‘No’ by saying ‘Yes’
Sometimes it is still difficult to say ‘No’ despite using the above tactics. Though we know our ‘No’ is not at all personal, we fail to communicate the right rationale to our stakeholders and end up hurting their feelings. Especially during large meetings, it is often difficult to say ‘No’ to stakeholders. Furthermore, if a request comes from someone with a higher title, then decision-making dynamics completely change, and we feel we don’t have a choice to say “No,” so we end up saying ‘Yes’.
Sometimes stakeholders act like they are personally offended by a decision, which leads us to say ‘Yes’ as we want to continue to collaborate with them.
In that case, how should we handle critical situations when someone is asking us to accept their request? In general, we shouldn’t be saying ‘Yes’ to all requests or taking on new tasks immediately. We want to acknowledge and thank stakeholders for their effort to make the product better. We want to acknowledge that the product can be better than it is now and schedule a 1:1 conversation to learn more about their request. Ask them relevant questions and validate their request as discussed in tactic 1 (Ask more questions and frame your conversation). Show them data and insights you discovered and more often than not, they are receptive to the effort.
Conclusion
Knowing how and when to say ‘No’ is essential to becoming an effective product manager. Communicating a clear ‘No’ without hurting your stakeholders will help you focus on priorities while maintaining strong relationships. Saying ‘No’ will also help you to take control of your priorities and identify needle-moving projects. Thus, using the above three tactics, you can start saying ‘No’ in a way that will benefit you, the product, and the team. Have you tried any of these tactics? What has been your experience? I would love to hear from you.
Originally published at Product Management — An Organization Locus.
