To learn more about post-purchase sentiment, I decided to engage with our Customer Success team and become more aware of where our users were struggling.
I will admit that my Product team and I tend to spend more time interviewing and talking with amicable customers. That is not to say that we only approach our happy users; in fact, a fair number of the research-oriented conversations have been tempestuous. Indeed, through our collective research efforts over the past year, we have collected quite a bit of product feedback that would land well on the other side of "needs improvement".
But in this exercise, I wanted to turn my attention specifically to customers who were in peril. And I wanted to go straight to the front lines.
What drove this decision
In addition to what we were learning from the interviews we had been conducting with customers and prospects around new features and enhancements, I also wanted to know more about our product's pain points. And I thought that a great way to do that was to talk with customers who were currently lodging their complaints with our Support team.
The decision: Carve out time to listen to and understand some of the problems customers were having with our product and to help identify ways to address each distinct concern.
In span of a single week, I was able to participate in three separate support cases. I got a chance to hear, in some cases first-hand, from customers who had legitimate complaints about:
- An unacceptable implementation scenario
- An (unintentional) product feature gap
- A grueling Administrator on-boarding experience
These scenarios afforded me with a good cross-section of problems to explore. One was griping about our product's inability to satisfy their complex security problem. Another had caught a change we had made in a recent release that legitimately "broke" one of their use cases. And a third was trudging through our formal training course and was beginning to grasp all that he would ultimately have to learn to support his own company's solution.
Plan of attack
I was intrigued to have three customers with three very different concerns. My process for each was similar however. I spoke with Customer Success person who was interfacing directly with the users, tried my best to assess the particular situation and made sure I understood each customer's own challenge.
In the end, I helped to resolve each situation but with three very different outcomes.
Scenario 1 - "Fire" a customer for which there was truly no fit
My first conversation revolved around a newer customer who had been planning to go live with their implementation in the next few weeks. In working through their initial project, however, they had determined that they needed a much more sophisticated security scheme and were now struggling with that part of our platform.
It did not take me long to recognize we were at an impasse.
Somewhere along the way, we had clearly misled this particular customer. We had since exhausted all the obvious and even more creative options and I confirmed that we would not be otherwise enhancing the product to support their unique use case.
It did not take me long to recognize we were at an impasse. Looking to quickly resolve the situation, we made the tough decision to rip up the customer's contract and return their money.
Scenario 2 - Escalate a support ticket regarding a product oversight
My next conversation was much different. Here a long-time customer had submitted a complaint with our Support team about a small feature that was removed in a recent product release. It was clear to me that we screwed up.
It was clear to me that we had screwed up.
After hearing their scenario, I agreed and admitted that we had inadvertently taken away a small piece of functionality that they had been relying on. I recommended that we escalate the Support ticket to trigger a feature enhancement request that would bring back comparable functionality to help restore their solution.
Scenario 3 - Meet face-to-face with an overwrought Administrator
And finally, toward the end of the week, I was made aware of another new customer who had been floundering a bit. The designated "administrator" at this company, who was in charge of making it all work was currently enrolled in our (highly recommended) training class to learn the ins and outs of our software but was laboring under the breadth and depth of the course material.
In truth, the original implementation project was poorly scoped and was running over budget. It was clear that more time would be needed to complete the work. But the Administrator was becoming even more unsure about his ability to ultimately support his own company's users when the solution was finally deployed.
I scheduled an hour meeting with him after the training class (we actually talked for more than 90 minutes) and listened to his concerns. After some healthy venting, he ultimately agreed that none of his immediate doubts were tied to the platform itself. Instead we decided to revisit the original statement of work and work with Sales and Professional Services to properly expand the scope of the project to fit his organization's needs.
The impact
Looking back, I am not sure if my products are better off as a result of these interactions. At the end of the week, I had been engaged in three unique customer scenarios and delivered three different resolutions:
- Defend the product, even if it meant losing revenue and risking our reputation
- Admit our product mistakes and try to earn back the customer's trust
- Reset a (new) customer's product expectations and help them find a successful path forward
Look for more reports from theProductPath around customer research, product validation, and voice of the customer here on PM Decisions.
In a dauntless attempt to answer the near ubiquitous question, "What does a Product Manager do?", I decided to dedicate an entire year to recording and sharing my own journey down the product path.
The Product Decision: Contribute to the growing body of knowledge by sharing weekly accounts of my on-the-job product experiences as the Head of Product for a late stage startup.