IoT's Dirty Secret: The Solution Gap
The IoT industry spent a decade connecting devices. It forgot to connect them to decisions.
The numbers were always impressive. Billions of connected sensors. Petabytes of operational data. Real-time visibility into environments that had previously been invisible — factory floors, supply chains, cold storage facilities, urban infrastructure. The promise was transformative: organisations would finally be able to see everything happening across their operations, and that visibility would unlock a new generation of efficiency, prediction, and control.
What happened instead was a data proliferation problem masquerading as a solution. The devices connected. The data flowed. The dashboards multiplied. And somewhere between the sensor and the decision, the value evaporated.
Where the Value Disappears
The IoT solution gap is not a technology problem. The technology works. Sensors are reliable, connectivity is cheap, and cloud infrastructure can process and store operational data at scale. The gap is structural, and it exists in three layers that the industry has consistently underinvested in.
The integration layer. Connecting a device to the internet is the easy part. Connecting the data that device generates to the systems where decisions are actually made — the ERP, the maintenance scheduling system, the supply chain platform, the operator's workflow — is hard. Not technically hard, necessarily. Organisationally hard. It requires navigating the IT architecture of enterprises that were not designed to accept data from operational technology. It requires integration work that is specific to each customer's stack and cannot be productised in any straightforward way. The vendors who promised IoT solutions frequently delivered IoT platforms — and left the integration work as a professional services engagement that customers had neither budgeted for nor anticipated.
The interpretation layer. Raw operational data is not insight. A temperature reading from a cold storage facility is a number. The knowledge that this specific temperature, at this specific time of day, in the context of this specific product batch, indicates a risk that requires a specific response — that is insight. Generating it requires domain knowledge, statistical modelling, and context that the IoT platform vendor typically doesn't have and the customer typically hasn't structured. The dashboards showed everything. They told you nothing.
The last-mile action layer. Even where insight exists — where the data has been integrated, interpreted, and converted into something actionable — the gap between "the system knows there is a problem" and "a person does something about it" is larger than almost anyone anticipated. It requires change management. It requires process redesign. It requires the operational teams who actually run the facility to trust the system enough to change their behaviour based on what it tells them. This is not a technology deployment. It is an organisational change programme. Most IoT vendors were not equipped to run it, and most customers did not understand that they were signing up for it.
The GTM Consequence
The solution gap has a direct and largely unacknowledged consequence for how IoT products should be positioned and sold.
The vendors who positioned their products as connectivity solutions — "connect your assets, see your data" — closed deals and then faced a wave of disappointed customers who had connected their assets, seen their data, and were waiting for the value that had been promised. The churn rate was high. The case studies were thin. The reference customers were reluctant.
The vendors who positioned around outcomes — "reduce unplanned downtime by 20%, optimise energy consumption by 15%, decrease inventory holding costs" — faced a harder sale but created more durable customer relationships. The outcome positioning forced a more honest conversation about the integration, interpretation, and change management work required to deliver the outcome. It qualified out the customers who wanted a platform and expected magic. It qualified in the customers who were willing to do the organisational work.
The gap between these two positioning approaches is, in effect, the ICP gap. Connectivity buyers and outcome buyers are different customers. They require different sales motions, different success criteria, different implementation approaches, and different definitions of what a good customer relationship looks like. Most IoT vendors tried to serve both with the same platform and the same story, and ended up with a customer base that was broadly dissatisfied and specifically confused about who was responsible for the value they hadn't yet seen.
The Ownership Question
Who owns the solution gap? This is the question that nobody in the IoT ecosystem has answered satisfactorily.
The platform vendor owns the connectivity and data infrastructure. They don't own the integration into enterprise systems — that's the systems integrator's domain. They don't own the domain models that convert data into insight — that's either a specialist software vendor or a consulting firm. They don't own the change management that converts insight into action — that's internal to the customer organisation.
The result is an accountability structure with no clear centre of gravity. When the expected value doesn't materialise, each party has a defensible argument that the problem sits in someone else's layer. The platform vendor delivered the data. The SI delivered the integration. The consultant delivered the insight model. The customer failed to execute the process change. Nobody is wrong. The customer has no value.
This is the dirty secret the IoT industry has been working around for years. The solution gap isn't a technology gap. It's an accountability gap. And it won't close until someone in the value chain — most likely the vendor who wants to retain the customer long enough to justify the acquisition cost — decides to own the full outcome rather than their component of it.
The Path Forward
The vendors who are navigating this well are doing something that looks counterintuitive from a product strategy perspective: they're narrowing before they widen.
Instead of building horizontal platforms that can connect anything to anything and serve any vertical, they're choosing one vertical, one use case, and one outcome — and they're building the integration, interpretation, and change management capability required to deliver that outcome reliably. They're accepting a smaller TAM in exchange for a higher probability of customer success, and they're using the resulting customer references and case studies to expand from a position of demonstrated value rather than theoretical capability.
The result is a GTM motion that looks more like professional services than software in the early stages, and more like software than professional services in the later ones — as the patterns from the early deployments get encoded into the platform, the integrations get productised, and the insight models get refined enough to deploy at lower cost. Palantir's forward-deployed model, applied to industrial IoT. The same logic. The same structural advantage. The same patient willingness to do things that don't scale in order to generate the understanding that eventually does.
The question worth asking is not "are you selling connectivity or outcomes?" Most IoT vendors know the right answer to that question. The harder question is: have you built the organisational capability to deliver the outcome, or are you still hoping the platform will close the gap on its own?
If you haven't read Blog 4 yet — the Skunk Works model and the forward-deployed engineer approach are both answers to the same problem the IoT industry is struggling with: how do you deliver value in complex operational environments without doing the non-scalable work that generates the understanding to do it well?