Customers Do Not Always Know

Glenn: Completely agree. Firms must always listen to customers and it is a great motto for customer service. That is, as long as it does not foster a culture that translates into committing to every customer request/need. It is certainly more art versus science on striking the appropriate balance between innovation and incremental improvement based on customer feedback.

I certainly agree that customers are not literally always right. Companies that have that statement as part of their R&D matra are foolish. I think innovation needs to be lead by visionaries in your company not by customer complaints. However, one would hope the Customer Service department has "the customer is always right" taped to their monitors. It's an important distinction - short-term versus long-term outlooks.

Stephen, I always know when I have an interesting post when you show up! You are very right that parachuting in and "living the life of" the customer is one of the best ways to gather the intelligence and "pain points" of the customer. There are a number of ways to get to that next great idea for innovation that solves a customer need.

The fundamental message is that the customer is rarely going to explicitly say "if the application just did X" it becomes the next innovation that you can build a business on.

Back when we were discussing knowledge management, I cited a post from my own blog entitled "Research is not about the answers!" and asserted that the same held for knowledge management:

http://correlate.wordpress.com/2007/05/08/still-a-major-pain-pointknowledge-management/

In the frame of this post, the claim can be modified to the assertion that customer engagement is not about questions and answers. It requires richer communication over a longer scale of time that embraces the entire development process and continues after delivery. A key element of the richness involves OBSERVATION, as well as verbal exchanges, which is the cornerstone of workplace anthropology.

My point is that asking the customer what the pain point is will probably be no more fruitful than asking what the customer wants. Because they have different work-situations, it is inevitable that customer and provider have different world-views; and those differences are likely to confound even the simplest verbal exchanges. More progress is likely to come if the provider embeds in the customers operations long enough to start hypothesizing about pain points. Those hypotheses can initiate a more informative conversation between provider and customer with greater promise of a satisfied customer. The reason this strategy is not very popular is that it is usually difficult to estimate how long it will take to arrive at those hypotheses that enable this particular development methodology. However, with appropriate prototyping tools, one may be able to take an incremental approach, giving the customer the opportunity to critique "samples" that basically embody "candidate hypotheses."

Note that none of these ideas are new. You can find them in the old book about decision support systems by Keen and Scott Morton. The book also provides several case studies, which, while old, remain quite informative.