IoT platform lessons learned

While we at Next Mile certainly have opinions about IoT and technology in general, we’ve received astonishing news that our opinions aren’t the only ones!

When most technologists think about IoT, they tend to put one of two things at its center: the device or the platform, with connectivity in a distant third (only wireless carriers put connectivity at the center). Of those, platform is the least-understood, given that a. the fewest people work on them and b. the technologies they employ are not well-known to device-focused engineers.

“How is it these people aren’t making money hand over fist!?” — A firmware engineer wondering why the platform they chose shut down

A little while back, we interviewed customers, allies, friends, and vendors about their experiences with IoT technology, operations, product management, marketing, and sales. Here’s our synthesis of the top lessons they—and you—have learned about building, running, and selling IoT platforms and platform-enabled products. This is what it’s like to live and work in the IoT platform world.

Technology

Engineers who build and maintain IoT platforms usually encounter problems of the technical, non-functional variety, meaning that platform functions rarely give them heartache, but something about how their platform delivers said function(s) causes their consternation:

Prepare for bad citizens. Clients may be new to building IoT products, so issues like devices accidentally DDoS-ing the platform happen more than you want.
Establish robust device/client management system(s) that identify and alert you (and users) to potential issues and preclude runaway billing and platform instability.
Understand that your platform consumes a constant firehose of data. Employing the fastest data storage mechanism may feel prudent, but each piece of data must then be related to a device/location/customer/user to become useful information when aggregated upstream.
Be wary of relational data. NoSQL and similar data storage solutions claim to be fast and may tempt you, but putting relational data into a non-relational database comes with a new set of problems that often cancel out any potential performance gains.
Carefully queue incoming device data. Process queueing helps deliver fast response times, but to be effective, you’ll need to simultaneously employ systems that prevent the queue from backing up.
RESTful and microservices may not be the right fit. REST and many other commonly known web patterns may work well for some parts of your platform, but not all. IoT is still new enough not to fit perfectly into existing web paradigms, just as it more clearly doesn’t often fit into existing firmware programming paradigms.
Don't reinvent the wheel by any means, but don't let a strong attachment or opinion about how connectivity "should" work stand in the way of trying something new. Example story:

“One common pitfall I have watched time and time again with both REST and microservice architectures is systems running out of TCP connections/resources due to new connections being opened faster than old connections get garbage collected. This frequently happens internally as a result of 1 device payload spinning off several internal operations within the platform. Alternatively, long-lived connections between internal services could solve a lot of these issues."

Adopt a "load test first" mentality. Try a few different configurations to see truly how much traffic you can push through each prototype architecture.
Don't do load testing on production. Instead, spin up a separate environment through some form of repeatable infrastructure tool allows testers to break something that doesn't impact your customers, or your developers in a way that yields isolated and pure results. It doesn't have to be the exact same scale.
Don't marry a single language or technology. The IoT landscape especially is still changing, and the development process is long. Be prepared to change with it.

Operations

Fortunately, operating an IoT platform works similarly to operating other large custom software applications or assemblages of commodity infrastructure. DevOps, finance, and IT should know:

Engineering and technology operations must stay tight with the product owner. However you accomplish it, the engineering group and the product team can’t lose their connection during the development cycle. In several cases, product failures occurred at an especially high frequency with remote teams located in different locations and timezones, even during the “everyone-remote” world of the pandemic period.
It doesn’t take an army. If your founder doesn't believe that his or her team can execute the vision or perform the work, spare the world and don't hire an army of staff!
Cost accounting for an IoT platform is ridiculously difficult. The bills most platform companies face make profitability calculations borderline impossible. Labor is the easiest input, with most others nested layers deep or abstracted by the difference between the platform provider’s approach and their infrastructure provider’s ruleset! Think “server time for your custom script(s) on a per-request basis for feature X.”

Offering

IoT platform product managers face a twisted thicket requiring constant growing, tending, pruning:

Respect the problem and solution. A platform that is a "toolset for makers" without a strong plan for UX, customer success, and onboarding only serves to break your customers into technology jail.
Avoid building features the market considers mature. Buyers have a strong opinion about the way these features should work, an opinion you'd waste effort overcoming.
Align platform features with buyer stages. This could manifest as the buying process, buyer maturity over time, features required with scale, features designed to address common problems that occur over time, even corporate stage gates. It’s some kind of alignment instead of random development.
Social features may have a role. Unexpectedly (or extremely expectedly), sharing- and invitation-oriented features allow tinkering engineers to share their work with purchase-driving executives.
Replication rules. The ability to clone and transfer setups, configurations, and profiles impacts the perceived workload your product places on the customer.
Feature creep inevitably alienates customers. Most products develop into a niche, and those that don’t either do everything or die off. Some enterprises are better off building their own IoT platform to handle their unique-to-them array of use cases, so better-designed IoT platforms and utilities ultimately make that effort easier for them.
Please decide where you fit. Some IoT platforms make sense for PoC development, others are a better fit for large-scale use. Who are you going to be?
Know when you're faking it. If the platform can't support a customer solution without constant fire-drills, burning the midnight oil, and a dependency on internal professional services/support to perform day to day tasks—you're faking it.
Be ready to re-evaluate. One engineer told his product manager, “Look, I can rebuild most of this platform in a month using Amazon services." This wasn't a joke, and he spun up the basics in less than five hours. IoT platform product managers may need to throw out months of previous work if and when something better comes along.

Marketing

Marketers find IoT platform positioning and messaging challenging because the audience is rarely clear or uniform:

Customers pay money for an outcome. Nobody is shopping to buy a platform. They need what it does, not what it is.
Know who really needs your software. you'll end up chasing your tail if you put too much focus (and development effort) on addressing "the Enterprise". A quote from one provider: “The customers with the most need (and willingness to pay for external help) are looking at platforms as a shortcut/cost savings strategy because they don't' have the engineering and development staff to do it on their own, which meant medium-sized businesses for us.”
Doing, or considering? Choose your prospecting target carefully and message precisely: do you want people doing IoT today, or people about to do IoT? “We thought we wanted makers and new products, but we’re a better fit for folks replacing old systems.”
Ask for referrals when prospecting. No amount of online research ever finds "the guy" because companies usually ask the most web tech-savvy engineer to drive their IoT program. That could be anyone!
You may need to incentivize change. If there is no plan to incentivize your only subscribing customers off the previous version of your platform onto your new one, they will never leave it. Improve your current/old experience instead of building something from scratch unless you’re ready to push hard.
Your platform name may hurt your search ranking. Don't give your IoT platform the same name as something more searchable like a place, a car, or a process. If you don't care about people being able to find your documentation/information on Google, then disregard this one!
The Ptolemaic view of the market doesn't work. "Every time we looked at the market with ourselves at the center we failed. Our potential clients didn't need to see themselves from our perspective, they needed us to see ourselves in theirs."

Sales

If you’re selling an IoT platform, whether it’s a custom build, a SaaS product, or something woven together from Big Tech webservices, keep the following in mind:

Every choice you leave open becomes an objection. “When we started, people could use any gateway with our platform. That was too many. We narrowed it down to five. That was too many. Then we narrowed it down to two and that was too many! Now we just say ‘here, use X’.”
The CIO’s your likeliest buyer. Contrary to the engineering-centric beliefs of yore, platform choice is a CIO sale, not a CTO sale, because most businesses intend to weave platform into the fabric of their operations.
Failure cascades throughout organizations. Early failure with IoT turns into a major hurdle for any future applications of IoT. "We tried that already."
Leverage or differentiate from incumbents. In the 2010s, Amazon and Microsoft practically gave AWS and Azure away to embed themselves in the enterprise. Now they’re stuck in, siphoning margin from atop their enormous scale. In order to succeed at all, you need to either add value to their products or differentiate from them.
Value remains elusive and difficult to calculate. Businesses of all sizes struggle to figure out the cost savings and profitability potential for their connected products and the resultant ambiguity makes it difficult to purchase anyone's platform.
Tears for tiers, part 1. "Funnel" behavior—customers progressing from a small purchase to a medium to a large—is mostly fantasy. While it can happen, 95% of platform customers’ spend will never deviate from where they begin.their initial moving up tiers or growing into a bigger monthly spend was an illusion.
Tears for tiers, part 2. Worse, free tiers have been a waste of time, with free user pools generating a minuscule number of paying customers.
Tears for tiers, part 3. Upselling into higher service tiers will be an exercise in futility, especially if your tiers are defined by feature availability. Most customers start where they expect to finish.
Cross-selling into associated features can work. If you’ve got an IoT security suite, data analysis platform, visualization system, etc., that gives your customer success team a legitimate way to increase lifetime value (to you) provided your customer actually uses your system.

Platform Life is a tough life. Consider this is your weekly exercise in empathy!

IoT platform choice is always expensive and entails many long-term challenges and trade-offs. If you need help architecting or selecting your next IoT platform, contact Next Mile for context-sensitive, realistic advice.