Your IoT pilot didn’t fail. Your seams did.

Almost every IoT pilot looks healthy in the demo room.

The device pairs. The dashboard updates. A few alerts trigger. Everyone nods, and someone says the dangerous sentence: “Now let’s scale it.”

Then the first real rollout starts, and the same pattern shows up. A site has weak connectivity. A device needs a firmware update. A customer asks who owns uptime. A unit gets bricked. Support opens a ticket, and it bounces between “the cloud team”, “the app team”, the installer, and the hardware supplier. Each party is correct about their component. The customer is still down.

That is why this IoT Now white paper lands on the most repeatable truth in connected products: pilots fail at the seams, not in the code.

My conviction is simple: if you cannot point to one accountable owner for commissioning and one accountable owner for the end-to-end customer SLA, you do not have a product yet. You have a science project with invoices attached.

The seams are where ownership goes to hide

When people say “IoT is hard”, they often mean “it touches too many teams.” That is true, but incomplete. The real failure mode is that the handoffs are undefined, or worse, “shared”. Shared is where deadlines go to die.

The white paper calls out the usual pressure points: firmware update responsibility, cloud uptime and data contracts, and the service model when a device is bricked in the field. Those are not technical details. They are interface contracts between humans and companies.

Here is the uncomfortable thing I have learned building connected building controls: scaling is mostly contract design and field discipline. The tech is rarely the limiting factor. It simply becomes the scapegoat when the commercial and service edges were left vague.

If you want a quick diagnostic, ask these questions and notice how fast the room starts negotiating:

• Who is allowed to push a firmware update, and who gets blamed if it interrupts a site?
• What exactly is the cloud uptime promise, and is it stated in customer language or vendor language?
• Who owns device identity and provisioning, and what happens when an installer cuts corners to finish the day?
• What is the field process when a unit is bricked, stolen, swapped, or simply dead?

If any answer starts with “it depends” or ends with “we’ll figure it out”, your pilot is not ready to leave the lab.

One commissioning owner, or every site becomes a bespoke project

The most expensive lie in IoT scaling is calling commissioning “installation”. Installation sounds like a one-time task. Commissioning is a system coming alive in the real world, under imperfect conditions, with acceptance criteria that decide who gets paid and who gets punished.

The paper’s practical point is the one I wish more teams would take seriously: name one commissioning owner with authority across installer, connectivity, device identity, and acceptance criteria. Without that, every deployment turns into a custom project, and your margin evaporates in travel, rework, and escalations.

This owner is not a project manager with a nice Gantt chart. They need the right to say:

• “We do not accept this site because connectivity does not meet the minimum.”
• “We will not go live until provisioning is automated and traceable.”
• “These are the acceptance tests, and we will run them the same way everywhere.”

When commissioning is weak, your rollout becomes a collection of exceptions. Exceptions multiply. Then engineering gets pulled into field firefighting, and the roadmap turns into a graveyard.

If you want a mental model, treat commissioning like a product surface, not a delivery task. It needs a spec, a toolchain, and a single throat to choke.

The decision that stops software becoming the scapegoat

If I could force one decision before any rollout, it would be this: define, in writing, who owns the end-to-end SLA to the customer.

The white paper says it plainly: do not define ownership by components. Defining it as “cloud uptime is on the platform team” and “device reliability is on the hardware supplier” sounds neat. In real life, incidents do not respect org charts.

Most downtime stories in connected products look like this:

• The device is fine, but can’t reach the cloud because of a site network change.
• The cloud is fine, but device certificates expired because of a lifecycle oversight.
• The app is fine, but a firmware update introduced a rare boot loop in the field.

Each component owner has an argument. The system is still failing the person paying for it.

An end-to-end SLA owner changes the conversation from “who is right” to “what restores service fastest.” It also forces the right engineering choices upstream: observability, rollback paths, staged rollouts, and the boring work that prevents multi-day incidents.

If you have ever run a serious service, you know the punchline: customers do not buy your architecture. They buy the outcome and the response when it breaks.

A kill-or-scale checklist that actually prevents rollout theater

Pilots often die slowly because nobody wants to say “stop”. So they become permanent: a few sites, lots of attention, and just enough success to keep hope alive.

I prefer a sharper fork: kill it, or scale it. The white paper hints at the same remedy: use a checklist that forces ownership.

Here is the version I would put in front of a leadership team. If you cannot answer these, you do not roll out. Not because the tech is bad, but because you are about to create a support disaster.

1) Seam map (write it down)

• Firmware: who can deploy, how you stage, how you roll back, who approves emergency patches.
• Cloud: uptime target, maintenance windows, data retention, data access, incident comms.
• Identity: provisioning flow, certificate rotation, replacement device process.
• Field service: who replaces hardware, lead times, what is billable, what is warranty.

If any seam is “shared”, fix it. Shared means nobody is accountable when it hurts.

2) Commissioning authority (one name)

• They own acceptance criteria and the commissioning playbook.
• They can block a go-live when prerequisites are not met.
• They control the installer interface, including training and audit.

3) End-to-end SLA (one owner)

• Single escalation path for the customer.
• Single incident commander for priority outages.
• Clear internal contracts with each component team or supplier.

4) The ugly cases (decide before they happen)

• What happens when a device is bricked?
• What happens when connectivity is unstable?
• What happens when an installer deviates from the standard?
• What happens when the customer refuses a firmware update?

These are not edge cases. They are Tuesday.

5) A scaling trigger (not vibes)

• Define what “pilot success” means in measurable terms: stability, repeatable commissioning time, support load, and uptime.
• Pick the threshold that unlocks rollout investment, and the threshold that kills the program.

This is where most teams cheat. They treat a demo as proof. Your only proof is repeatability under normal field conditions.

My opinion: IoT is a service business pretending to be a product business

Connected products sit in the world. The world is messy. That mess has to be priced, contracted, and supported.

So yes, the software matters. But software is not your biggest risk. Your biggest risk is shipping something that cannot be commissioned consistently, cannot be updated safely, and has no clear end-to-end promise to the customer.

If you take nothing else from this: before you scale, go hunting for seams. Put an owner on each one. Then put a single owner above them who is accountable for the customer outcome.

That is how you stop pilots from dying politely. And it is how you build technology that changes something real for the people living with it.

If this is the season you are moving from pilot sites to real rollout, it may also help to read Autonomy’s Hard Part Isn’t the Car. It’s the Service. The shape of the problem is the same: the hard part is the thing that happens after the demo.