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.

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.