Disaster by Committee

I already know Information Dashboard Design by Stephen Few is going to be a decent read because by page five, I'm greeted with this remark:

Customers are expert in knowing what they need to accomplish, but not in knowing how software ought to be designed to support their needs. Allowing customers to design software through feature requests is the worst form of disaster by committee (Few, 2006).

It's been a while since I first unsuccessfully tried articulating why plain old customer feedback and feature requests don't guarantee great products. What makes a human factors specialist's interpretation of user needs more useful than the user's own voice?

I've seen more specific (but less elegant) arguments than Few's. One of my favorite answers relies on the fact that most users you'd encounter have no idea about what your company can and can't produce - they're not qualified to define product specifications.

I think what we learn from users is more useful for defining product requirements. What are the goals of the users? What do they need to accomplish these goals? What kinds of tasks do they perform to achieve their goals? Human factors specialists should elicit and then organize the answers to these questions, helping to define the actual product specifications.

A common area of contention is, "Why do we need so much interaction with the users?" This is a valid question considering we might have: "obvious" design needs, feature requests, and clear customer feedback.

In response, I would say that a keen observer watching users can not only get user information with much higher fidelity but also with much greater validity. I suppose it's worth mentioning that users report incomplete and/or misleading information - watching users actually using the product gives you the whole picture and that picture is more contextually situated.