Most companies have an inefficient chain of people and paper between customers and the people who can make major improvements. When the customer data finally reaches the product design group, it often isn't easy for the team to digest its significance and prioritieze it accordingly. All of the delays taken together mean that improvements don't happen as fast as they should.
I recomend the following approach to integrating customer complains and whish list into product and service development.
1. Focus on your most unhappy customers.
2. Use the technology to gather rich information on their unhappy experiences with your product and to find out what they want you to put into the product.
3. Use technology to drive the news to the right people in hurry.
If you use these three things, you'll turn those draining, bad news experiences into an exhilarating process of improving your product or service. Unhappy customers are always concern. They're also your greatest opportunity. Adopting a learning posture rather than a negative defensive posture can make customer complaints your best source of significant quality improvements...
I have always worried that when these claimed incredible new benefits come, we will lose all the old ones. Then it becomes a kind of trade-off situation where you have to see if you are better off. I like clear wins. I would bet on improving what we have while maintaining all the benefits and eliminating the drawbacks, rather than introducing new games where there are new benefits and new drawbacks
Features are kind of crummy in a way, because the more features you have, the bigger the manual is. And features are only beneficial if people take the time to use them, wheras speed — if you can print the pages faster, or show it on the screen faster, or recalc it faster — that’s worth an incredible amount. If you can give the users a few simple commands and make the program efficient enough to do what they want with those few commands, then you’re much better off. One sign of very good programs is that even internally they follow that philosophy of simplicity. If they want to do something complex, they call the code with simple operations internally, rather than doing the complex operation from scratch.