When conducting customer interviews, one of the classic errors I see product managers (PM’s) make is to ask customers what they want. I cannot tell you how many times I’ve been in a feature validation meeting and the PM leading the session asks, “Would you use this feature if it was in the product?”
I’m sorry, but that’s a really bad question to ask. Don’t do that.
Here’s the deal. The users don’t really know. They also have agendas. They also forget things. They also lie sometimes.
Many moons ago, I was working on a strategic infrastructure product. As part of this product, we were trying to decide what features to add in what order. Normal PM work. One of the features we were thinking about was a disaster recovery (DR) feature. The team responsible for backup and DR was really excited about this feature. They did a survey of existing customers that asked, “If we had this DR feature, would you use it?” Not exactly that question, but pretty close. 50% of our install base said, “Yes, we would use it.”
Here’s the problem though. We already knew that our market wasn’t spending money on DR. We had revenue numbers that showed that our existing DR product wasn’t selling well. This lit alarm bells on my team. Huge argument ensues. We spend MONTHS debating this. Finally we decide to build the feature.
The feature falls flat on its face. Nobody wants it. We really struggle to get even one customer deployed. Months go by and we finally do some proper research. It turns out that all these customers know that they should do DR, but they don’t. Auditors tell them they should do it, their exec leadership says they should do it, but when it comes down to actual planning, they just don’t make time and it falls off the work plan. Thus, any DR solution has to address this critical time and staffing issue or it won’t get adopted.
Sigh. Back to the drawing board.
So, how do you learn from my costly mistake?
Customer needs vs. wants
You need to get away from stated customer desire. In the end, it really doesn’t matter what they want. Hell, I want to look like Hugh Jackman. I don’t and I won’t. I need to be healthy and exercise, so that’s what I actually do. When you talk to a customer, it’s really easy to find out what they want. They’re usually happy to tell you. But this is just surface clutter. The entire point of a customer interview is to dig down and understand customer need. What is it that they need to be true? Can you satisfy that need? Can you make their pain go away? If so, you have a customer for life.
In the previous example, they said they wanted DR. Maybe they did, maybe they didn’t. What they needed was for audit and senior leadership to get off their back. So, we introduced a feature that automatically made their data resist a single Data Center failure. Customers loved it. They did no work and their auditors were happy. The feature sold amazingly well.
Here are some ways you can dig down into need and away from want:
Always ask how it is done now. How long does this thing take? How much does it cost? Who does the work? Based on our proposed solution, would it be cheaper/faster/better than it is right now? Knowledge of current state helps you understand your value prop. You save them five minutes? Meh. You save them a million bucks? Hell, ya.
Focus on them, not on you. Who cares how your product works or what your roadmap is? Worry about them getting promoted. What can you do in the product to make this person a rockstar? How do they get promoted for using your product? Going into a customer meeting, giving a demo and walking out is a complete waste of PM time. That should have been done by an SE. Yes, you have to pay for their time by telling them what they want to know about the roadmap, but no, you’re not there to sell. Don’t talk about you, your team and all the hard work you’ve been doing. Ask about them and how they are doing.
Talk to the right person. Do you know who your buyer persona is? Your user persona? Is this person one of those two? If not, why are you talking to them? Does it matter what someone who doesn’t use your product and doesn’t have the problem you are trying to solve thinks? No, it doesn’t. Make sure you know who you are talking to and why.
Ask them to show you. One time when I worked for VMware, I was on site with a German retailer and we were discussing a new feature in a conference room for over an hour. I just wasn’t getting it. Finally, I said, “Who does this now?” Dieter does this now. “Where is Dieter?” Dieter works down the hall. “Can we go see Dieter?” Yes, right this way. Man, I learned more in the next 30 minutes than I had learned in a month. Amazing. Cherish those opportunities.
Always force them to make a tradeoff. Never ask, “Do you want A?” Always say, “If you could have A or B, which would you choose?” Assuming that B is a good feature, picking A over B means that A is also pretty good. Of course, this test only works if B is actually good. So, pick B carefully, just because you love B doesn’t mean that B is a killer feature. Pick something you’re pretty sure the customer loves. Make them kill their own children to get A. If they’re willing to do that, then A is pretty good.
Always ask why. If a customer tells you something or states a preference, always ask why they have that preference. So, if a customer says “I really want you to integrate with Jira,” you need to know why they want to integrate with Jira. Is this about speed? Cost? Can you see a sample Jira ticket? How many times has Jira integration come up this week? What would happen if I don’t integrate with Jira? Is there an existing corporate mandate that they must use Jira? And so on.
Always aggregate. A single customer, even a really big customer, saying that they want something is interesting but ultimately irrelevant. If you find that a high percentage of customers have the same underlying pain points that you can resolve with feature X, now you have something meaningful.
Trust, but verify. Anything that you’re told about user behavior is subject to misunderstanding, false reporting or other issues. Don’t guess. If they say, “We use feature X daily,” go check. If you don’t have enough reporting in the product to know what features they use, go fix that first. I have had multiple people tell me that features were highly valued by customers, only to find out in product telemetry that the feature never got used.
Of course, I’ve seen PM teams who have the opposite problem also. Teams that completely ignore customer preferences and needs. I’ve actually been told, “Nobody wanted the iPhone, but Steve Jobs built it anyway. This is our iPhone moment.”
No.
You are not Steve Jobs. You are not inventing the iPhone. Just no.
You cannot ignore reality. If customer need isn’t there, the odds of you making the product successful are super low. Yes, you could get lucky, but do you want to rely on luck? There are millions of actual pain points inside customer organizations right now. Millions. Just pick one. Solve the pain point. Iterate. This is the only way to consistently build software your customers want and will pay for.
