Customer insights, part one: the perils of talking at your customer
Helpful tips for avoiding dumb mistakes I've commonly made.
Customer insights, part one
We are customer-obsessed.
The customer comes first.
Nothing is more important than delivering value to customers.
There are a dozen variations on the theme of customer centricity. We all know we must talk to our customers, hear their problems, and design solutions to improve their lives.
Building a customer-first mindset is hard; the skills take years to develop.
This article is the first in a series about having quality conversations with your customers, listening carefully to them, and taking appropriate action on their feedback.
I see–and have made–three common mistakes: talking at your customers and not listening to them; listening to your customers and ignoring their feedback; and listening to customers but not validating the market applicability of their requirements.
This first article is about the hard lessons learned when you talk at your customers instead of with them.
Please talk to your customers.
In the beginning, I took this advice quite literally.
My goals were to share information, spread awareness, and generate excitement about our product, its capabilities, and the bright future. I considered myself a teacher and my customers as eager students. Achieving these worthy goals came at the expense of learning from my customers and using that knowledge to build a better product.
The more experienced I became, the more confident I was in my knowledge of the market, competitors, and customers. Because, you see, I’d been diligently meeting with my customers for years, inundating them with important information and saving questions for the end.
A lesson
Many years ago, a sales VP talked me into visiting one of his government agency customers in the DC area. I came prepared to speak, armed with a PowerPoint presentation I used to explain our product roadmap in excruciating detail. (Many of the features in my well-planned roadmaps never shipped.)
My talks could easily fill an hour, and my mindset was to talk fast. I rarely paused for questions, preferring to plow through my prepared content. Speaking truthfully, in those days, I was afraid of customer input. I lacked the confidence to accept direct feedback. I desired to be THE product expert, more knowledgeable about my product than anyone else.
If a good rule of thumb is to talk 20% of the time and listen for 80%, I inverted this ratio.
These are mistakes common to young, inexperienced product managers. Sometimes, we fall back into these patterns later in our careers.
Meanwhile, back at the customer meeting
Our contingent crammed into a small, windowless conference room. I fiddled with connecting the projector to my laptop. After ten minutes, the customer arrived, a gruff older man who could carry on about the history of computers and recount his experiences using punch cards. He spent the first ten minutes of the meeting establishing his bona fides.
When he finished his sermon, I launched into my talk.
Fifty-four minutes into our meeting, he stopped me.
The previous year, the sales VP had sold our software to the federal government agency we were visiting. I vaguely recalled answering product questions and presenting our roadmap during the presales phase. I must have talked a lot because I knew very little about what they wanted to use our software to accomplish.
The deployment hadn’t gone smoothly, but they finally had something working in production.
Unbeknownst to us, this man had led the product’s evaluation, reverse-engineered it (violating our contract), and subsequently written about seventy thousand lines of Perl code to get our software to do what he wanted.
The product wasn’t functional until I’d made my changes, he explained. I don’t understand how you shipped an incomplete product that didn’t work.
He paused and looked around the table. We outnumbered him six to one. He resumed in hushed tones and made a proposal: he wanted us to license his software changes and incorporate them into an upcoming generally available release. He didn’t consider the product functional without his changes, and in its current state, his code was unsupportable by anyone but him. For obvious reasons, his situation was untenable. If we didn’t incorporate his code, he would ask for the agency’s money back.
I sat, a bit dumbfounded, wondering if his employer was aware of his entrepreneurial spirit. At first, I strained to grasp his point, blaming his low voice and ignoring the reality of what he was saying. Finally, his point landed. He was trying to sell my software back to me.
I mumbled something like, I’ll think about it, while I packed my laptop, and we adjourned the meeting.
The sales VP drove me to a nearby coffee shop for our meeting debrief. His sense of urgency that I accept the customer’s terms suggested he’d already spent the commission he’d earned on the deal. For half an hour, I reiterated that I’d consider the proposal, careful to make no commitments. In truth, I couldn’t make any commitments because I had no idea what all that code did and why the customer needed it to solve his problem. I still hadn't learned anything meaningful about what the customer was trying to do.
By the time I arrived for my flight home, I’d already received a direct email from the customer reiterating his terms and insisting I accept them at the earliest. I regretted leaving behind my business card.
I learned something about my product that day, but my approach ensured those learnings were haphazard and accidental.
Actually listen to your customers before you talk.
Eventually, I realized my customers know way more than I do about their problems, and it’s vitally important to understand what they think about the software I’ve built to solve those problems. I am stubborn and prideful, so this took longer than it should have.
But here’s the thing. Asking for and accepting feedback is hard. It takes work.
I learned a technique where I ask a question or pose a topic and then shut up and say nothing for at least a minute. A minute sounds short until you try it. People hate the silence, but by the end of those sixty seconds, I guarantee someone in the room or on the Zoom will break the silence.
Typically, a free-flowing dialog follows where customers unload their thoughts, concerns, ideas, and tribulations.
All you have to do is stop talking.
Conversations and outcomes
Perhaps I’ve over-tilted on this, but my first reaction to almost everything nowadays is, “Hey, that sounds cool. Let’s do some voice of the customer work and validate or disprove that.”
It’s a solid move. Before you build your backlog, plan your sprints, and send a squad off to code, find out if you understand the requirements and have a grasp of the problem you are trying to solve. Can you articulate the outcome in the customer’s voice? Until you can, you’ll have no whether your product idea has merit.
Most product managers talk at their customers because they are afraid. What if you get an answer you don’t like?
I encourage product managers to build a system for gathering insights and organizing feedback.
Start with open-ended questions and gradually refine.
What is the hardest part of your job? What are two things that would make your job easier? Tell me about how you accomplish <insert task>? How often do you do that task? When was the last time you did it?
Schedule thirty-minute meetings with your customers. Come prepared with three questions or topics and give the customer 7-9 minutes to respond. Bring someone to take notes because seven minutes is a long time and will be packed with information. Having the secondary note taker along allows you to be fully present and engaged, able to ask follow-up questions, and ready to react to subtle body language and facial cues you might otherwise miss.
After the conversation, analyze your learnings, synthesize them with other feedback, and look for ways to quantify anecdotal evidence. Follow up with questions that quantify perception–on a scale of 1-5, how hard is <x>?–or provide other quantitative clues–how long does it take? How often do you do it? How many times does it have to be done?
And then what happened?
We didn’t license back the seventy-thousand lines of Perl code. Instead, I organized a follow-up meeting and asked the gruff government developer WHY he spent so much time writing all that code. The problem, he explained, was the product lacked a validation process to manage data quality. A user had to manually browse through synchronized data to determine whether it matched what was expected.
After he said it, the need for such a feature seemed obvious. But I hadn’t heard any customers specifically ask for it, not because they didn’t need it, but because I’d been talking at them rather than learning from them.
Soon after, I asked a handful of customers about how they were checking to see what was happening with the synchronized data. One by one, they eagerly told me how they’d hired junior team members to manually check the data each day or each week or how they’d written scripts to accomplish the task. All eventually expressed how much they needed an automated data validation capability and how much it would simplify their lives. One told me he could redeploy at least three team members to work on other, higher-priority tasks.
We immediately set about prioritizing the work for our next release.
How can I help?
What is one simple change you can make to literally flip the script?
Before.
Speaker: blah, blah, blah…
Audience: …
Speaker: do you have any questions?
Audience: Yes!
Speaker: I’m sorry, that’s all we have time for; let’s follow up!
After.
Speaker: How can I help?
Audience: Answer too long to transcribe…
This tactic will set you on the path to more effective learning. In the following article, I’ll explore how to ensure you don’t just ignore that feedback because you are sure you’ve already deduced the correct answer to the problem.