How do you keep saying "NO" the right way that does not make the receiver frustrated?
The ability to say "NO" is one of the open secrets to being a successful product manager. Many time, people who suggest ideas are your company stakeholders, investor or hold the "C" level title. So, how can you keep doing it right?
Product manager act as a gatekeeper to prevent wasting time and money by building something that does not bring value. Before we go down further about how to say "no", we need to be explicit about why we say no.
- We didn't say "no" because we are lazy.
- We didn't say "no" because we are overwork.
- We didn't say "no" without validating it.
- We didn't say "no" just because of a tight timeline.
- and more importantly, We didn't say "no" just because we are a "no" addict!
We say "NO" because we want to build a great product. A product that solves the underlying problem and brings value to its users
Saying "NO" by validation
This is by far the most commonly used tactics. We back up our statement by providing quantitative and qualitative data. We look at the metrics and different funnel setup in the product. We conduct user interview, gather feedback and even build a mini prototype to test our hypothesis.
Very often, the idea turns out to be not worth pursuing. We go back to the meeting table to report our finding. We do our best to word it in a way not to be personal and hurt other feelings.
It usually ends with something like this: "As much as we like this idea and hope to start working on it, our finding seems to prove otherwise." We then back it up with the whatever we have gathered.
Saying "NO" by prioritisation
In a startup, product manager and the team we work with are usually overloaded with tasks. Most teams have enough tasks to fill more than sprint more than a quarter ahead. It is extremely difficult to validate every idea like what we do above. Therefore, we prioritize. We provide a rough estimate of how long this feature is going to take. We then guesstimate the commercial values it can possibly bring before finally decide if it worth pursuing.
We then go back to the table and state: "This idea seems really good to have, but commercially, it does not bring much value. Therefore, the effort and time needed do not justify us to build this feature at the moment."
This usually works best to separate the "good to have" ideas vs the commercially "must have" ideas. We also prevent time wasted on validating an idea that is not commercially feasible to build. Do note that, these ideas are not validated yet, therefore even if they seem to make sense commercially, we still need to validate the problems and if the solution really solve the problem.
Saying "NO" by providing an alternative
We only use this when the ideas/solutions are trying to address a real problem. During the validation phrases, we can confirm the problem that the users face. However, when the solution doesn't seem to be receptive, we should look at an alternative instead of just saying "no".
"After validation, we can confirm that this idea X is addressing a real user problem. However, X would need some modification as users don't seem to understand how it works. Perhaps we can try Y instead."
Sometimes, mix result could be produce by the validation. If we decide to pursue the idea, we can also build a scaled down version of it. This would help solves the problem of overcommitting resources to build something that no users wanted.
Saying "NO" by saying "YES"
Despite all the above, it is still difficult to say "no" to a stakeholder who you said "no" to for the umpteen time, especially during a meeting. Even though, we know that is 100% not personal, it can start to feel like it to the receiver. Therefore, we say "yes". However, we shouldn't be saying "yes" to the executing or taking on new tasks immediately. We say "yes" to thank him for his effort in trying to make the product better. I usually do this on a meeting that evolves many people.
"Thanks for your suggestion. I agreed that the product can be better than what it is now. Let's discuss later to see how we can potentially validate it".
Despite already knowing the metrics or validation test we run that this idea will not work, I take it off the meeting so we can discuss in a better place. I make sure to follow up with the stakeholders and show him my finding. More often than not, they are receptive of the effort.
There is no silver-bullet approach to saying "no". All product manager needs to know is that we are saying "no" because we want the product to be better than it was yesterday. On the opposite, we didn't say "yes" because it was an idea by the CEO. We didn't say "yes" because it is easier to end the conversation. We say "yes" only because we feel that it will make the product better.
Thanks for reading! If you like it, please hold 👏
I am a technical product lead at Milieu Insight. At night, I am a maker, engineer, and designer. I enjoy learning and building new things about tech, products, and startup. You can find me on my blog or Twitter.