I agree that doing more listening than speaking when talking to customers is important.
It's also important to remember that customers will tell you they want features they they won't actually use or pay for. So it's necessary to develop an understanding of what your customers do and what problems they're trying to solve.
This often helps more than just listening to features they say they want. If your customers aren't in the business of building products (especially software products), their ability to ask for features is limited by the fact that if you're not an expert in how the product is created, it is difficult or impossible to know what features might be easy to add, and which ones are difficult.
It's even likely that you can add features that your customers that your customers don't even know are possible. In this case, they won't be able to ask for those features, or anything like them. As an expert (in software, or any other specialized product development field), taking the time to really understand your customers, the problems they face, and the jobs they are trying to accomplish can help you come up with new features and products that actually amaze your your customers and attract new ones.
I would add that when you put a person in a position that you have asked them for input, they will feel pressured to give SOME kind of input, whether or not it is actually warranted. You're kind of setting them up to give input in the same way you might set someone up to tell a joke, they feel pressured to fill that space with SOMETHING.
Most of the time when I have built features that came from customers, it ends up being the least used feature of a particular update cycle. Sometimes to the point that we have to reverse or highly modify it later. The reason your customer isn't in the business of making the thing you're making, is because they have no idea how to make that thing.
If you ask a person what they want out of a new Ford car, they are not going to say "Brake pads with a higher durability for longer use," they are going to say "More cupholders wouldn't hurt, and maybe you could offer it in magenta?"
Instead, you need to ask your customer about what they are doing in areas around your software. Not "What would you like in a new car?" but "What have you been doing in your car?" and "How much maintenance do you have to do?" and "What's the worst thing about the stuff you do in the car?"
Then maybe you can find out that the brakes make a squealing sound because they are mis-adjusted and are wearing out the pads too early.
Great points! Being willing to listen is step 1. That's the product culture that needs to exist first and foremost. Completely agree with you: knowing what to do with the feedback you receive, and how to interpret it in order to innovate and solve real problems is the key that I firmly believe drives the ultimate success of a product. That's a product development/design problem that's alluded to in the middle of the article, but hard to really do it justice in a few small blurbs. Feels like a good topic to be the subject of its own stand-alone post as a follow-up to this one :)
"Part 2: Listen to Your Customers, but Don't Do Everything They Say" haha.
As you pointed out, you did allude to it in the article. I was just trying to add a bit more based on first hand experience with software customers.
And hey, sometimes customers will just flat out tell you that they need a feature that is blindingly obvious to them, but didn't occur to your product development team. It's nice when it is that easy.
So I agree that the knowing how to interpret what your customers say is and important part of being able to act on what they share with you. That certainly doesn't diminish the importance of anything you wrote, though. Without engaging with customers and properly listening to them, there wouldn't be any information to interpret.
Here's what Alex (atopiler) Slacked me yesterday after he read the article in draft "One thing that I felt didn’t really come through fully was some of the true essence of cust-dev calls. This is the product snob in me talking, but it felt a bit like we're listening to what our customers wish for, and we build what they tell us to build. When it comes down to it though, what the calls really reveal, and what we’re really trying to understand more deeply than anything else is what are biggest problems and frustrations they’re dealing with on a day-to-day basis? Why are these things frustrating? Why do they put themselves through that frustration? And what would it enable them to do if those problems didn’t exist?"
And that became that middle section.
Thanks to all of these comments I'm seeing the light of what he was really getting at there and I've salted the headline and some of the earlier passages to set that up a little better.
p.s. this is my intro to HackerNews - you guys are awesome.
It's also important to remember that customers will tell you they want features they they won't actually use or pay for. So it's necessary to develop an understanding of what your customers do and what problems they're trying to solve.
This often helps more than just listening to features they say they want. If your customers aren't in the business of building products (especially software products), their ability to ask for features is limited by the fact that if you're not an expert in how the product is created, it is difficult or impossible to know what features might be easy to add, and which ones are difficult.
It's even likely that you can add features that your customers that your customers don't even know are possible. In this case, they won't be able to ask for those features, or anything like them. As an expert (in software, or any other specialized product development field), taking the time to really understand your customers, the problems they face, and the jobs they are trying to accomplish can help you come up with new features and products that actually amaze your your customers and attract new ones.