Listen to Customers for Problems, not for Solutions

And why the famous Henry Ford quote is wrong

Aug 09, 2020

In this edition of The Discourse, we deep dive into what it means to listen to your customers. Why is it so undervalued? How can you go wrong? And how can you set a framework to do it well?

Subscribe if you're new here to get weekly content like this directly in your inbox.

How to not listen to customers

David Cancel in his MindTheProduct talk gives an example of the introduction of the EMV chip credit card in the US. This was meant to replace the swipe card, which didn’t have as much security as a chip card.

The jobs-to-be-done was supposed to solve the security issues but in the end, it caused longer wait-time due to its super slow processing.

Let's try to understand what went wrong. There were a lot of stakeholders including the banks, card issuers, and retailers. They assumed that the customer’s problem is security but what they didn't realize is that the customers cared 4x more about speed than security.

The reason they had a credit card is so you can outsource the security hassle to someone else. Due to the slow processing time, it caused 10-seconds queues at the retailers which caused problems for the customer.

Don’t assume you know what the customer wants

Henry Ford and why you shouldn’t ask customers what they want

When the topic of listening to customers comes up, most product people bring up the famous Henry Ford quote (which may be inaccurately attributed to him):

“If I had asked people what they wanted, they would have said faster horses.”

What they misunderstand is that you shouldn't ask what they want. You should ask what their problems are. In this case, they wanted to reach the destination quickly.

Now, the customers aren't always equipped to answer how that should be done. It could be a faster horse, a car, or something else.

It also turned out that after the initial success of the Model T, Ford didn’t innovate much which led to General Motors capturing much of the US automobile market. Ford’s market share went from 66% in 1921 to less than 15% in 1927.

Listen for problems, not for solutions

Asking for a faster horse is nothing but a feature request.

Customers love requesting features. For example, if a customer asks for an analytics dashboard with export functionality as a feature request, first ask questions.

What would X feature allow you to do?
Why do you want this feature?
What is the motivation behind the request?
What are they doing to solve this problem right now?

What these questions will allow you to see is how big a problem is right now for them.

The 5 Why's framework is especially useful to uncover the root cause.

Going back to the analytics dashboard example, it could be that they need the dashboard to make decisions, or they could just want an export of the data to create their own custom dashboard. They might also just want to send email reports to their customers.

There are many use cases for this one feature request.

If you don’t uncover the real motivation by digging deep, you'll build the wrong feature.

The customers own the problem, you own the solution

How to categorize feedback

According to David, you should add the feedback to three buckets according to the Spotlight Framework:

User Experience issues:

Some of the questions would be in the form of

How do I
- use ________
- integrate with ______
What happens when __________
I tried to ________

They know it's possible, but they can't figure out how to complete the action.

You have to solve this challenge through improvements to user experience or help docs.

Product Marketing

Some of the questions are:

Can you ______
How do you compare to _________
How are you different than __________
What should I use you for?

This means that you offer these features, but the user is unaware of them.

You have to improve education and product marketing.

Positioning

Few questions you would receive:

I'm probably not your target customer
I'm sure I'm wrong but I thought

If you believe the product fits the right persona, you have to address this in the marketing copy.

How often you should get feedback

In today's world where both hardware and software products are built with constant feedback from the customers, you should be asking for feedback at every step.

What’s helping is the 'Build in Public’ movements that are gaining traction.

Dru Riley from trends.vc writes about this in his report on Open Startups and KP is creating a movement on Building In Public with buildinpublic.xyz

You no longer have to wait for a big launch to get feedback from users.

By involving customers through the process of development, you generate goodwill.

Further watching: