The PM's guide to Saying *NO*

And how to decline requests

As a new Product Manager, one of the hardest things for me used to be saying “No” to things. I’ve always found it extremely difficult, and after so many years, sometimes still do.

Back in the day, when I tried to reason why this is so, I generally attributed it to my Indian upbringing—where saying NO is generally considered rude and sometimes downright hostile.

But then as I traveled, studied, made friends, and worked across geographies— I realized it’s not just me. In fact, our aversion to saying and/or listening to a NO is much more a function of the normal human condition than it is of a particular geography or culture.

Why we dislike saying No?

In my observation, our aversion to saying “NO” to things stems from the same things that make us human.

  • We like to be liked” If I say no, people might dislike me, avoid me from a group and I will make them unhappy”

  • We fear authority - “How can I say no to my boss? To my customers?”

  • We feel responsible- “ He / She needs help, its hard for me to say “NO”?

  • We don’t know how to do it - “I simply don’t know how to say NO.”

All of these are completely normal and valid concerns. After all, It is certainly possible that people will be unhappy with us if we decline their requests. And yet, the benefits of saying NO far outweigh these costs.

In fact, saying NO the right way affords you tremendous self-respect, helps you focus on what’s important, and raises your overall stature amongst your peers.

And believe it or not, sometimes the key to saying NO successfully is to not say NO at all. This is a big topic that I can rant about for a long time, but let’s put some context around this for the rest of this post.

Saying NO is key to building products

I consider Saying NO as a life skill that we must all learn— but for this post, I will simply focus on the tremendous benefits it brings to people who build and manage products. For discussion purposes, lets take the Product Manager role.

You see, the role of a PM is highly cross-functional. You juggle multiple stakeholders and bring everyone together to build a great product. On any given day, you may be interacting with any number of functional stakeholders in the graphic below.

Typically in product-centric companies, each function will have its own ideas about the product, how it should be built, what will make it better, what features are needed, etc.

The same is true with customers. Many engaged customers and power users love to provide feedback to the product manager—asking for new features that will benefit them do their jobs even better.

(Let me first qualify that this is largely a good thing —after all, we all want engaged, passionate teams that deeply care about the product? We all want customers who are die hard evangelists ? )

But with all that passion, comes lots of emotion.

We are all emotionally connected to our thoughts and ideas. We don’t like our ideas to be dismissed.

If you serve as the Product Manager, you’ll invariably get lots of ideas and opinions from the team and from your customers. And in a truly Product led business, decisions such as whether or not to build a certain feature and/or where a certain request will sit in the backlog rests with the Product Manager. In the course of making these decisions, you will have to wade through low-quality ideas and heck even say NO to many good ideas to get to the great ones.

This puts a PM into an interesting position.

How do you say NO without burning bridges? without making your customers upset? without frustrating your team if their suggestions don’t make it to the product?

Lets focus on customers. How do you say No to them?

Talking about not listening to your customers reeks of Product Management blasphemy, but its not. Here are some tips.

When a customer calls in with a request

For any business, a customer is sacred, a paying customer even more so. What do you do when a customer calls you requesting a feature?

Here’s a framework I recommend.

  • Listen to understand their problem: PM101 - When a customer calls, drop everything else and listen to what they are saying. If the customer is calling with a feature request, your job is to understand their underlying need.

    What is it that they are really trying to solve? Use the 5 WHY framework to get to the bottom of it. Ask follow up questions if you aren’t sure what the customer is asking for.

    “I am not quite sure if I understand what you mean, could you clarify…….”

    It’s often very tempting to simply build the feature that the customer is asking for —but resist that urge. Don’t commit to doing anything just yet. Remember that while it’s your job to build solutions to customer problems, not all problems are created equal.

  • Determine the underlying need: As you understand the problem better, reframe it and simplify to articulate it back to the customer.

    You can say - “If I understand you correctly you’d like to……” or “To make sure we are on the same page, could you confirm my understanding?”

    This does 2 things — (1) gives you a very good handle on the problem statement and (2) the customer feels your demonstrated empathy in fully grasping their problem.

  • Is this problem localized? Next, try to determine if the problem is unique to this customer or is it potentially an issue that a broader segment of your customer base is experiencing? You should be able to validate this through your ongoing customer support tickets and/or through other customer feedback channels.

    If it is indeed something that comes up often, then it perhaps needs to be addressed in a future release. On the other hand, if you find that this specific customer request will only help them / a few customers and add no value for the vast majority of your customer base — this is where you need to start thinking about how to respond to the customer. Yay or Nay?

As you’d imagine, getting back to customers with a “YES” is the easy part.

But what if the answer is NO? Maybe after careful consideration, your team has determined that the cost of building such a feature is too high compared to the benefits it’ll deliver. Or perhaps, your VP of Product determines that the customer’s feature request isn’t aligned with the overall vision and strategy of the company?

Now you have the sensitive job of communicating the decision to the customer, and they might not like it.

How to say “NO” to Customers, politely.

Here are some of the best practices that I recommend when you’re delivering negative news to customers.

Plan your response

Anticipate the response you’ll get from the customer when you give them the bad news and plan your response accordingly. Be prepared to explain your rationale patiently but firmly.

The good news is that most customers would understand that not every wishlist of theirs will turn into reality, but then when you are a paying customer the least you expect is to be heard.

1. Begin with Empathy

Genuine Empathy with your customer’s situation will help you say “NO” without burning bridges. Use phrases such as “I understand”, “I agree” , “I am aware of the issues” to remind the customer that you understand their request.

This helps guide the conversation into a more amicable territory, and its easier to deliver unpleasant news.

2. Be assertive and clear

One of the worst things you can do is to say “YES” when you really don’t mean it.

This is bad for both parties— you just took on something that you don’t have the time or bandwidth for—but more importantly— you’ve given the customer false hopes and made things more difficult. Not good.

Instead, be assertive and clear. Let customers know the reality of the situation as it stands. For instance, say something assertive, yet palatable.

“Unfortunately, there is no plan to implement this feature in the foreseeable future. But if things change we will be sure to let you know. Thanks so much for reaching out!”

3. It’s a feature, not a bug

Sometimes customers will ask you for features that you might have deprioritized or dropped from your roadmap already.

If the reasons were strategic/confidential of course you cannot divulge them —but if it were things like Privacy, confidentiality, regulatory compliances, etc. you can use these situations to your advantage to politely decline requests.

For instance: If a customer calls you and says “I want to download my chat conversations in the app but I can’t do it. I really need this feature so I can keep them for my records”

You can say something like: “For security and privacy reasons we do not store transcripts on our servers, but we send them directly to the email we have on account. Protecting customer data is key for us”.

Bottom line

Before you respond to a customer’s request whether in an affirmative or a negative, make sure you have evaluated and understood their request totally and genuinely. Make sure you have demonstrated to them that you care about their problem. In most cases, unless the request is something you absolutely cannot entertain, try not to respond immediately —instead promise to get back to them in a reasonable and finite amount of time.

I’ll leave you with my favorite quote from Sir Richard Branson ( and this is the only one that I like from Mr. Branson)

“Set realistic expectations with your customer, and then constantly exceed expectations—preferably in unexpected and helpful ways”

I hope you enjoyed this post. You can follow me on Twitter where I share learnings on managing and building products.

👋 Thanks for reading!