A few weeks ago, a customer told me that my product is so good that he plans to stop using it.
A bit of context here: As you may know from my blog, I am the product owner of a wiki-as-a-service documentation web app at Microsoft. Our service offers multiple managed wiki sites to various orgs across Microsoft, with the same underlying infrastructure and features developed and maintained by me and my dev partners. If a team meets certain criteria, they can request us to setup a managed wiki for them.
This customer’s team has been using one of our wiki apps, a site shared by many teams, for over a year. Always been a happy customer, he reached out asking for a separate managed wiki app dedicated to his team. Unfortunately, his team did not meet the criteria and we therefore couldn’t justify the additional support cost that would come with each new separate site. Hearing that, he asked me:
“Ellery, your team’s product is really good. We really want to have a dedicated site of our own, so as to not share infrastructure with other teams. If you aren’t able to give us a site under your service model, could you guys teach us to copy your setup and we will maintain our own site outside of your offering? We got dev resources to do that if we have to!”
Of course. Always happy to help out a customer. But I also know that what the customer asks for is not always what may service them the best. In this case, I could sense a hint of frustration with this proposed alternative (the “if we have to”). So I set up a meeting, determined to first figure out why he asked before simply providing what was asked for. I could guess there was frustration with shared wikis that I was not aware of, and listening to frustrated customers is always a learning opportunity not to miss.
When we met, I first acknowledged his desire to learn about our setup and begin copying it, then I asked: “Please help me understand what you need. First of all, do you really want to take time to setup and maintain a web app, outside the scope of your job?” Not surprisingly, the answer was a very clear “No”. Then I segued into my burning question: “How come your team want a separate site so badly, that you are considering maintaining one of your own?”
He answered my question in much details. After discussing for a while, I uncovered the real pain point behind his request: sharing the same wiki site with other dozens, if not hundreds, of teams means content search is tricky. Although we had been working on improving search engine in our offering, it is still inevitable that his teammates will find other teams’ content with similar keywords. And even though we offer advanced search operators in our search engine, learning to use them is a burden for each of the hundreds of team members of his is not intuitive enough. “How would you feel if Google requires you to learn advanced search syntax before you can find anything meaningful?”
Aha, now the real pain point is exposed: it’s not “independence” they need (in fact, having that would cost unnecessary dev investment), but rather “easy discovery”. And of course, I could see this need exist not just for this one team, but many of the many teams sharing any of our wiki sites. This customer probably happened to experience the pain point most strongly, and that turned into an opportunity for me to discover this pain point. He, our dev lead and myself spent some more time brainstorming solutions to the discovery problem, and came up with a new feature that would allow users to intuitively search within a small scope of their choice, without typing complicated search syntax.
In hindsight, had I simply prescribed what the customer was asking for (how to copy our setup), I would still “get the job done”, but never would have come up with this solution that solves a problem more elegantly for him and many other customers; and he would have set up a site of his own, and forever lower his weekly bandwidth by a few hours because he needs to do extra web app DevOps work.
I would summarize my learning in this story as: Diagnose before Prescribe. Just like a physician wouldn’t hand out random prescriptions to patients before arriving at a diagnosis, a product manager should resist the temptation of taking the path of least resistance and “just do what the customer ask”. It is part of the job to understand the customer’s needs, and to do that, you need to tune in to beyond just customers’ words to crack what the customer is really saying.
This method comes from empathetic listening. In empathetic learning, someone’s words only make up a small portion of what they truly wish to communicate; the rest are radiated via tone, facial expression, body language, etc. By tuning in to “how they say it” in addition to “what they say”, you can uncover not just logic but also emotion — and attending to the speaker’s emotion helps you see a much bigger picture of what they really want to express, which leads to greater opportunity of success for both parties.
As mentioned in a previous article, I have been reading up on the works of Stephen Covey. One of the principles he evangelizes is called “Seek first to understand, then to be understood.” This principle focuses on empathetic listening, and I think my story shows that this is not just applicable to personal relationships, but also to the practice of product. Instead of simply preaching the reason my team won’t support a new tenant and let the customer run his own app with extra cost of his own (“to be understood”), I seeked to understand his needs first. The result was a third alternative that was better than simply “I got what I wanted” or “he got what he wanted”!