Saying No is one of the essential skills of product management. Be it a customer, peers, execs or other stakeholders, how you say No has a big impact on both your effectiveness as a product manager as well as your own career velocity.
If you say Yes to everything, you are destined for failure because your products will likely be underwhelming and there is no clear prioritization framework for your team. If you say No a lot, chances are that you likely get a negative reputation built around you that will become even harder to overcome. (e.g. Jake is so hard to work with, `he never agrees to anything!)
Saying No is an essential skill and one that can actually strengthen your reputation as a strong product manager in the eyes of your teammates and the organization.
There are two distinct parts to saying No.
Making the assessment of the request
How to communicate the “unpleasant” decision
Assessing the request
Is the request solving the real problem?
The first thing to do is to understand the need behind the request. Often I will get a request from a stakeholder (e.g. sales) and the request is very specific. For example, “we need a UI control to turn this feature off”. It is really important as a product manager to shift the conversation from the “how” to the what and why. Often these stakeholders turn into product managers and provide specific feature requests because they are trying to be helpful.
The real need may be orthogonal - the customer wants a discount on a particular SKU and the sales rep can meet the customer price if they can turn off one of the features. So building the UI controls is not the real customer need.
Once you have identified the real request, you can then assess it objectively against your decision framework. Your reasons for saying No is likely because:
The data is not compelling. You see the request (e.g. request to permanently lower the price of a feature) as an anomaly and not a consistent trend. And in many cases, a workaround exists that while not efficient, gets the job done.
Goals misalignment. The request does not impact organizational goals (e.g. if adoption or revenue is the top goal in the org, then agreeing to this request does not further those goals)
Prioritization. The request makes a credible “why” argument but fails the “why now” test. You consider the request reasonable and aligned with long term goals but don’t see a need to change anything in your current backlog to accommodate the request.
A slippery slope is to say that this request passes both the “why” and “why now” test but the team needs “more resources”. I don’t know any team that didn’t want more resources! Savvy managers just respond with “I agree that you can’t do everything but let us figure out the right project to de-scope. Give me your list of projects you are funding, and I will help you stack rank this incoming request accordingly.” In other words, “let me do your job for you”
You don’t buy it - this gets more subjective where you have a hunch or hypothesis that the request is a bad idea. However it is your opinion vs someone else’s.
So you arrived at a decision. Now how do you communicate and make it stick?
2. Communicating the decision
Get manager and exec buy in. Walk your manager and key stakeholders on your framework and the decision. Ask them if they see a higher level escalation coming. For example, the request may be eclectic in nature but may be coming from one of your top 10 customers and retaining them is important to the organization. Depending on the sensitivity of the request, explicitly ask them to have your back.
Prioritize for quick responses vs long maybes. Seasoned folks respect folks that provide a quick yes or no, vs a long maybe. Think back about all those times when you chased something and you didn’t get a clear response. You were left with hope that things will pan out, you spent time and energy on it thinking you will influence the outcome, only to realize, much later, that the answer is a No. More importantly, there was nothing new that was discovered to get to No. If you know you are going to turn down the request, don’t delay it.
Using Principles. Communicate your decision using a principle based approach. Sharing the framework helps the other side point out inconsistencies in your framework or something you may have missed. Alternatively, they see that the decision was fairly evaluated because they cannot disagree with the principles.
Offer paths to favorable resolution. If the requesting team has been seeing their requests declined frequently, you might need to offer additional options especially if you agree with the request and disagree on the timelines.
For example, if the ask was reasonable but fell low on your prioritization list, you can ask the team to contribute resources to expedite the backlog.
Depending on the culture of the organization, you can invite the stakeholder to escalate to move other priorities around. We have an incredibly open culture at Google, and we have an escalation manifesto authored by a very senior exec to help us do precisely that. Escalations can be very effective when they are focused on solving the problem and do not blame the individuals involved, creating the necessary psychological safety for everyone involved.
Be nice! Finally, remember the cardinal rule - “mean what you say, say what you mean and don’t be mean when you say it!”
Those are some effective steps you can implement today to be a more effective product manager. Please feel free to leave a comment with any feedback or additional tips you may have!
If you liked reading this, consider signing up for career coaching. Schedule a complimentary consultation with me to discuss how I can help you accelerate your career.