Design Thinking for IoT in the Product Development Process

Since Cooper lit the torch with a basic process construct that started at approval and ended at launch, elegance has been added. The early 1990s brought in a product definition phase which was preceded by a concepting activity. The late 1990s saw improvements for technology-push products, rapid commercialization, and the formalization of portfolios at every phase of the pipeline.

The early 2000s ushered-in advanced development processes and innovation skunk-works organizations which were separated from product development and added refinements for technology-push. The late 2000s integrated intellectual property (IP) to generate, protect, and monetize it through licensing and sale. In the early 2010s, we made it lean. Many are still working on IP and lean. But—never a dull moment—the IoT is arriving faster than many had imagined.

Currently, few companies have gone through their product development process from stem to stern to prepare for the IoT. Modifying business and technical processes, and using them until they become the norm, takes several years. IP is a great example of this. There is urgency, however. If predictions that there will be hundreds of billions of connected devices by 2025 are true, it would stand to reason that the companies that design "IoT-ready" products would have an advantage.

What then are the implications of IoT-ready products on the product development process? Let's use a bit of design thinking to look for places to tailor the product development process for the IoT. Right now, the value of the product is largely about the product itself. In the future, the value of the product will also be its information content and its ability to aggregate vertically and horizontally in the cloud. A well-designed process can go a long way to enabling "IoT capability." My previous column discussed the importance of sensors. The better the source data and the less it costs, the better the resultant value. That is a good starting point.

One of the first considerations for a new product is its portfolio fit. Does the product fit with the company's IoT goals for the portfolio, product line, or family? Has the company established IoT goals at these levels yet? From a technical view, do architectural rules and guidelines exist for incorporating sensors, wireless, flash, and other possible "IoT enablers" in a systematic way?

For project plans and approval decisions, do business plans address "IoT ability" in a consistent manner as is done for other variables that have become part of every business plan? Are there implications for bills of material, design reviews, and other structural and checklist documentation? Chip and PCB designers have been provisioning for magnetic fields, cross talk, and current surges at the micro level. In the future, fully connected products touting 100% up-time will have many of these same design considerations at the macro level—and associated safety issues.

Alpha and beta testing with customers and focus groups is sure to bring in a whole host of new types of inputs, slowing down products that are well along in development. As one nears product launch, technical literature and marketing promotional materials will have to address IoT capabilities in a consistent way. My guess is that many companies will soon develop an "IoT branding" strategy. These branding strategies will mature with time, ultimately emanating from architectural principles early-on in the process, as enabling the IoT also approaches its own day-to-day norm with product developers.

The IoT will be no different than other product development process improvements. They all had their "what does it all mean?" beginning. Companies that eagerly addressed early-market uncertainties were the first to become proficient. Other companies then copied their practices. But, the eager ones got a three- to five-year head start.