Listening to Customers is Harder Than It Seems

Maintaining a core value of "listening to our customers" is trendy among companies big and small. But it’s harder than it seems. Albert Wenger absolutely nails it in this post about why listening to customers is hard, hard, hard. Key excerpt below, bold font my own. I want to highlight point #2 — it is often the case that customers do not know what they want, or actually don’t want what they say they want.

First, which customers should you listen to? Is it the early adopters or should you try to identify what you believe to be “mainstream” customers? This turns out to be very hard to answer. If you don’t keep the early adopters at least somewhat happy you may never make it to the mainstream. Or it could be that there is no real mainstream for your product, so looking for it might make you neglect the early adopters you already have. Conversely, if you only cater to early adopters you might build something that fills their generally more advanced needs but is too complicated for the mainstream.

Second, how should you listen to customers? Is it what they are saying about the product/site/service or what they are doing? Here too are conflicting pieces of advice. On one hand is the theory that for every one customer complaining about a particular problem there is a silent group of 100 or more having the same problem but not bothering to complain. On the other is the view that verbal complaints and even more so feature requests tend to be what users “think” they want as opposed to what they actually want need (thanks to tweetip for pointing this out). The latter can only be learned, the theory goes, by observing their actual use. Often what customers say and what they do conflicts.

Third, how should you reconcile listening to your customers with your strategy? This is often the hardest part. You have a strategy that you believe in. It’s difficult enough to not outright ignore any customer feedback that’s not on strategy. After all, you don’t want to be a flag waving in the wind and shifting with every breeze. But how can you tell that apart from your customers telling you that your strategy is actually wrong? What if you are trying to solve too hard a problem, when the customers really need something much simpler?

On point #1, I think you have to develop for the early adopters and just accept that you will probably over-develop and need to modify the product for the mainstream. This is a frustrating cost but an unavoidable one since capturing the early adopters, winning their support, and leveraging their testimonial into mainstream accounts is critical. In my experience many mainstream customers fancy themselves early adopters and hence won’t discount the early adopter’s testimonial as much as they should (in the sense that a product working in an early adopter won’t necessarily work in a mainstream inasmuch as the needs and cultures are different) allowing the company to really leverage an early adopter’s success to potential clients who actually look and act different.

One Response to Listening to Customers is Harder Than It Seems

  1. michael vassar says:

    It seems to me that the mainstream customers largely choose technologies because they are cool (simple, attractive, well marketed, above all, high class) and easy to use, while early adopters adopt technologies that resemble less powerful version of future technologies that they can fairly clearly conceive, but not clearly enough to appreciate the difficulties of actually building their imagined technology. The early adopters make noise promoting the prototypes of future tech as the next big thing, some company (facebook, blogger) comes around to make a ‘cool’ version of whatever the early adopters are promoting, achieves lock-in, and never bothers to create the version that would realize the early adopter’s vision.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>