In the past month or so, I've written about the need for CIOs to put themselves out there and get involved with more customer-facing activities instead of focusing solely on internal business improvements. I shared results of a Diamond Management & Technology Consultants survey in which three-quarters of CIOs said their primary innovation role was to improve business processes (50 percent) or IT processes (25 percent). Far fewer respondents said the CIO's role was to create innovation designed to improve customer service, reach new customers or create new products/services.
The author of the survey, CIO Dashboard blogger Chris Curran, and I agreed this was a problem. While I made the case that internal process improvements often translate into improved customer experiences or new products/services, it's still telling that the respondents to Curran's survey saw themselves as primarily serving internal customers rather than external ones.
Microsoft CIO Tony Scott also apparently recognizes this internal "tunnel vision" as a problem. As related in a recent SearchCIO.com story (free registration required), Scott has been supplementing time spent with internal product groups by reaching out to Microsoft's external customers. He told attendees of the Mass Technology Leadership Council Growth Summit that he'd spent four hours working with a customer service representative at a call center. He said:
If you haven't done it, go sit in a call center and listen to customers calling in. Customer service people know things about products that product development doesn't know.
One customer wanted to know how to install the product keys for several products. While one product referred to the keys (which software manufacturers use to ensure their products are purchased legally) as "product keys," another called them "license keys," and yet another didn't appear to have any keys. (The latter product had embedded keys, which the customer service rep explained to the customer.) As the article points out, these kinds of interactions are not easily captured in coded applications, and thus are not typically shared with product development.
Gathering this kind of feedback should yield tweaks to make products easier to use and/or improved online documentation. Scott said he plans to make such sessions a regular part of his routine.