Ever since I was a kid, I’ve had a love/hate relationship with writing.
Don’t get me wrong, I love it more than I hate it. It’s just that I invariably have a hard time getting started. I sit down and usually struggle – there are so many ideas, and they all seem to compete for my typing attention. I worry if anything I’m saying is new. I struggle with which ideas to combine, which to eliminate, which to elaborate on. In the end, there is only so much time and I only have ten fingers. And I’m not a very good typist.
Over the years I’ve learned innovation and product development are like that, too.
In my twenty-plus years in corporate technology research and development, and now working with a wide variety of clients, I’ve observed the same pattern: companies really have a hard time figuring out what to make. The front end of development – the cradle of innovation – is indeed fuzzy. Much fuzzier than is needed – or is healthy.
This problem is not new, even in high tech. I recently re-read my old copy of “Developing Products in Half the Time” from 1991, and although the examples are dated, the premise rings true: companies spend lots and lots of time, effort and money in the front end of development. Much more, in fact, than they know, since the wasted effort at this stage is hard to measure.
In a recent Businessweek cover story, Michael Mandel lamented “The Failed Promise of Innovation in the U.S.”. In his article, Michael cited a raft of statistics showing a disturbing lack of real world impact for many of the highly touted innovation breakthroughs of the last decade, including alternative energy, genetic research, and next generation internet technologies. But I suspect it’s precisely the failure to manage the innovation process that results in the poor return on investment many companies find in advanced technologies.
Actually, I think there is probably nothing wrong with America’s competitiveness in technology, or the pace of technological advance. Instead, it’s this front end struggle with how to reliably translate investment in advanced technology and “research” into profitable products and services that people want and need.
My experience definitely resonates: poor front end execution is a big problem.
It’s strange how the concept of execution gets linked almost solely with operations. The image of the “good manager” – the General Electric archetype – is typically associated with running mainline corporate businesses, taking advantage of efficiencies, optimizing and streamlining operations, squeezing improvement from the supply chain, and so forth. In contrast, the term “manager” is almost a dirty word in popular innovation circles. You almost never hear about execution in research, or advanced development, or design.
Don Norman alludes to this lack of execution in several of his books. In “The Invisible Computer,” he describes what he calls a “human centered process” for product development, starting right from the ideation stage in the fuzzy front end. While I like the way he ties technology, marketing, and user experience together, I’m not sure completely reorganizing the company is a realistic solution for better front end execution. There are lighter weight ways to get things done. But Norman’s call for a holistic design process in the front end resonates – he even cites Contextual Design as an example of a development process that brings all three legs of innovation together.
In my previous life, I worked to establish an innovation process based on users within a large company’s technology research organization – and now I work with clients doing the same thing with Contextual Design. The experiences throughout are remarkably similar. A funny thing happens when you introduce a stepwise process in the front end – people really value knowing what comes next. While there can certainly be a good deal of doubt initially that a “process” (bad word, after all) can speed things up rather than slow things down, it’s almost like a relief for most people that they don’t have to argue about what steps to take next. Teams we work with tell us having a way to structure conversations about ideation and prioritization based on real-world data is a huge time saver. The trick is not to be too rigid in order to not kill creativity – but that’s a topic for another post.
I’m not saying that Contextual Design is the only way to create new products. But I am saying that knowing what to do – or having a set of ways to know what to do – saves time and energy in a crucial part of product development.
Putting one foot in front of the other is the only way to walk – or run.