This is part of a short series about the talk I gave at Product Camp Boston, entitled “Getting Better at Getting Better: A PM Kaizen.” A general introduction to the talk is here and you can view the slides.
The hardest thing for me as a PM has been to learn how to listen to customers, and when not to.
I know, I know. Customer centricity is a key tenet for growth, if you don’t listen to customers you die. But I’d argue that you can get yourself in real trouble if you listen to customers too much, or listen the wrong way.
Here’s the thing. Customers will tell you really important things about how your software works, or doesn’t work, for them. But sometimes you have to really dig for the key information. I can’t count the number of times that a customer request came into my email, passed along by a well-meaning co-worker, that when I dug in turned out to be a completely different issue.
The reason is that we all try to solve our own problems. Customers know their workflow better than anyone else, and so as they think about something that irks them about your software, they’ll consider lots of possible ways to solve the problem within what they understand to be the constraints, and discard the ones that won’t work for them. Then they’ll think of other problems and revise their solution, and ultimately pass along a solution that is so specific to their use case that it may actually not solve the problem for other customers, and may even create new problems.
So I tend to follow the rule of Five Whys. Because what is tremendously valuable is understanding the root cause, the underlying customer problem, that sparked the communication in the first place. Sometimes customers are inspired to identify good solutions, but often their understanding of the constraints, lack of knowledge of other features you have in your roadmap (or under development), or thought process constrained by their local environment results in partial workarounds that don’t solve the root issue.
So much for the microcosm of customer feature requests. What about your roadmap? Surely that should be customer centric?
Well, to a point. But you have to be keenly aware of who the customers are who are influencing your roadmap and who they represent—and what stage your product and your market are in. I find the Crossing the Chasm model helpful for understanding this part. A lead customer for a pre-chasm offering, or a mainstream customer for a post-chasm offering, can provide helpful feedback. But if you’re in the middle of a market disruption, listening only to your existing customers can be a recipe for disaster.
That goes double for when you get successful. Large software product teams get very good at listening to their existing customers, and miss out on the customer pain points that lead some prospects to choose other solutions. If you couple the crowded PM calendar with lots of feedback from existing customers, you can get into a trap of the Urgent Now and miss the signals that your market is shifting.
So how do you stay focused on longer term, bigger picture problems? How do you avoid being dragged into that tire fire in your inbox? It turns out that the tools you need to stay focused on the right things may be closer to hand than you think.