The IoT industry has spent years measuring its own success in numbers of devices. Connected devices deployed. Devices under management. Devices projected. It’s a satisfying number to put on a slide, and almost entirely the wrong thing to measure.
Connectivity alone doesn’t create value. It creates infrastructure. There’s a meaningful difference, and a lot of organizations have learned this the expensive way.
The wave was bigger than people remember, and it started earlier. Around 2012, large enterprises looked at the smartphone and cloud era and had a collective realization: startups were moving faster than their own large internal IT operations could. Boards started asking, ‘who owns innovation?’, and org charts answered with new titles: chief innovation officer, director of digital transformation, innovation lab director.
The wave crested somewhere between 2015 and 2018, fueled by board-level mandates to pilot anything that felt like the future and consulting firms happy to help spend the budget doing it. IoT, AI/ML, blockchain. This was the era of technology innovation initiatives largely driven by FOMO.
By 2018, skepticism was already growing. Too many PowerPoints and pilots, and too few outcomes anyone could point to. Those ‘innovation’ and ‘transformation’ titles got absorbed into product organizations, CTO offices, and business unit leadership, where accountability was harder to sidestep.
That era wasn’t a total loss. For every pilot that burned budget and goodwill and quietly got shut down, connected solutions were embedding themselves into logistics, maintenance, HVAC, and commercial and industrial operations where they’ve since stuck. The industry learned things. Expensive things, but things about connected things.
The problem is that some organizations didn’t get to the learning part. They ran one initiative; it went nowhere, and now ‘we tried IoT’ is a full sentence that ends the conversation. Those are the ones still wondering what they would do differently next time.
Back then, consultants were frequently called in to help companies make sense of their IoT projects. The expectation of the role, often unstated but clearly implied, was to help clients spend the money. What those consultants actually spent most of their time doing was pausing, pivoting, or walking clients away from more than half the projects that leaders or engineering teams presented. The problem was rarely a technology problem; it was a people problem that wasn’t defined well enough to justify building anything. Slowing down to speed up. Asking better questions. Involving the right people.
Pushing against ‘we need to build a connected thing because a corporate initiative mandated it’ wasn’t always a popular position. But it was usually the right one.
There were far too many companies that gave into the hype and jumped right into the deep end, and ROI was treated like a meme: Step 1, invest in connected solutions. Step 2, collect all the data. Step 3, … profit. Nobody lingered enough on step 2.
Now, we have a chance to make things right. Here’s what that expensive era and its lack of progress taught us: Before a single device gets provisioned, three questions should have real answers. Not in a slide deck. Actually answers, delivered by people who will live with the results.
Who is the audience for the data? Not “stakeholders.” Specific people. A field technician making a decision under time pressure needs something completely different than an executive reviewing a weekly report. If you can’t describe the person who will look at the output of this system, you’re not ready to build the system.
What is the context they’re operating in? This one gets skipped constantly. A sensor that measures bulk propane tank levels across thousands of tanks sounds useful, until you realize each location already has an HVAC controller that monitors runtime. You can calculate BTU consumption and extrapolate fuel usage from data you already have. Sometimes the right sensor is the one you don’t buy.
What is the purpose, the actual why? Not the business case document version. The real why. If you can’t describe a specific operational problem this solves, you’re going to hit resistance at adoption. Skilled people with established ways of working don’t change because change is theoretically good. They change when you show them it removes the task they hate, eliminates the paperwork, or means they don’t have to drive two hours to read a gauge.
Ask that last question honestly, and it leads somewhere. For example, in the case of a hospital asset tracking engagement, run user interviews with floor managers before a single spec is written. When a medical unit isn’t on the shelf, how long does it take to track it down? What’s the process? How often does it happen? Is there even a record?
Then the question that changes the room: if you could get that time back, what would you do with it?
The answer isn’t ‘generate better reporting’. For a healthcare operation, it’s “spend more time with patients; help care staff’. Stop doing the job that should be done by a system.
That’s the outcome. Not ‘estimated financial savings of 30%’. That number earns an eyeroll in half the rooms you present it in and a skeptical audit request in the other half. The floor manager’s answer connects to something real, a skilled person doing skilled work instead of hunting down equipment.
Measurable outcomes don’t always live on a dashboard. They show up as a drop in logged support calls, fewer manual data entry hours, field inspections that no longer require a truck and a crew. In a hospital, it’s a healthcare worker spending more time at the top of their skill level, whether that’s with patients, support staff, or operations.
Those outcomes look different depending on who’s asking. Finance sees labor hours. Operations see process reliability. Care staff see workload. IT sees ticket volume. Being ready to articulate the value of a connected solution across all of those conversations is where real adoption happens. That’s where an initiative survives long enough to prove something.
Connectivity is the beginning of that story. What you measure at the end of it is the whole point.
Ryan Carlson is Technology Evangelist at Soracom, a cloud-native IoT connectivity platform and full MVNO provider. Ryan has helped pioneer connected products in energy, healthcare, transportation, and commercial services as a product owner, solutions architect, researcher, and principal IoT consultant. He has first-hand experience in product design, user research, IoT corporate strategy, and overseeing product development and go-to-market strategies.
