I went to visit a customer a few weeks ago as part of a commitment to myself (and my products) to get out into the field more often. My goal with them and with all of my planned visits to the field was to talk about how they use my product, what business challenges they face and what they see for the future in terms of their own growth and what they would want and need from my product. I got what I was looking for…and a whole lot more.
Unlike many of my colleagues in Product Management (at least in software Product Management and in the Silicon Valley), my educational background is not in Business, Marketing, or Engineering. Both my undergraduate and graduate work were in Psychology and Counseling Psychology. I didn’t learn a lot about financial models or the 4 P’s of Marketing or how to write Java code (though, I did learn about the Internet, primarily through it’s forebearer, Gopherspace), but I did learn the importance of listening.
One of the primary tenets of Psychology, be it clinical, research or counseling, is that you have to listen more than you talk. If you are working with experimental subjects, you have to listen and document their responses. If you are working as a Psychotherapist, you typically spend 40.5 of the 50 minutes of the “therapist hour” listening to your client. And not just listening to what they are saying, but listening for the hints and hidden messages behind what they are saying and deciphering their context and meaning, which is the key to successful talk therapy.
As a result, listening is a skill that was hammered into me repeatedly for 6 years and has come to be a valuable tool for me as a Product Manager. When talking with customers, prospects, Engineers, Salespeople, or the Executive team, I listen first. I make sure that I understand not only what is being said, but why it is being said, the context and whether there is or might be any sub-context (which is really just another way to say “reading-between-the-lines”). Once you start listening, you’ll realize that the person or people talking are giving you much more information than you originally thought.
Which brings me back to my original point about the customer meetings. As I mentioned earlier, I was just looking to get some very high-level information that I could normalize with all of the customers that I was planning to meet with. I had never met with this customer before, but had reviewed some of their past and current support tickets to get a cursory understanding of some of the issues that they faced. I had also talked with members of the Support team to get their view of what type of customer they were and the relationship that they had with our company.
Based on the preliminary data I had collected, I was prepared for a somewhat painful meeting with the customer. I didn’t think they were a very good fit with the characteristics of our “ideal” customer and the features they were asking for and the issues they brought up with Support were considered by me and others to be edge cases.
The original plan was for me and one of our founders and the VP of Engineering to visit this customer, but due to some last-minute scheduling conflicts, it ended up being just me. I thought about changing the meeting, but it had been hard to coordinate in the first place, so I decided to see it through. When I got there, however, and started talking with the team, my perceptions about them started to change.
First, after about 30 minutes, I had a better understanding of their business, which was considerably different than what I thought it was before the meeting. Having that understanding made many of their issues seem less like edge cases and put them more in line with some of the challenges that other customers might have. That gave me some ideas about how to tackle some of the challenges in the near-term and also what I would need to do in the future to address areas which I thought were well outside of our sweet spot, but now see as being more integral.
Another thing that happened was that while the meeting initially had a somewhat adversarial tone to it (we started the meeting by getting some of their issues out on the table, even though I had tried to steer the conversation away from that area), as I let them talk and asked only a few questions to spur the discussion, they started to discuss more about their vision and how they saw my product fitting in to that vision.
What I found was that they had many ideas on how to use my product that I hadn’t considered. They wanted to use my product in a way that it wasn’t currently being used, but that made a lot of sense when they spelled it out. It was an “A-ha!” moment for me.
Finally, through the discussion, I got insights into how another organization operates. What their processes are. How they build their product. What they spend their time and money on to increase success. What type of people they have on staff and in what roles.
It’s easy to become insulated in one’s own organization and I sometimes find that I limit myself to the same patterns of interaction and process that I have become accustomed to. Hearing the stories of this customer (and others) helps me to lift my head up from looking at my feet while I walk and take a fresh view of the world.
Plenty of Product Management texts and resources recommend talking to your customers in order to build better products, but there’s also a good possibility that just listening to customers can help build better products and better Product Managers.