IOX Insights
The business case for connected products fails because of the wrong unit of calculation: why you need to calculate per device-year, not per device.
The short answer: not because the numbers were too optimistic, but because they were calculated in the wrong unit. A connected product doesn't earn and cost money at the moment of sale. It does so in every year it spends in the field. If you calculate per device instead of per device-year, you get a calculation that works in year one and breaks in year three.
There is a second design flaw, and it sits on the revenue side. Most of the value of a connected product is created at the customer's end – less downtime, fewer site visits, better planning. Without a mechanism that gives you a share of it, that's where it stays.
When a business case doesn't hold up, the diagnosis comes quickly: we got our estimates wrong. The reflex that follows is just as obvious. Calculate more conservatively, add a buffer, cut features. Next time we'll be more careful.
That reflex is the first trap. A buffer on a badly constructed calculation pushes the tipping point back by a few months – it doesn't remove it. The problem isn't inaccuracy, it's a mix-up: the first business case for a connected product usually isn't a business case at all. It's a cost calculation. It tells you what the device costs, not whether the business works.
Pilot projects show this most clearly. A pilot is almost always cheap per device, and for an uncomfortable reason: it lacks exactly the costs that grow with volume. You can look after a hundred devices with a spreadsheet and two helpful colleagues. With ten thousand, that no longer works, and the cost items that appear then were never part of the pilot calculation. That's why so many projects get stuck between prototype and series production. Not because the technology doesn't work, but because it does – and still nobody can say whether it pays off.
A third point adds to this, and it's shifting noticeably right now. Connectivity on its own is no longer a selling point. It has become standard equipment, much like a display or an app. A business case whose revenue side essentially boils down to “our product is now connected” has nothing left to sell.
So before you recalculate, it's worth looking at which cost items can actually tip your numbers.
These cost items have one thing in common: they only exist per year. A device doesn't cause them once – it causes them again every year it is in the field. The right unit for a connected product is therefore not the device but the device-year. Four items decide whether this calculation holds up.
First, connectivity over the product's lifetime. Per device and month it looks harmless – that's exactly the trick. Multiplied by the fleet and by ten years of operation, it becomes the largest recurring item in the whole calculation. On top of that comes something no specification mentions: radio technologies have an expiry date. Networks are switched off, tariffs restructured, contracts expire. Migrating a fleet that has already been shipped is an item in the business case, not an IT topic to be solved later.
Then there's update capability. For a long time it was a feature; now it's an obligation. A device that no longer receives security updates becomes a problem under the Cyber Resilience Act – for you as the manufacturer, not just for your users. What's expensive isn't the individual update. It's the readiness: an update infrastructure that runs for ten years, keys and certificates that have to be managed, documentation that is still accurate when nobody who built the device is around anymore. That readiness costs money every year, including the years in which you don't roll out a single update.
Things get tricky with support. A connected product generates contacts that a non-connected one never did. Every device that can report a fault will report it. And the roles are reversed: your customer often sees the fault before you do and expects you to know about it already. What was meant as a service promise becomes a service expectation – with a cost side nobody calculated, because it never existed in the product business.
And finally, the fourth item, which actually sits on the other side: your share of the value. The value of a connected product is almost always created in operation at the customer's end. It saves trips, prevents downtime, improves planning. That's real value, but at first it lands entirely with the customer. Whether any of it reaches you isn't decided by the feature but by the pricing logic: do you sell the device once, sell availability, charge by usage, or take responsibility for an outcome? Anyone who takes on a long-term obligation and is paid once doesn't have a cautious business case. They have a contradictory one.
This point is especially uncomfortable for companies with a healthy spare-parts and service business. A connected product that runs more reliably and can be repaired remotely reduces exactly the revenue that is earning good money today. That's not an argument against it. But it belongs in the calculation – and not as a footnote.
The good news: you don't need a bigger model, you need a different one. Most business cases aren't calculated too roughly – they're calculated in the wrong unit.
So take a single device and a single average year of operation, and answer four questions. Four lines – that's all you need to start.
The four lines per device-year
What does this device cost in one year of operation – connectivity, support, update readiness, compliance?
What does it bring in during the same year, and through which mechanism exactly?
From which year of operation does the total turn negative, and how many devices are in the field by then?
What value is created for the customer – and which part of it do we share in?
The most common response: we don't have these numbers. That's true, and it's not the exception. In the classic product business they were never needed, so nobody ever collected them. The wrong conclusion is to estimate more precisely. The right one is to work with ranges and set a cut-off criterion: the value of an item at which this project no longer makes sense. A range with a clear limit is more reliable than a figure with two decimal places that nobody can back up.
And use your pilot for this. A pilot that only shows the technology works has wasted half its value. Measure the items that will later grow with volume: how many support contacts do a hundred devices generate per quarter? How much data volume is really used, not according to the data sheet? How long does an update take across the whole fleet? These are the numbers that make your business case robust – not feasibility, which is rarely the problem anyway.
One last point, and it's closely tied to the question of untested assumptions: decide on your pricing logic before you lock in the architecture. Whether you sell once, charge by usage or guarantee availability changes which data you need to collect, who owns the infrastructure and which contracts you need. Once the architecture is in place, the pricing logic has effectively been decided as well – it's just that nobody talked about it.
A business case for a connected product isn't robust because it's calculated cautiously. It's robust when it answers two questions: what does a device cost and bring in during one year of operation – and through which mechanism does part of the value reach you? Everything else is a calculation that will be proven right in year three, when it no longer helps anyone.
A connected product is sold once and operated for ten years. Only one of these two numbers appears in the first business case.
Want to know whether your numbers hold up over the product's lifetime? In the Business Case Check, we work out with you what a device costs per year, when the total tips over and how you share in the value created for your customer. You get a one-page summary with a traffic-light rating and the two cost items to verify first. Free of charge.
Request a checkNewsletter
New articles, practical know-how and lessons learned from our IoT projects – straight to your inbox.
No spam, unsubscribe at any time. For details on data protection, see our privacy policy.