Why your product managers should support customers
(An extended version of this article can be found in our medium channel.)
In 2005, our CEO Girish Mathrubootham, then a Product Manager – came up with a concept to see how much of a difference he was making in his job. He called it the Moving Target Theory of Customer Support.
According to the Moving Target Theory, a customer always dictates when and where your solution isn’t working, every step of the way. If you see that most of your support queries are about something specific in your product, it automatically becomes your Primary Target. Until you take care of it, your team will not be able to make any progress by building more functionality.
For example, if most of your tickets are about users not being able to login to your app, you should focus on fixing the issue at hand – your primary target, and nothing else. Why? Because it gives you a clear indication of where your users are getting stuck. If they aren’t able to get past that point, there’s no point in working on a different area of the product.
According to Girish, every time you make changes to take care of the Primary target, your customers cross the hurdle and start pointing out the next problem in the product – which, in turn, becomes your next Primary Target. This is a recurring cycle and validates the fact that you are making progress with your updates.
If your primary target changes frequently then, as a PM, you are solving the right problems and your product is healthy.
Fast forward to 2015, and you can see that Girish’s 10-year old theory still holds true for most product companies. At Freshdesk, we were able to see that even today, the moving target helps us focus on solving our customer’s problems first before we build the next big thing in our product. It also showed us why it makes sense for Product Management and Customer Support to go hand in hand.
Product managers on support
PMs make a lot of assumptions when they build products, it is a part of their job. Sometimes, these assumptions seem 100% foolproof and look like the right thing to do from their perspective. But the truth is, not all the ideas that look great on paper are practically usable to customers. That’s why it’s critical for every product manager to not only understand what they are going after but also to make sure that their users aren’t looking at it differently.
The easiest way for them to do this is to get on supporting themselves. Over here at Freshdesk, our PMs frequently talk to customers in person and through phone calls. Last week, we caught up with some of them to understand what they’ve learned from doing this over the years, and why it matters.
a) Quantitative vs Qualitative data
A lot of research goes into a feature even before the first line of code is written. PMs collect a lot of quantitative data about the market, the competitors and customers…but quantitative data can only show you what the problem is. It cannot really tell you anything about why the problem occurred in the first place and how you should go about fixing it. Your best source for qualitative answers like this one is your customer. To really understand the problem, PMs should be talking to customers on a regular basis, put themselves in their shoes and make sure that they don’t restrict themselves to just one perspective.
b) Customer stories and use-cases
PMs shouldn’t just walk-in customers’ shoe day in and day out; they need to know customers’ problems better than the customer themselves.
This should be pretty easy if the PMs were average customers themselves, but when they’re not… the only way they can really get inside a customer’s head is by collecting stories and use-cases from existing customers. By doing this, they can ensure that they don’t just go by what a customer thinks is the right solution, and instead build something that is even better.
This also gives them a list of stories to come up with when they are pitching their product/features to customers.
c) The key to respect
A PM has to not only sell the feature to customers but they also have to convince engineers everyday that the feature they’re building is important and absolutely necessary. It isn’t easy to face a barrage of conflicting opinions – maybe they’d like this better, are you sure this is the best way to do it – and still stay firm on what you think is the right way to go about it.
Customer requests, thankfully, go a long way in endorsing a PM’s opinion. In fact, if you have revenue numbers to go with these requests, you can tell your engineering team exactly how much they’re worth to your business, and how much you stand to lose if it doesn’t get rolled out quickly. A PM who is in touch with customers regularly can justify his decisions and can make the engineer, and other peers, see the solution from the customer’s point of view.
d) Feature prioritisation
As much as PMs would like to fulfill a customer’s every wish, they cannot possibly build everything that comes their way. They have to weed out some requests, prioritize some over others and decide what goes into the product. And the best way to do this is by talking to customers.
While talking to the customer
PMs need to follow a few rules during these support/feedback sessions to make sure the conversation is beneficial for them and the customer:
- Learn the art of saying ‘No’. PMs should keep in mind that it’s always better to say ‘No’ than to make false promises.
- Do not make it into a numbers game. After a few conversations about the same feature to different customers, the value you get out of it diminishes. Never set a goal on the number of customers you should talk to.
- Do not manipulate the answers. Layout the topic of conversation and start listening. Make sure you are not trying to nudge the customer into saying things that will validate your assumptions.
- Manage time. Don’t get caught up in this requirement collection phase. Learn when to stop listening and start building.
A pinch of salt
There is such a thing as talking to too many customers. A PM should be focused on understanding the pain point rather than just fulfilling a customer’s every wish. A PM supporting customers has to make sure that she does not let customers drive the product. As Girish says “Respect the customer’s problem, ignore the suggested solution.”
An engineer, a support guy and a PM walk into a bar
The way a Product Manager talks to a customer is different from the way an engineer or a support agent talks to a customer. Engineers look to provide fixes. Support agents focus on making sure that customers don’t get frustrated.
PMs, however, are the only ones who can look at a problem and really figure out what might have caused it – whether it’s a product problem, a marketing problem or a sales problem.
And, unlike the other two, they actually have the power to fix it not just for the one customer but for everybody.
It’s not just a one-way street though. Customer support agents need to be empowered with the ability to look at a problem like a PM. They need to be given more incentive to dig deep into the problem rather than just dispatch “fixes”. They need more ways to communicate with PMs – be it through collaboration tools or weekly stand-up meetings.
To create a good product, it’s not enough if Product Managers are on support. Customer support should be on Product Management too.
This is the second in our All Hands on Support series. Find out why Developers and Salespeople should be on support too.
