Amazing! That is the true essence of customer development.
When you walk into a hardware store and ask for a 2-inch drill bit, it's not the tool you really want. What you really want is a 2-inch hole in the wall.
"You'll never create amazing products with this mentality..."
I think that this kinda misses the point. If you're only building the things they explicitly ask for, then yes, you're right. However, customer development isn't mean to track what your users want and cover their expectations; it's to uncover the biggest pain points/real problems to come up with amazing solutions for - what's actually _worth_ pursuing and potentially building? How exactly those solutions manifest themselves often times does not come directly from customers, but the amazing ones are just as often inspired by insights gleaned from customer development.
The article you shared actually backs up my point exactly. Example: what could be obvious to one of your customers can end up being amazing to you and your other customers. In practice, I've found this dynamic play out time and time again.
I have to whole-heartedly disagree with this. Customer development and feedback don't just apply to short-term marketing and minor-point improvements. That couldn't be further from the truth.
The "They'll tell you what to build" isn't meant to be taken literally. If you listen and try to truly understand people's problems, they'll guide you towards the most useful solutions. Coming up with those solutions is still up to you in most cases, though.
Re: Apple - they understood the real problems that their potential customers had. No, customers didn't come and tell them to go and build a device like the iPhone. However, from understanding the market and the pain points that people had with mobile phones, Apple was able to identify an opportunity to enter a new market and disrupt it.
Actually, I'd suggest people did tell them to build the iPhone, and the iPod.
They looked at the problems with the MP3 market at the time, tiny devices with poor user-interfaces and their solution to the state of the market at the time was the iPod. Unexpected from Apple which was only a computer company at the time.
Once we had our iPods we were carrying around an iPod and a phone (Blackberry was huge at the time). They understood customers wanted a single device, it had to have great messaging like a blackberry, and do all the music and video needs of an iPod of that era. Blackberry had apps, a web-browser, maps, etc. It's important not to forget that. Apple did a better job with the browser and gave the thing a full-size touch screen. Customers didn't ask for that, but they had asked for the basic device. Apple took what was asked for and put their own scrutiny to it to see just how amazing they could make it.
The point is to talk to people to know whether something you want to build is actually going to be great before you go and build it. Most of the time when people go and build what they think is "great" they end up realizing that nobody actually cares. It's a sure-fire way to waste a ton of time of money, which for startups, are the two scarcest resources you have.
this actually isn't bad advice for idiots. so if you're an idiot, by all means it's probably better to ask someone, "how'd you like it if" rather than build it and see. As a great example, everyone knows people like battery life. So if you're an idiot, a great question to ask your customers might be, 'How'd you like it if we made a giant battery, like a car battery, that you can take along as an external battery booster for your next Samsung, so that you can just have it connected and have 72 days of life. It would be deep discharge, so that you have hundreds or thousands of cycles." Why did I use this example? Because only an idiot would ask any customers this. It's idiotic. But if you're the kind of idiot who would make that - then by all means! ask them.
On the other hand, steve jobs didn't need to ask his customers how they'd like an iphone - he told them why they'll like it.
Would recommend you check out "The entrepreneurs guide to customer development"!
Customer Development is a process that's really meant to be applied to prospective customers. The whole point is to figure out what problems the market needs, and ultimately what kind of solutions there might actually be a market for.
Instead of building something and then going to people and asking if it's useful, find out what a large segment of the market would find useful first.
Get out of the building and talk to actual people - create simple experiments to help you prove whether a market actually exists. Validate your assumptions before building. Follow the Lean Startup methodology :)
Very true. The helicopter vs. rush hour example is kind of like finding the holy grail, and that's what you strive for. In practice, the majority the improvements you can extract from these conversations end up being much smaller. But many small improvements compound and also help create the invaluable customer feeling of "Hey, I feel like the team behind this product really gets me!"
Also, well put: "You probably don't know better than them AND they probably don't know what they want."
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.
When you walk into a hardware store and ask for a 2-inch drill bit, it's not the tool you really want. What you really want is a 2-inch hole in the wall.