Clearworks Conversations: The Role of Customer Research in Product Management
Our Clearworks Conversations Blog Series features interviews with leaders who we feel have a unique perspective to share. In this blog post, Clearworks’ Noël Adams interviews Rich Mironov, a 35-year veteran of Silicon Valley tech companies who coaches product executives and parachutes into companies as the interim VP of Product Management. He was the ‘product guy’ or CEO at six start-ups. In the interview Rich shares why customer research is “absolutely essential” for product teams
Noël: What role should customer research play in product management?
Rich: For me it [customer research] is absolutely essential. In some of the old-style product management we thought we were just about getting stuff shipped. I have been on the podium now for two decades pushing the thought that we should really be shipping things that customers want to buy, solve real problems, and are economically viable. We cannot figure that out by staring at each other, contemplating our navels or talking to our engineers. So if we are not doing customer research, honestly I don’t know what the product management function is about. We are just handmaidens to the engineering team if all we are doing is writing specs that we don’t know are any good.
Noël: In your experience do product teams do a good job with customer research and if not, why not?
Rich: I think customer research is really hard and a lot of product teams are not particularly well trained on it. They don’t know how to do customer research and they are afraid of it. It’s intimidating. So let’s think about what works well and then some of the failures modes. I want every single product person on my team to have a call at least once a week with a real user or a real prospect or a real buyer. Starting with open-ended where they learn things, where they shut up and let customers talk and tell us what they think – and definitionally happens outside of the sales cycle. When we are selling, when sales reps pull us into calls or meetings with customers — we know that is a sales call and our job is not to raise lots of complicated issues or ask about the future or show prototypes that we haven’t decided to build. Our job then is to help close and brings money in, but it doesn’t fulfill the research goal of actually learning anything. Everybody on my team should have one call a week with somebody who really uses or might use our stuff so we develop some taste about what is important and we gather enough data that when somebody tells us something that is wrong we can look at the last fifteen or thirty calls and figure out whether it is our misunderstanding or somebody else’s.
Noël: Other than not doing research at all or trying to turn a sales call into a research call what are some of the other missteps you have seen some teams make?
Rich: I see a lot of folks who aren’t used to research instead pitching their products. They are using a customer call to spend most of the airtime talking about what their products do, sharing the roadmap, explaining why the product is good or the price is good and then asking the person at the other end whether they agree. It is a classic problem: at that point our interviewees just want to get off the phone and they will tell you anything to escape. So they get off that call and we haven’t learned very much. All we have learned is that somebody is polite enough to tell you that they think your good idea is good as opposed to the deep open-ended dig dig dig: “tell me more…”, “what I hear you saying is…” – the classic interview techniques that Clearworks do so well.
Other things I see that don’t go well: We let our sales teams do our research for us. Salespeople talk to customers all the time and tell us: “ you [product managers] don’t need to talk to customers because we {sales} are doing it for you”, and that misses the point that the sales job isn’t the research job. It is the job of getting somebody at the other end of the phone to agree to send money. Sales people have a very good set of skills around leading the discussion and putting evidence out and push, push, pushing, but again it doesn’t lead to learning. It leads to either dropping them off the phone or closing the deal.
Then probably the last thing for me is very small sample size. It is really easy to talk to one user, customer, or prospect and decide you understand your market — and usually that one interview is an outlier of some kind. I would tell my folks that if they haven’t talked to ten or twelve or fifteen users/customers/prospects that maybe it is too early to draw some conclusions.
Noël: Conversely, what have you seen work really well for teams who are trying to engage customers in research?
Rich: I think there is some infrastructure to put in place. For instance, it is important that the team have easy access to customer contact information and maybe some calendaring systems and scheduling so that when they fling out a request to twenty or thirty or forty folks it is easy to get them on the calendar. Some good centralized storage so we take lots of notes. We transcribe or we record, we get our highlights down as quickly as possible and put them someplace where they are shared, maybe indexed or easy to find.
I think a lot about coaching here. If one person on the team is good at interviews, then that person does the first couple of interviews and someone less experienced leans in and listens. Then they switch chairs on the next call and the less experienced person does the interview with some notes and comments afterwards or maybe even some scribbled Post-it notes midflight. We need to train up our folks on how to do this because it is not easy. Interviewing and validation are not obvious, and nobody knows how to do this naturally. So the idea that I would just throw somebody in the water and see if they know how to swim or how deep it is or how cold it is – is not as good a strategy as mentoring them, showing them how it is done, running a bunch myself or with somebody on my team.
Noël: So it is important for product teams to talk to customers and do customer research. When is it appropriate for them to pair up with a professional team of researchers?
Rich: I have had a chance to work with Clearworks a bunch of times, and have personally pulled your teams in because I know that is what my organization needs. I think that’s important when the product team is very thin on the ground and understaffed and can’t do this, or where we have a really important new piece of research without the bandwidth or experience. One project that we worked on together: I brought Clearworks into a client of mine when we needed to explore a whole new market segment and nobody on the product team really had good context or knew that market’s vocabulary. We wanted to make sure we were not poisoning our point of view on the new segment with all of our biases about the old segments.
I also find that people who do a lot of interviews extract tremendous amounts more information, more value, and more insight than somebody who is new. So if it is really critical to get this one piece of work correct because we are going to bet our 10 or 50 or 500 million dollars on it, then I might go outside for a great team to make sure we get the right answers. I wouldn’t do it as a regular thing unless for some reason my own product team couldn’t do it for themselves.
Noël: Do you have any tips or pieces of advice for product teams when it comes to making time for customer research or doing customer research?
Rich: If we are going to get these meetings to happen, we need to actually get them on our calendars. I am always pushing people to schedule their customer calls early in the day, to take fifteen minutes out on some day to send out a bunch of requests and get a pipeline going because it takes time and energy and it is really hard to do one-off. It is really hard to start and stop research. It needs to be really a steady diet.
I would also encourage Heads of Product (or VPs of Product Management or CPOs) to set some clear goals or KPIs, or whatever they are – because if we don’t set goals this is the first thing that falls off. So I’d want to count and measure with my team that everybody did at least three of these calls last month or we know the reason why – that it is as important to us as responding to sales requests or publishing roadmaps or sitting with our development teams.
Noël: Anything else you want to mention or advice to give?
Rich: One other thing I usually throw in here, is for my product managers who are scheduling these calls or videos with our customers I always encourage my teams to include one member of the developer staff and a designer if they have one, because the developers and designers hear different things. They have different biases. Their ears are tuned up a different way. If we are all sitting in on the same call, we learn more. It’s also a really big motivator particularly to the development side that we are really getting good customer input instead of just riding on the opinions of product managers. Developers work twice as hard when they hear a real customer express a need or a problem or applause for something. They live every day to hear that a real user took advantage of their pieces of product and liked it. So, I try to get them in the room although I don’t usually let them talk the first couple of times.
:::::::::::::::::::::::::::::::::::::::::::::
If you want to read more from Rich, be sure to check out his long running blog that covers software, start-ups, product strategies, and the inner life of product managers.
Also, we love chatting about customer research. Reach out if you want to chat about how you can use insights to inform your product strategy.
Sara Dougherty
sara@clearworks.net
