Saying “No” to customers, with empathy

Banner image, where the title reads "Say no with empathy"

Like many customers, I don’t like it when businesses say “No” to me, but I recently found myself on the giving end of that “No”. It was a new experience for me.

As you may know from my blog, one of the products I own at Microsoft is an internal wiki platform for enterprise documentation. This wiki platform is so successful for our target org that engineers from other orgs have reached out asking us to setup the same platform for them. Well, we do that; in fact we already offer “wiki-as-a-service” to a few other orgs in Microsoft, saving them time and effort of re-inventing the wheel for documentation.

Recently, many teams contacted my team, asking to be customers of this “WAAS” solution. This testimony of how successful my product is made me more worried than excited. Why? Because the existing wikis cost too much effort to set up: we are talking about days of work to evaluate business case, establish customer responsibilities, set up the new site and migrate any existing content, before a new managed wiki site can be created. My team could barely afford that for the existing customers, and intaking more customers under this service model will definitely sap our support bandwidth in the long-term.

I started working on revising our service model, and decided that because of resource limitation we must prioritize the service requests we get based on our product’s business goal. Among other things, I created a self-evaluation tool to help potential customers find out if we can support them. Baked into this self-evaluation tool is a set of “criteria” that the potential customer must meet before we start servicing them, and those “criteria” are made based on the core business values my team drives for in Microsoft.

Then the hard part (for me) came: based on the results of the evaluations, I had to tell some potential customer groups, “Sorry, but we can’t service you yet.” I didn’t look forward to doing that. I always feel a PM is here to serve, so the idea of turning down service request felt strange, even though I knew very clearly it was justified as I didn’t have the resource to serve every request. Fortunately, because the situation we face are clearly explained in the self-evaluation tool, most customers showed tremendous understanding when they arrived at the “No”. But of course, some were unhappy, and expressed doubt in my new customer criteria. To them, instead of getting defensive of my work, I decided to completely acknowledge their frustration; instead of repeatedly explaining the reason behind the criteria, I worked with them to build stronger business cases. For example, there was a group who were very frustrated that I turned down their request because their documentation user base was way below the prescribed minimum. I apologized to them, expressed understanding of their frustration, and suggested some methods for them to join forces with other groups to form a bigger wiki user base. These efforts addressed potential customers’ disappointment and helped some of them become impactful “WAAS” customers.

Here are what I learned about saying “No” to customers that helped both me and my customers:

  • Use empathy to acknowledge and take responsibility for the frustration caused by this “No”. No matter how justified that “No” is, it is a word that will cause frustration to some degree.
  • But also, be politely firm about that “No”. There was a reason that I couldn’t service every potential customer, and that message needs to be clearly communicated.
  • Explain the reason clearly, with context. Customers deserve to know “why”, and it should be communicated with context. For example, saying “we won’t accomodate your v3.0 feature request because it will take 10 days to complete” doesn’t provide context, but adding “and we only have another week until v3.0 code complete” can be more helpful.
  • Practice customer-obsession and offer to help in alternative ways. Although I wasn’t able to service all customer requests due to resource limitation, this way customers are still treated as a priority, and you may just discover alternative solutions that solves their problem — after all, isn’t problem-solving what a PM does? 🙂
  • Finally, embrace growth mindset and take this “No” as an opportunity to identify growth area in your product. For my team, having to turn down customer requests due to resource limitation was a clear signal that our process could be too heavy, which indicates shining opportunity for infrastructure and workflow improvement.