My husband, who is a stereotypical Luddite when it comes to technology, often points out that certain products have gotten so intricate and complicated that they were far more prone to breakdowns than their simpler predecessors. A great example is cars: now, not only do you have to worry about the basic mechanical whys-and-wherefores of keeping the engine running, you've got to worry about whether the sensors (aka idiot gauges) that warn you about things really WILL warn you about things.
He absolutely has a legitimate point, of course, and the issue of the technology complexity that is now part of the most basic product design is the subject of an essay in the March issue of the McKinsey Quarterly called, "Tackling IT complexity in product design."
Going back to my example of the car, the McKinsey article reports that the average number of technology-enabled control units in new vehicles is now 80, up from 20 a mere five years ago. Mobile phones boast twice the number of IT-related updates per year, roughly 40, than they did back in the year 2000.
The creates big challenges for the business world: escalating product design and development costs, along with more costly support considerations. There are other fundamental problems: as components or modules become more specialized, can they be reused across different product lines? Does it whack out the assembly process? And so one.
The world of smarter devices and products means that manufacturers of all sorts need to rethink their development and design organizations, according to the essay. There are a number of simple steps that companies can take.
Aligning the goals of the business with the goals of engineering EARLIER in the process. Here's a simple, seemingly obvious suggestion from the article that often is overlooked:
"A good architecture has a number of important characteristics. It is modular, allowing sections to be tagged, stored, and applied in different products. It is built on standards, providing for easier integration. It is configurable, letting one system serve many customer requirements. And it is updatable, allowing new features to be implemented without any need to discard large parts of older releases."
Get engineering, marketing, product design and other teams to talk to each other. Yes, probably easier said than done, but pricing considerations sure better be part of product design decisions from the get-go. Why aren't they? You shouldn't be concerned with building the best, you should be concerned with building the best for your customers. There's a difference.
This post was originally published on Smartplanet.com