Your 8 most ruinous IoT technology decisions

In connected product development, IoT, and software in general, it’s rare for a single problem to completely destroy a connected product’s potential. Instead, mistakes stack up. They also feed parasitically, eating your product’s margin until resolved.

For review, connected product development tends to occur over three distinct phases inside a product OEM:

• 0-1: getting the first connected product on the market (not prototype)
• 1-2: connecting the second product (not line extensions)
• 2-n: connecting subsequent products and/or line extensions

As we stated last week, sloppiness in the first phase begets problems down the line. While errors arise at each phase, acknowledging said phases and your position in them will help you estimate the significance of each particular challenge and decision.

As with all IoT projects, resist the urge to sprint to the finish line. Constructive reflection is step one in preventing and minimizing ruinous IoT technology choices. We outline the 8 most onerous, non-obvious IoT technology mistakes below.

Consider a situation where everything goes according to plan:

• You have an idea for an app to control your device
• You connect devices to your app with a cloud platform
• Customers start using your product

What happens when you want to switch platforms? This may become urgent if you succeed faster than expected or you’ve underestimated the scale of your needs. We’ve seen this problem obliterate profitability multiple times (for you, anyway—your platform provider is quite happy).

With device traffic, you can create a proxy to make changes easier. Similar thinking works here, too except you also need to consider what’s in the cloud platform you want to replace.

The answer starts with an eyes-wide-open understanding of everything you’re getting from your cloud provider, and deciding whether you should own or abdicate that function/feature. Some examples:

• User accounts. This is vital data and activity, including authentication, authorization, and access control. If you have no place for this functionality you’re stuck where you are.
• User accounts again! Don’t forget boring stuff like password reset, suspensions or lockouts, account communication, GDPR, etc. These are critical user experiences that are ignored when done well, and rating-busters when done poorly.
• Asset storage. Less of a concern except that changing providers may mean new standards for routing, naming, encryption, and more. Simply moving files may not be possible or it may break a key experience.
• Logging. Always forgotten until your product goes down on Prime Day or during a trade show, then you’ll wish you owned your own application logs.

The list goes on. Your team will be able to build a list of every service/feature/function you need and determine the pros and cons of ownership. If you’re thinking ahead to phases 1-2 or 2-n, project your decisions into those phases and see how they hold up. If you’re rebuilding, our migration planning exercise provides a framework for uncovering work and cost.

You’ve heard the rationales before: “That’s close but ____.” “They don’t integrate with ____.” “We can’t change ____ in our process.” All feel convincing, and the executive narrative your team helps you write becomes seductively inevitable.

Soon, you’re standing in front of your CTO/CEO/COO, asking for an enormous amount of money to build something that your gut tells you is pretty close to _____ and should be achievable with _____. When they ask the (appropriate) question “can we do this by using something else?”, you swallow the undiscussed nuance and lingering questions, answer “no”, and your gut wrenches.

Trust your gut.

The answer to this is remarkably simple. Challenge your team to solve your problem without writing a line of code. Whatever it takes. After some grumbling and some research you’ll start to hear things like:

• “We could use _____ and tie it to ______. We’d only have to write a few things but could use the rest.”
• “It would be ugly, but we could try using ______ service.”
• “______ platform isn’t in our industry but solves our problem and has a white-label option.”

Once the MacGyver juices are flowing you’ll be a lot closer to your 0-1 phase answer. It won’t be exactly right, but your team will be starting from a place of pragmatism. Your bosses and your P&L will thank you.

Imagine a scenario where you pay for a resource by the hour, 24 hours a day, when your customers only access your service during business hours. For a physical store that could mean idle time makes up 66% of their cost. It gets worse in IoT—resources may be accessed a dozen times, but are stored (and paid for) for years.

This is the most common but avoidable product cost mistake, especially if you’re having something built for you. Any complex application built today is constructed in parts and stitched together, and each part has different associated costs to run or grow. For instance:

• Static data. Data that rarely (or never changes) can be stored as a file and cached for almost no cost, compared to a database that costs money to operate and access even if data doesn’t change. Just because a feature is used (accessed) does not mean it should be recomputed.
• Bundling data. Each time your application communicates you’re paying for two things: a. the connection, and b. the size of the transmitted message. The balance of message frequency and payload size can manifest significant costs (or huge savings).
• Case-specific architecture. IoT architecture can be counter-intuitive. Having a write and a read database sounds complicated and, frankly, duplicated. Ironically, having two single-job databases may be less resource intensive than one multi-function service. Not always, but that depends on your specific case.

Similarly, some aspects of your application may require significant resources to run but only while administering your product. Perhaps your program requires complex (read: expensive) computation to create a report, but once done, that report never changes. Offering that report dynamically means paying a premium price every time, even if nothing changes.

Early intentionality with your architecture can mean the difference between a system with low cost-to-scale vs. one with compounding price changes for each new product, customer, or region. Everything you pay for in 0-1 will need to be handled (or paid for again) in 1-2 and 2-n. Will you build on your previous architecture, rebuild it, or build another one?

The answer is to interrogate your application’s resource needs early. Go down in the weeds with your team and find ways to save pennies. They will add up quickly.

Despite every statement to the contrary, and despite every skilled tester added to the team, most connected product programs treat quality as a checkbox:

☑ Testing

We sympathize with this behavior a tiny bit: quality assurance and testing mean too many things. Most organizations base their IoT testing approach on the types of testing they performed in the past, applying familiar, hardware-appropriate methodology to their IoT stack, manifesting as a mixture of:

• Application-level smoke testing
• Hurried compatibility and integration testing
• Legal and regulatory review
• Application- or hardware-level acceptance testing of some type

It’s possible to operate for years with a testing amalgam that produces scads of bugs and tickets, but was never software- or IoT-appropriate. You’ll drown in bugfix work, yet somehow fail to raise the quality of the customer experience despite your effort.

The answer requires that you implement an IoT-appropriate testing paradigm. At a high-level, that should look like this:

• System-level functional testing. QA testers verify that each new function works from a user’s perspective. The bulk of their test plan should hit the whole system: firmware, hardware, cloud, app, network, etc. Avoid boiling the ocean by focusing this on new functions and edge cases.
• System-level regression testing. Create a regression test suite for your interface(s) (web or mobile apps usually) and run it as part of your release control process. Focus it only on core functions (as determined by inspection or analytics data)—maintaining a regression test suite for every corner case or little-used feature isn’t worth the effort. This should find big blockers before they light up your call center.
• Application-level analytics. You can instrument the key action→result function pairs accessed by your users. For example, to activate a fan, a user might tap the fan icon on your mobile interface. Ideally, the fan will a. activate and b. tell the app that it has activated. Capture that data and determine an acceptable success rate baseline and performance threshold. If they begin to deviate from an acceptable level, you’ve got a clue that something’s off, and know that becomes the difference between an emerging problem and an incipient one.
• Application-level functional testing. Standard testing behavior in software—have humans test your new features.
• System-level acceptance testing for major releases. Connected products have a long lifetime, and over the years, your experience conditions user behavior. Significant changes break their expectations even if everything works, so it pays to know ahead of time if your next release will cause a serious issue or merely upset your installed base for a while.

Your quality can benefit from engineering unit testing, but we don’t consider that a paradigmatic requirement.

We stated earlier that flexibility is expensive. This becomes more apparent the bigger your product suite gets but can be expressed in terms of multipliers.

• Product—1x$. Start with a single product. That means one codebase, one test suite, one documentation set, one OTA pipeline, etc.
• Models/SKUs—3x$. Now imagine your product has three models. That may still be one app codebase, but now you have 3 different firmware versions, which means 3 test suites, and 3 OTA pipelines.
• Sub-models/more SKUs—9x$. In order to deal with supply chain challenges you decided to support two different chipsets in your product as well as two different memory configurations. Now you could have 12 firmware variations, test suites, and OTA paths.

Modularity has created a scaling nightmare that will only get worse with new models, supply constraints, etc. Each fragmentation multiplies complexity.

The answer isn’t simple or easy. It happens in two conversations:

• Starting with no instead of yes when considering change. A chipset shift may save you $0.46 per unit on the BOM. but cost 1,000,000x that in additional, perpetual overhead somewhere downstream.
• Completely understanding a change. This is hard but vital. Assume you are NASA and you’re launching a rocket. Every member of the team must express the cost of a change to them before you’ll see the whole picture completely.

We’ve seen modularity turn successful products into hidden cost quagmires more than once.

Should you provide over-the-air (OTA) updates to your connected product?

It’s impossible to measure the precise cost of this decision. If a connected product breaks and you can’t fix it, are you willing to pay replacement costs or suffer an unhappy customer?

If yes, you may not need OTA. But you need to be certain that you’re willing to live with:

• Solvable, bug-related poor ratings
• A stream of returns that could overwhelm profitability
• A product-killing recall
• Bad press about any of these can drag down adjacent sales

If not, OTA will make your life both easier and harder. OTA is often complicated and complex. It requires a multidisciplinary delivery approach, is highly contextual to the product, and can become onerous to the user if done poorly. OTAs become a significant management and workload burden with large fleets, especially if you’ve got multiple SKUs. It’s also (famously) an attack surface for ill-intentioned hackers.

Thoughtfully executed OTA can help you solve individual and fleet-wide problems quickly and quietly. They also lead to a place of both necessity and temptation: the ability to deliver new features and changes to your product experience. We’ve seen this power wielded both well and poorly, often at the same time. Good examples of feature-enhancing OTAs include life-extending updates and compatibility updates. OTA-driven features create challenges when they change how the device itself works, how it behaves for users who’ve been conditioned by it, and non-sequitur additions that fall outside expected behavior.

The answer is that the value of OTAs will be specific to you, your market, and your product. Consider this feature very carefully.

In the rush to build, we prioritize delivered functionality. Most engineering teams prefer to deliver features and, in software, often consider the job done after deploying a given feature. That mentality will get your connected product built, but it will not make it good at a better rate than chance.

The answer is to recognize that the leap from software or hardware engineering to IoT and systems engineering requires one massive, difficult change of mindframe: engineering for non-functionals deliberately. Common IoT non-functionals include:

• Execution needs
  • Usability
  • Performance
  • Accessibility
  • Reliability
  • Availability
  • Security
  • Compliance
• Evolution needs
  • Scalability
  • Compatibility
  • Portability
  • Reusability
  • Flexibility
  • Maintainability
  • Testability
  • Survivability

In systems engineering and IoT specifically, non-functional pieces break user satisfaction more readily than missing features. You don’t have to cover every case, but you do need to treat non-functionals with equivalent or greater weight than your connected product’s feature set.

A simple experience that works beats a complete experience that doesn’t. If your product had one feature, but you solved for the above 15 non-functionals, you’d have a better offering than one with 15 features.

Surprise! It’s vendor lock-in again!

Lock-in usually causes the most organizational agony of these 8 decisions, and it’s a broad enough topic that we wrote a separate article about minimizing vendor lock-in last week.

The answer lies in understanding that vendor lock-in will exist in your IoT infrastructure to some extent, but maximizing your control over it early per our recommendations will serve you best long-term.

Next Mile helps businesses navigate the complexities of IoT from 0–1, 1–2, and 2–n. Contact us to de-risk your IoT infrastructure and create a sustainable operation for your connected products.