… but customer feedback leads to better product development.
“So which one is it?” I hear you ask…
I don’t blame you. After all, saying that customers build mediocre products is completely at odds with the product development mantra.
Asking customers what they want is a sales tactic. It isn’t a product development tactic. Asking why they want it is more important.
Find the WHY, not the WHAT
Finding out the “Why” behind a request is super-valuable. But we rarely touch that part.
Everyone is so engrossed in saying “speak to the customers and find out what they want”, that it’s almost impossible to believe that amazing products can be produced without asking the customers.
Not asking your customers, don’t mean not listening to them. In fact I have written before, listen to what is not being said by your customers.
I don’t remember the last product I touched that was built on the back of customer feedback and was truly amazing!
Do you know of any product, truly amazing, that was born out of customer feedback? Do let me know! I am waiting.
- The iPhone wasn’t born out of customer requests.
- Palantir was born out of a vision, not customer requests.
- No one was really asking for Airbnb.
- Customers were asking for better MySpace, not Facebook when Facebook was created.
- Photographers wanted more “choice”, whilst Instagram boomed on giving less.
- We wanted taxis to come pick us up faster, whilst we now wait longer for an Uber.
- No one was asking Microsoft to create cloud services, customers were asking for cheaper Microsoft Office pricing.
You see, none of them began with 100 customers asking for it specifically.
They all began with a couple of founders, deciding, “heck, I am going to build this isht“.
And they are all successful companies.
Care about the problem, not the customer
In all of those instances above, founders deeply cared about the problem. They deeply cared about what they were building and, damn, they executed well in the early years.
None of the thought leadership on “asking what the customers want”.
By all means, speak to your customers. I encourage you to speak to customers, but do it in this order:
Build -> speak to customers -> build -> speak to customers -> build.
Once you build something, then ask “Why” or “Why not” your customers would use it. Get the why behind what they are saying. That is what will help you build better products.
You “solutionise“, customers “Problemise”
Your team has problem solvers. You know how to build something amazing. You are the expert. Not the customer.
Say what you may, customers are not experts at building amazing products. Just building what they want will lead to mediocre products.
For instance, when you go to the doctor, the doctor asks you what seems to be the problem / or what brings you here. And then almost immediately ignores your own diagnosis. The doctor moves on to do tests that will get to the bottom of it. Figure out why you are feeling ill, and then prescribe a way forward.
You don’t tell the doctor what to prescribe you or provide the solution. The doctor listens to you, find out how you are feeling, and then finds a solution to the problem – sometimes “experimenting” by giving a particular dose and checking the results in a few days.
The doctor is an expert. You are the customer. You don’t give the solution, the doctor does.
So why, in product development, do customers get to develop solutions? They shouldn’t.
You go build what you want. And then show your customers and ask “Why” they would or wouldn’t use the platform, and try to find a solution or double down on that “Why”.
I like the Lean Methodology. I like the MVP. But is there an acceptable standard for any of that?
I will regret saying this, but…
MVP is procrastination.
You have built something? Ship it. Talk to customers; find the “Why”.
I’ve always felt this way, so I am glad I finally get to just say it out loud. Customers build mediocre products. Ignore “What” they want; find “Why” they want it.
If you are spending time on finding out what customers want, you are procrastinating and following some bulls**t lean method to find an answer that you already have, but you don’t want to be bold and go for it.