"Doing" innovation: technique or org design?

I've been answering questions lately about how you "do" innovation and "voice of the customer." What are techniques? How do you gather data? Convert the data into new product ideas?

Those are interesting questions, certainly, but there are a lot of resources out there that present valid frameworks and approaches for doing innovation. The trick, of course, is to be able to apply a framework or approach to a real situation in the messy real world of new product development.

An equally interesting and important question, and one I don't hear much, is "How do you need to change the organization to support innovation," rather than focussing on the individuals? Personally, I think that's the harder challenge, since it requires more organizational change and can take managers out of their comfort zones.

Look, sometimes all you need to do to get individuals to innovate is to give them some tools and get out of the way. But setting up and organization that can catch the ideas generated by its employees can be a real challenge. That's the other side of the innovation equation, and the one that's less talked about.

Is "networking" just a different name for something else

I've been thinking a lot about this "networking" thing--the person-to-person kind. I think I've been doing a lot of it lately, although I'm not really clear on the definition. As far as I can tell, if you are working with people, doing your job successfully and people see it, and helping people when they need help, then you're networking. I think "networking" is just a fancy term for "doing the right thing" with respect to your business and personal relationships. Maybe there's more, but I'm missing it.

Appropriateness as a criterion for speech IVR

Someone who is putting together a conference symposium on "the impact of speech technology on society" pinged me and a big bunch of other opiniated people on this topic and asked for input. My quick effort to be an IVR/speech industry forward-thinker follows.
--
Where the IVR industry will go is away from homegrown, do-everything speech recognition systems running on a company's own platform to highly specific, appropriate applications running on hosted platforms. A lot of companies have spent a ton of money on speech development tools and handed them to IT people who figure that speech is like every other technology - you just hack on it until you get it right. When it doesn't work the companies blame the technology, and the IT department (or communications department) makes excuses.

Examples of highly specific, appropriate use applications are things like name capture and city and address capture. The applications that do this well are created by speech rec companies that understand what they are doing and design and test them for a long time, refining them for a long time. These small, self contained applications may be embedded in larger apps that may be DTMF only.

Hosting allows the speech vendor to gather an enormous amount of data from various companies' callers and use that data to improve their product. IT departments at individual companies don't have the resources or expertise to do that. Another specific, useful application is speech to text transcription. Again, a few speech vendors will succeed at doing this, but most companies don't have the resources.

The idea of speech recognition systems as giant, expensive opportunities to push an auditory brand at customers who call will go away.
--
"Appropriateness" is really something that is hard to talk to companies about. Once they've made up their minds about speech, based on some conversations you weren't at, it's very hard to pull them back and get them to think about whether speech is an appropriate modality for the IVR app they want to develop. I've tried to engage a number of people at companies, pointing out that a three-item menu of easily discriminable labels is a lot easier to implement and use if done in DTMF. No sale. After the speech decision has been made then it's full steam ahead, and anyone who says otherwise is simply engaging in "analysis paralysis."

PDMA: Cultivating product development careers

I went to an excellent panel discussion titled "Cultivating product development and management careers," hosted by PDMA Carolina Chapter. The panelists represented a wide range of companies. They had a lot of good advice for people trying to get into new product development, or those already doing NPD trying to move up.

After the panel discussion the panelists and attendees broke into groups and brainstormed on some of the topics that were raised during the panel discussion. Good event. Pictures of the event were posted online. Click on View CJ's Gallery, then select the product development careers gallery.

Remarks on The Management Myth

The Management Myth, by Matthew Stewart, is a harsh look at the management consulting industry. Stewart, a philosopher by training, took a job with a management consulting firm created by former McKinsey associates. His book, which began as an article in The Atlantic three years ago, describes the history of management consulting starting with Frederick Taylor and Elton Mayo and ending with gurus Tom Peters and Jim Collins.

It's tough reading if you're sold on the value of management consulting. The book is probably a lot more enjoyable if you've been on the receiving end of some new consultant-led management fad imposed from above by an unwary exec.

Fixing process problems in the UI

Most experienced UI designers will have seen this at least once: a client asks for a new online self service application and insists "we really want a lot of people to use it." Hey, when a client cares about usability of the application you're designing, that's a good thing, right? When you do your up-front analysis you discover that their existing process for servicing customers is awkward and unsatisfying for its users. You point out, reasonably, that in order to create a good self service application, the client needs to tweak its service process. "No," you're told, "we can't do that. You have to work with what you have." And then the kicker: "Just think outside the box." The client rep you are working with either isn't in a position to change its process, or doesn't feel the need to. You're stuck automating a bad process, and your design spirals down into a series of design anti-patterns, workarounds, and random attempts to fix the workarounds. And everyone loses in this scenario: the client, the customers, and you for delivering a bad application.