The Voice of the Customer

Somehow, some way, you’ve got to get your customer’s input.

I’ve tried to do formalized processes on obtaining VOC, but have never been very happy with them. Looking back at the formalized documents after going through a couple of revisions with a product can’t justify the time and expenditure to create them — it is truly the blind leading the blind if you are trying to break into a new market. Not that there is a lot of choice there, but rapid prototyping may be a less all or nothing proposition, especially for a small team with limited resources vs. teams that have people devoted to six sigma and the like.

I’ve also constructed round-tables of various ‘expert’ users to provide feedback, but the feedback from experts usually ignores the fact that most users are ‘perpetual intermediates’. And while the feedback is usually useful, it isn’t always easily enacted. Doing a round-table at the end of a product means that you can do a few tweaks, but no major overhauls, and doing continuous round-tables is difficult to arrange if your clients are busy.

There is another option, although it also has a few sticking points: utilize your sales and support teams. They talk to your customers daily. Sales should know what people are asking for; support should know what customer’s pain points are. Again, this only really works with an existing product. And the other downfall can be one of self-service instead of customer service. It may be in the support person’s best interest to limit how much support they have to give, so instead of fixing a fundamental product problem they may advise patching a work around instead. Sales may advocate building something peripheral because people are asking for it, while missing the boat on how it fits into the total package.

VOC is more art form than science, but that’s what makes it such an interesting topic, and certainly one open for debate.

Advertisement