Gathering customer insights, part three: learning without validating
Welcome to the third article of this series about gathering customer insights.
Read on Substack.
Part one explored the pitfalls of talking AT your customers. You visit customers, talk at them incessantly, never pause to listen, rarely ask questions, fear their feedback, and are blindsided when you get it.?
Part two delved into the hubris of expertise and why we sometimes listen to and ignore our customers.
This installment, let’s call it 3-a, is about dedicating time to learning what customers need by asking good questions and paying close attention to their responses. You learn a lot about the problems your customers are trying to solve. A clear picture forms in your mind–you have solutions–and you immediately take action on the feedback and build like hell. Your product plan looks like a cornucopia of features, making a dinner table groan!?
Except you forgot a crucial step: validation.?
When you talk to a customer, how do you know any other customer wants what they are asking for? Figuring out feature applicability matures your product from customer-centric to market-driven. We’ll explore this in more detail this week.
What if your customers only tell you what they don’t like about your product? When all you know is what the customer doesn’t want, replacing one bad thing with another is easy. You have to learn what will delight them. But we are wired to take action on negative sentiment. We will explore that asymmetry and negativity bias in the next article.
Building bloat into your product
Product review season descended on our team like a skier falling off a mountain. I flew my team in quarterly to check in on their products, make plans for the coming quarter, and celebrate our successes. Six products in two days. It was going to be a whirlwind.
I worried about one product in particular. Sales were lagging, customer support requests were up, and the team regularly missed delivery deadlines. My strongest product manager helmed this product, so I was flummoxed. What was going on?
She presented her data, and nothing stood out as an obvious explanation, but there were some clues. The sales data showed proofs of concept were taking longer and converting less reliably. Customer support requests ambled across topics and features in no organized pattern. Technical debt consumed an increasing proportion of the backlog.?
领英推荐
My product manager ran an ambitious customer development program in the previous quarter. She was thinking about two significant new initiatives for her product that would likely impact many, if not all, customers. She flew the world, campaigning tirelessly to get the data to test her hypotheses. She asked smart questions, and customers gave her indispensable feedback.
We reached the roadmap portion of her presentation, a now-next-later summary of the important work the team would do over the next 90-180 days. The problem smirked at us from the conference room’s monitor.?
Her previous roadmap focused on only two themes. After her roadshow, two themes had blossomed into eight, each featuring up to a dozen near-term priorities.
“Help me understand,” I asked. “Most of these features seem orthogonal. What is the organizing principle across your themes?”
She blinked at me.
“This is what I learned on the roadshow. This is what customers want.”
“You’ve delivered a bunch of features for each of these eight themes already?”
“Yes.”
“So, that explains the tech debt.”
The problem came into focus...