Saying “no” is one of the hardest things a product manager must do. And it’s something you, my dear product manager friend, should be saying a lot.
James Clear, the author of the bestselling book “Atomic Habits” recently spoke about the importance of saying “no.”
“When you say no, you are only saying no to one option. When you say yes, you are saying no to every other option.
No is a choice. Yes is a responsibility.”
Let that really sink in.
How many times have you been given a product idea or feature request and then responded with “We’ll put it on the backlog and consider it for an upcoming sprint.”
So many product managers worry about disappointing their stakeholders so they do a little dance around the subject to avoid saying no.
Not only is it critical to be willing and able to say ‘no’, but it’s important to do so quickly and decisively.
When I was working as a product manager for a start-up a few years ago, we had a team dinner one night and someone pointed out that I seem to really enjoy saying no and “killing people’s dreams.” Yes, I was called the dream crusher. I compared myself to Katniss Everdeen, oh so swift with a bow and arrow. You see, I would lock on to certain product ideas that threatened to derail the company and I would shoot those things down.
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. You lose trust with your stakeholders because they don’t see you as someone who takes their feedback seriously. You lose trust with your team because they see you tossing more ideas without vetting them onto the backlog where they most likely shrivel up and die. You lose trust with your boss because she will often end up being asked by your stakeholders why you haven’t done anything with their idea.
Here is my 4-step process for graciously saying no to feature requests:
- 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.
- Look for the value – ask questions to determine the potential value of their request. Try to quantify the value with real data. If necessary, suggest you or they do some additional homework to get the data.
- Describe the cost – help them understand the cost likely to be associated with their idea. Most often, the effort needed to implement those ideas is enough to help them understand the idea isn’t viable. Perhaps the idea would negatively impact the usability of your product. 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 that would be associated with their idea, help them understand the rationale behind it.
- Just say no – this is the hard part, but if you’ve done steps 1-3 properly, the person making the request will likely realize the futility of their idea on their own. But if they continue to press the idea, use data to back up your decision. I’ve found it can be also very useful to help stakeholders (and anyone who’s in a position to make feature requests) how prioritization decisions are made. If you haven’t already done so, document the framework you use to make product decisions.
Steve Jobs once said “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.”
What have you said ‘no’ to recently?