Ask HN: Should you listen to your customers?

[kasrakhosravi2]

I always had a hard time with this question.

On one hand, I always knew it is really important to ask customers about their pain points and how my product can solve it.

But I also get carried away by making a lot of assumptions on the behalf of my customers and sometimes it has paid off.

So in short, the process of listening to customers is a bit vague in my mind. I was wondering if anybody has a system in their head about how to approach this?

[giantg2]

Should you ask your customers?

I think this is a yes. This gives you some insight into what is desired.

Should you listen to that feedback?

I think this depends. You may get some customers that have unreasonable expectations. I have recieved some enhancemnet requests that make sense, so I implemented them. I've also recieved requests for functions that were beyond the intended scope of the product and would be better met with other products. In those cases, I would be honest and tell them those thoughts. Granted this is FOSS.

[kasrakhosravi2]

Good points. I think listening to customers feedback is like having an open door policy. Even though there will be some useless and irrelevant feedback and conversations, the ones that are important and useful can move the needle for your business. Thank you for sharing your take on this

[twobitshifter]

https://hbr.org/2011/08/henry-ford-never-said-the-fast

> An innovator should have understanding of one’s customers and their problems via empirical, observational, anecdotal methods or even intuition. They should also feel free to ignore customers’ inputs. Because by now it should be clear that Ford’s adherence to his vision of the mass-market car and how to materialize that vision was instrumental in both his early success in growing Ford Motor Company as well as his later failure to respond in a timely and effective manner to rapid innovation in the marketplace.

The real lesson learned was not that that Ford’s failure was one of not listening to his customers, but of his refusal to continuously test his vision against reality, which led to the Ford Motor Company’s failure of continuous innovation, resulting in a catastrophic loss of market share from which it never recovered.

[necovek]

The obvious and simple answer is: always, yes!

You should not take their input at face value though (try to figure out what problem they are attempting to solve since they'll usually propose tooling that solves their problem), and focus on things affecting your customers most heavily (however you define that: highest paying customers, largest numbers, most influential to get word-of-mouth recs...).

But sometimes you should take their input at face value too ;)

[kasrakhosravi2]

You hit the nail in the head. Customer feedback is like a book that can be useful for your context, irrelevant or exactly describes your pain points and show you the path to success. Since the effectiveness of customer feedback is on a spectrum, I think our best bet is to listen to most of it and just become better at pattern matching and formulating hypothesises. Thank you

[helph67]

Become familiar with Pareto https://en.wikipedia.org/wiki/Pareto_principle Some clients are more important than others, specifically by the income they contribute to you (now and/or in the future).

[kasrakhosravi2]

Excellent point. You always want to focus on the part of the job that has the potential to bring the most value with minimal work. If a single user wants a feature, it is better to be ignored in favor of more lucrative business opportunities within the business that could bring more cash and also value for customers. I will keep this in mind.

[Graffur]

"Listening to your customers is way overrated. The job of a customer is just to enjoy your product or service and not to predict / understand your business or give you guidelines or where to go." - Mark Cuban

[kasrakhosravi2]

Haha this totally sounds like Mark. I think this statement is SO true for a lot of founders out there too scared to move or do anything just because nobody is validating their ideas. I think as a founder you want to have some initial ideas about how the world work and the business you are trying to solve. And then in the process, you need to ask for feedback, keep refining and keep going.

[Jugurtha]

Listening to what customers say does not mean you implement what they say. Extract the problems they're trying to solve, the "job to be done".

What they say and the underlying problem are different things. Way too often, people will suggest solutions (developers will suggest implementations), not the actual problem they're facing.

For example, here's something I posted on Reddit for our machine learning platform[0]. One commenter said:

>Sounds like a great tool. But for me to seriously consider it would have to be OSS.

If you take it at face value, you'll think "Oh, people really want this to be open source". Digging deeper, however, by driving the commenter to talk about the fact they use other tools and services that are not open source, it becomes clear that the commenter wants control over data, peace of mind, and reduce technical risk:

>Adopting a tool that might disappear in the future is too big a risk for our team (and I believe many others) to take. OSS provides a guarantee that even if the company behind the tool disappears, it will still be accessible to us.

It's not that they really wanted OSS. The "OSS" was an implementation or a solution to their underlying problem: what if your company disappears and all the work I've done on your SaaS is gone now, or you leave me scrambling to exfiltrate, and even then, I might be stuck.

This aligned mroe with items we had on our roadmap to address that problem because we felt strongly about this too.

There's a useful concept called the "XY Problem"[1]. I remember someone asking me how to solder a thick wire to a tinier pad. I investigate what they're really trying to do further, and it turns out they had a burnt out fuse and they wanted to put a thicker wire and solder it to avoid it melting again. That's the whole point of a fuse. That's why the fuse gives away its life, so other appliances may live in case of a higher current. Replacing with a thicker wire resolves the apparent problem (fuse burning), but exposes the downstream appliances to a higher risk.

The "solution"/"implementation" to their "problem" is poor, because their problem definition is lacking. They came up with it based on the knowledge they had. Properly identifying the problem helps avoid disasters downstream.

Clearly defining a problem is extremely important. We're a boutique consultancy specialized in machine learning, and a good chunk of what we do upstream is peeling away layers of solutionism, assumptions, implementations from what our clients say when they talk about what they want or what their "problems" are.

Some ways to peel out this way is to ask them what they're doing right now to solve that problem, how frequently they have to do that, the last time they had to do that, or if they're using other tools to do that.

This is similar to when we're in a meeting and talking about our product and someone asks us if we have a feature that does X and I ask them to talk more about the problems they've had trying to do X. More often than not, they'll say they don't really need X. They were just asking. Or if they that "Prouct Y has the feature X". "What has been your experience with product Y?" ... "We're not using Product Y". Why not, it has feature X... This makes you realize that if it were that important, the conversation would be different.

If you don't do that, your "sales person" coming out of the team will say "We definitely need to add X to the product".

"Desirability", "feasibility", "viability".

The links[2][3][4] are replies that address this directly or indirectly.

- [0]: https://www.reddit.com/r/MachineLearning/comments/kolobf/p_c...

- [1]: https://en.wikipedia.org/wiki/XY_problem

- [2]: https://news.ycombinator.com/item?id=24503365

- [3]: https://news.ycombinator.com/item?id=24972611

- [4]: https://news.ycombinator.com/item?id=22827841

[kasrakhosravi2]

Excellent examples which gave me a more clear idea on the right way of thinking about this. I think more important than anything, it is our ability as founders to ask the right questions, form the right hypothesis and be able to recognize the signal from all the noise.