Saying “no” is one of a product manager’s most challenging responsibilities. And it’s something all product managers should be saying a lot.
Here’s a typical situation for product managers:
You fire up Slack and see a DM waiting for you from a salesperson like this. “If we just add this extra capability, I’ll finally be able to close that deal with Company X.”
Your stomach does a flip as you think, “Here we go again,” as you reply, “Hey, thanks for the feedback. Let me take a look, and I’ll get back to you.” Then, you avoid them for as long as possible.
So many product managers worry about disappointing their stakeholders. They do a little dance around the subject to avoid saying no.
“I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying ‘no’ to 1,000 things.”Steve Jobs
The reality is that you are juggling finite resources to deliver your product in a timely fashion. You have to make the best decision about what to build (and when you can deliver it) based on your resources.
Not only is it critical to be willing and able to say ‘no,’ but it’s essential to do so quickly and decisively.
Why should you be ruthless about saying no? Because when those requests and ideas sit on a list somewhere without taking any action whatsoever, bad things happen.
When you fail to say no and don’t manage your stakeholders effectively, you lose trust and credibility. These are two essential traits for product managers.
You lose trust with your stakeholders because they don’t see you as someone who takes their feedback seriously.
You lose credibility with your team because they see you tossing more ideas onto the backlog without vetting them.
Your boss loses faith in you because stakeholders ask her why you haven’t done anything with their idea.
Let’s discuss how you can say NO effectively. How do you reject someone respectfully? How do you turn them down without making things awkward or seeming adversarial?
Here is my 5-step process for saying no when you’re a product manager:
Step 1: Create a dialog
When you are presented with an idea or feature request, spend a few minutes talking (and, more importantly, listening) to the person to understand their idea.
Try not to make assumptions, pay attention, and repeat what they’ve said to show that you are listening.
Making them feel heard will build trust and goodwill.
Step 2: Show them how you prioritize
Help stakeholders understand how you and your team make prioritization decisions. If you haven’t already done so, document the framework you use to make product decisions.
Walk them through your process. Show them how their idea fits in using this process. At this point, they may realize that their idea is not viable.
This is an excellent opportunity to reinforce the product strategy and focus areas.
Step 3: Look for the value
Ask questions to determine the potential value of their request. Try to quantify the value with actual data. If necessary, suggest you or they do some additional homework to get the data.
Step 4: Describe the cost
Help them understand the price associated with their idea. The effort needed to implement those ideas is often enough to help them understand that the concept isn’t viable.
Sometimes you’ll need to help them understand the things your team would have to stop doing to focus on this idea. Whatever the expense associated with their idea, help them understand the rationale.
Step 5: Just say no
This is the hard part, but if you’ve done steps 1-3 correctly, the person making the request will likely realize the futility of their idea on their own.
If they continue to press the idea, use data to back up your decision.
Here are some suggestions for how to diplomatically say no:
“Thank you for the idea. Unfortunately, our product roadmap and development schedule are locked in place for the immediate future. I’ll place it in our idea parking lot so that we can revisit it another time.”
“Our research has told us that this type of idea could cause usability/technical feasibility/etc issues. It’s just not something we can do at this time.
“This isn’t aligned with our product strategy and area of focus for the quarter.”
I’ll share one final tip on how to say no. Get in the habit of documenting what you are saying NO to in a place where others can see them. This can be an appendix to your roadmap or a section of a wiki page you’ve created to summarize a new project or set of features you’re working on.
Being transparent about what your team will NOT do and WHY you are saying NO to those things will reduce ambiguity throughout your organization. It will help you build trust and credibility with your team, stakeholders, and boss.