Part Six

Lean Product Development for the Internet of Things

More than one-third of all IoT projects never make it past the proof-of-concept phase, according to a 2017 Cisco report. It’s a sobering statistic, considering that same year, 73% of executives were, at the time of the poll, either researching or launching an IoT initiative. That’s a lot of failed products, not to mention hundreds of millions of dollars down the drain – most of which could have been avoided with a specialized product development practice.

The tenants of Lean

Lean product development practices allow engineering teams to quickly optimize products while simultaneously shipping new features, eliminating waste and continuously improving the quality of the deliverable. This process allows software teams to rally behind a philosophy of ‘done is better than perfect.’ But creating connected products is far more complex than software alone.

Rapid iteration in IoT and the dangers of moving too quickly

In theory, the goals of rapid, iterative development, constant optimization, and waste elimination are the same for IoT as in traditional lean product development. But in reality, the complexity and potential for wasted time and money grows exponentially. The success of connected products hinges on their hardware design, and early mistakes can be extremely costly later when materials sourcing, supply-chain management, and retailer negotiations begin.

Hardware teams live by a hard rule of ‘measure twice, cut once’ because manufacturing and supply chain considerations are incompatible with a ‘ship now, fix later’ mindset. Once a product moves into manufacturing, iteration on hardware and firmware must cease. Changes made during manufacturing mean that your assembly line sits idle, you have to quickly re-allocate your engineering team, your bill of materials cost increases, you face component shortages, and you introduce risk due to lack of testing and long-term validation of changes. These changes are likely to add months (if not years) onto your development time.

The failure to appreciate these critical decisions will ultimately undermine your execution, and greatly increase your risk of spending an eternity in a special kind of hell: Prototyping purgatory. But this doesn’t mean that iteration must stop completely, or even slow down – it just means that certain decisions must be thoroughly tested and solidified up front.

Definitions

1. POC: Proof that an idea is feasible.

2. Prototype: A working model for delivering an experience to the consumer.

Where to start: Proof of concept, prototype, or MVP?

While sometimes used interchangeably, each is actually a critical phase of the product development lifecycle. Each is optimized for for different challenges, and all three are necessary to create a successful IoT product. Proofs of concept identify technical and delivery risks and test a hypothesis of a solution, without integrating or testing anything else that isn’t related to that specific risk. In a prototype, the learnings from all of the proofs of concepts are merged into a development device that allows multiple different teams to collaborate on iterative product development, with each successive prototype incorporating the new design and learnings from each of the teams in order to test the entire product as a complete system. Once a prototype meets all of the design criteria, including user testing, quality testing, manufacturability analysis, and failure mode analysis, it can be considered an MVP and released to manufacturing.

Consider a smart shelving unit that tracks inventory levels and out-of-stock events. Proofs of concept for this product include the sensors that track weight, the mechanism that pushes products forward on the shelf, and the physical shelf itself. These POCs would then be assembled into a working prototype, as software teams build an ‘essentials-only’ ecosystem around it, including user touchpoints, an IoT platform, data collection and analysis, and more. Finally, the MVP is created, expanding the prototype to include functions such as onboarding, user management, and any other features necessary for this product to be considered usable.

Consider each of these deliverables as distinct development phases – all rapid, iterative, lean, and designed to dramatically reduce risk.

Create your proof of concept(s)

Do not rush this step. This phase is designed to determine whether or not an idea is feasible and, if so, how to build it. Hardware and software teams should begin delineating which functionalities will fall to which disciplines, and mechanical and hardware engineers should work with industrial designers to create multiple proofs of concepts – one for each of a product’s necessary hardware components.

While solving for as many narrow hypotheses as possible, hardware teams must begin de-risking, solving for a multitude of product considerations such as connectivity, sensor selection, firmware design, mechanical design, and industrial design. They must devote time to testing and experimentation to ensure the best possible solutions, because at the end of this phase, each POC should satisfactorily validate a single, high-level product need.

De-risk while building a prototype around your POCs

Now that each hypothesis has been answered and key product considerations solved for, the POCs can be assembled into a working model of a single product. This prototyping phase allows multidisciplinary teams to work out the kinks of a product’s key features while putting together the physical and digital components.

Two separate, iterative development tracks are necessary at this phase: One that encompasses industrial design and hardware engineering, and another for UX design and software engineering.

In each of these tracks, the two disciplines will design and build separately before coming together to test and iterate. This cycle must happen multiple times to ensure a fluidity of experience before the two tracks come together. At this point, the team must test the hardware, software, industrial design, and UX design together and iterate again. Then, the two tracks must break off once more to continue iterating and testing separately. If it sounds like a lot of work, it is. But without multiple rapid rounds of iteration, your team is far more likely to miss areas ripe for optimization.

At this stage, it’s ideal to work with local, small-batch manufacturers to keep costs down and turnaround times high.

Create your MVP and prepare for manufacturing

Now that you have your prototype, it can be fleshed out as an MVP. This is where all additional components needed for a sellable product are created, including features like user management. Iteration continues during this phase, but hardware and materials considerations must be finalized at this point to begin preparation for real manufacturing and supply-chain processes with large-scale distributors and manufacturers. Thorough cost-benefit analyses must be performed to ensure the best solutions for the best price.

Don’t get discouraged

With careful planning and iterative processes, you can ensure your connected product makes it to market. It may seem like a long road, but the ends justify the means – it’s the only way forward in a connected world. “IoT is seen as the future of everything,” says Stephan Fabel of InformationWeek, “from smart-city advances like traffic congestion relief and intelligent street lighting, to better energy management, to industrial robotics and asset tracking, to monitoring of medical equipment and patient condition (not to mention the array of home consumer applications).” (Fabel, 2018)