Ensure that the business case makes sense. The product has to make sense and have business value, not be a platform to connect things. Make sure the customer understands the product’s value. If it doesn’t make sense to you—and the customer—it’s unlikely you’ll build a good product, Pisani said.

Take the friction out of device onboarding. When you introduce IoT devices to an environment, it should be a turnkey process. “Every step that adds friction besides plugging it in or turning it on adds confusion and reduces adoption,” Pisani said. That friction “turns into returned product or product that never gets implemented,” he said.

Penetration test early and often. Pisani said that he has worked on several IoT projects that were ready to ship –only to be met with critiques from the security and compliance team, which would weigh in suddenly with a vulnerability or issue. “That’s a difficult mistake to recover from at the end of a project cycle,” Pisani said.

Field-test early and often. You can’t launch an IoT project in the echo chamber of your developer testing phase. “You won’t know how your product starts to work sitting on a bench with the same engineers that wrote the code,” Pisani warned. “Find those [issues] errors early and often makes it much easier to project-manage and gives you a chance to sleep better at night if you aren’t stuck trying to fix a bunch of issues at the last minute.”

Take CI/CD process from serer side team sand integrate into hardware. Simulate your hardware the best you can. Run simulations on your hardware. And keep track of how your devices are running without reboot. It’s easier said tham done. Software teams usually have a leg up on continuous process. Run those simulations on your hardware. Simulate your hardware as best you can. Run nightly hardware builds, find memory leaks, process issues.

Get started with what you have. Despite all the new technology that’s released on a regular basis, “The IoT industry changes too fast, so you have to get started with what you have,” Pisani said. At he same time ,understand integration issues with chip updates or components are incompatible. Make sure you are integrated with vendor roadmaps.

Don’t throw behind the runner. As an analogue from baseball, Companies start out with an idea and can’t evolve it fast enough. “:Once they prototype, do some building, make a few more changes, then do pen and field testing, you are further out than you thought,” Pisani recounted. “Now you’re 18 months in and a whole bunch of new chip capabilities s came out.. Make sure you have an evolution path and move one generation forward without a complete redesign and rebuild.”

Optimize data payloads from the outset. In some projects, interfaces aren’t defined at the outset, but data flows might start on Wi-Fi, then move to cellular, then use 2.4 Ghz protocol. Identifying the proper data load for each connection is important. It’s easier to add to an interface than it is to take away from an interface once you realize you have a problem.

Plan for network instability and signal interference as you design features and capabilities. When there is a network drop you can recover all the data that was being processed while network was down. Make sure you have time stamps so you can deliver the data and reconstitute the data on the server side if it gets delivered out of order. Have the diagnostic tools and logging capabilities so you can debug and troubleshoot rather than take stabs in the dark on the problem.

Get started with these ideas tomorrow.