At Link Labs we’ve helped dozens of companies, large and small, create, launch and scale their IoT products. This includes safety-critical systems like, Stanley, Black, and Decker’s Shelter Lock control system and large scale, distributed Smart Meter systems.
Here are a few of the important lessons that may not be so obvious to teams just starting out on the journey to create IoT products.
1. Don’t optimize for cost in your prototype, build as fast as you can.
Cost is a very important driver in almost all IoT projects. The business case for an IoT product often hinges on the total system cost as it relates to incremental revenue or cost savings generated by the system.
However, optimizing hardware and connectivity for the cost is a difficult and time-consuming effort on its own. Teams are often forced by management to come to the table (sometimes as early as the ideation phase) with solutions where the costs are highly constrained.
A better approach is to build “minimum viable” prototypes to help flesh out the business case and spend time thereafter building a roadmap to cost reduction.
There’s a tremendous amount of learning that will happen once real IoT products get in front of customers and the sales team. This feedback will be invaluable in shaping the release product. Anything you do to delay or complicate getting to this feedback cycle will slow getting the product to market.
2. There is no IoT Platform that will completely work for your application.
IoT Platforms generally solve a piece of the problem, like ingesting data, transforming it, storing it, etc. If your product is so common or generic that there’s an off-the-shelf application stack ready to go, it might not be a big success anyway.
As we shared in lesson #1, create some basic and simple applications to start, and build from there. There are likely dozens of factors that you didn’t consider like provisioning, blacklisting, alerting, dashboards, etc. that will come out as you develop your prototype.
Someone is going to have to write “real software” to add the application logic you’re looking for, time spent looking for the perfect platform might be wasted. The development team you select will probably have strong preferences of their own. That said, there are some good design criteria to consider around scalability and extensibility.
3. Putting electronics in boxes is harder and more expensive than you think.
Industrial design, designing for manufacturability, and design for testing are whole disciplines unto themselves. For enterprise and consumer physical products, the enclosure for the electronics plays a heavy role in how the product is perceived. If you leave the industrial design until the end of a project, it will show. While we don’t recommend waiting until you have an injection molded beauty ready to get going in the prototype stage, don’t delay getting that part of your team squared away.
Also, certification like UL and FCC can create heartache late in the game, if you’re not careful. Be sure to work with a team that understands the rules, so that compliance testing is just a check in the box and not a costly surprise at the 11th hour.
4. No, you can’t use WiFi.
Many customers start out assuming that they can use the WiFi network inside the enterprise or industrial setting to backhaul their IoT data. Think again. Most IT teams have a zero-tolerance policy of IoT devices connecting to their infrastructure for security reasons. As if that’s not bad enough, just getting the device provisioned on the network is a real challenge.
5. Don’t assume your in-house engineering team knows best.
This can be a tough one for some teams, but we have found that even large, public company OEMs don’t have an experienced, cross-functional team that covers every IoT discipline and is ready for a new product or solution innovation.
Be wary, your team won’t always know the best way to solve technical problems. The one thing you do know best is your business and how you go to market. These matter much more in IoT than many teams realize.