Connected Products 101: What Manufacturers Should Know Before Adding IoT to Their Equipment
Somewhere in your business, the conversation has already started. A competitor has launched a “smart” version of a product you both make. A large customer has asked whether your equipment can report its own running hours. A board member has read about servitisation and wants to know what your answer is. For most equipment manufacturers, the question is no longer whether to think about connected products — it is how to scope a first one without burning a year and a large budget learning what the pitfalls were.
This article is the plain-English guide we find ourselves giving engineering and commercial directors at the start of those conversations. No protocol war stories, no cloud architecture diagrams — just what a connected product is actually made of, from the device to the dashboard, which decisions matter early, and the failure modes that catch manufacturers out. It draws on our work in the manufacturing and industrial engineering sector, including connected-product projects like the one we delivered for EnviroVent, which we will come back to. If you are considering IoT for manufacturers seriously for the first time, this is the ground to cover before anyone writes a line of firmware.
Start With Why: What Connecting a Product Is Actually For
The single biggest predictor of whether a connected-product programme succeeds is whether it starts from a business outcome or from the technology. “Our products should be connected” is not an outcome. These are the outcomes that reliably justify the investment:
- Service revenue and predictive maintenance. This is the big one for equipment manufacturers. If your machine can report vibration, temperature, running hours or error codes, you can sell service contracts priced on evidence rather than guesswork, schedule maintenance before failures instead of after them, and turn a one-off equipment sale into a recurring relationship. For many manufacturers, the aftermarket already out-earns the original sale; connectivity is what lets you defend and grow that.
- Usage visibility. Knowing how customers actually use your equipment — duty cycles, settings, features touched and features ignored — changes product development from anecdote to data. It also changes commercial conversations: warranty disputes look different when the machine kept its own logbook.
- Compliance and reporting. In regulated environments — ventilation, refrigeration, emissions, safety-critical plant — customers increasingly need evidence that equipment operated within parameters. A product that produces its own compliance record is worth more than one that relies on manual checks.
- Differentiation and usability. Sometimes the win is simply a better product. A machine that can be commissioned, monitored and adjusted from a phone is easier to install, easier to support and easier to sell. When we built the myEnviroVent mobile app for EnviroVent — whose ventilation products are in over a million UK homes — the point was exactly this: iOS and Android apps that connect to the ventilation units so customers can see the unit’s current speed and settings and adjust them easily. That accessibility made the products more effective in use and gave them a value-added feature competitors lacked, and the complete system went on to win a “Smart Product of the Year” award.
Pick one of these as the primary outcome for your first connected product. Not all four. The programmes that try to justify themselves with everything tend to deliver nothing measurable at all.
The Anatomy of a Connected Product
Every connected product, from a domestic ventilation unit to an industrial compressor, is the same five things joined together. Understanding the chain at this level is enough to have a sensible scoping conversation.
1. The device and its firmware
Something on or in the machine that measures, and something that thinks. In some products this is a retrofit sensor module; in others, the machine’s existing control electronics already know everything worth reporting and the job is getting that data out — which is an integration exercise with your own electronics as much as an IoT exercise. The EnviroVent project involved exactly this kind of work: integrating with the ventilation units’ electronics and communicating with them over wireless protocols.
The word to take seriously here is firmware. It is software, it will have bugs, it will need updating for the life of the product — which for industrial equipment can be twenty years. More on that below, because it is where first-time programmes most often underestimate.
2. Connectivity
How does data leave the machine? At scoping level there are three broad families, and the trade-offs are commercial as much as technical:
- Wi-Fi (and wired networks) is effectively free to run but depends on the customer’s network — fine for domestic and office equipment, fragile on factory floors and construction sites where IT departments, firewalls and patchy coverage get in the way.
- Cellular works almost anywhere and needs nothing from the customer, but every device carries a SIM and a monthly cost, which your commercial model has to absorb. For high-value equipment in the field, it is usually the pragmatic answer.
- Low-power wide-area technologies (LoRaWAN and similar) suit small, battery-powered sensors sending tiny amounts of data infrequently, at very low running cost — but they are unsuitable for anything chatty or for remote control.
There is no universally right answer; there is a right answer for one product in one deployment environment. The mistake is not choosing “wrong” so much as not costing the choice over the fleet’s lifetime.
3. Cloud ingestion
Somewhere, messages from thousands of devices have to arrive, be authenticated, and be routed. This is a solved problem: the major cloud platforms provide managed services for exactly this, and our work is typically built on Azure IoT services, which handle device identity, secure two-way messaging and scale so that you do not have to build any of it. The scoping-level point is simply this: do not let anyone propose building your own device-messaging infrastructure. This layer is undifferentiated plumbing, the managed services are mature, and your engineering budget belongs at the ends of the chain — the device and the application — not in the middle.
4. Telemetry storage and processing
Device data arrives as a relentless stream and is worth little in that form. It needs storing (recent data kept hot for dashboards and alerts, history kept cheaply for trends), aggregating (nobody wants ten readings a second; they want this week versus last week), and watching (rules that turn “temperature above threshold for ten minutes” into an alert a human sees). This is also the layer where, later, analytics and machine learning can be added for genuine predictive maintenance — but that is a later stage. You cannot predict failures until you have accumulated enough history of what normal and abnormal look like, which is one more reason to start collecting sooner rather than waiting for the grand AI-enabled vision to be signed off.
5. The customer-facing application
This is where the value actually lands, and it is the layer programmes most often shortchange. Telemetry in a database earns nothing. A service manager seeing a fleet dashboard, an installer commissioning a unit from a phone, a customer getting an alert before a failure — that is the product. In our experience the application layer deserves the same design attention as the physical product carrying your brand, because to the customer, it is the product. It is worth noting that the EnviroVent app was built for phone and tablet on both iOS and Android — meeting users on the devices they already hold, not on a portal they must remember to visit.
Scoping the First Version: One Machine, One Signal Set, One Outcome
The strongest advice we give first-time connected-product teams is a discipline of ones:
- One machine. Your best-selling or most serviced product line, not the whole catalogue. Retrofit across the range can come later; proving value cannot.
- One telemetry set. The handful of signals that serve the chosen outcome — running hours, a temperature, an error register. Not every value the control board can technically emit. Every extra signal costs connectivity, storage and attention, and most are never looked at.
- One customer outcome. The single thing someone will do differently because the product is connected: a service visit scheduled from data, an alert that prevents a callout, a commissioning process cut from an hour to minutes.
A first version scoped this way can be live with pilot customers in months, generating the two things no amount of planning produces: real field data, and real customer reaction. Both will reshape version two in ways no workshop can predict — which is also the argument for building the first version so it can be extended rather than as a throwaway.
The Unglamorous Essentials
Four topics rarely make it onto the concept slide, and all four are cheaper to address at the start than to retrofit.
Provisioning at manufacture. Every device needs an identity — credentials, a certificate, a registration in your cloud platform — and it has to acquire that identity somewhere. The workable answer is on the production line, built into the manufacturing and test process, so devices leave the factory able to introduce themselves securely. The unworkable answer, discovered by many programmes at scale, is a manual registration step per device performed by an engineer. Design provisioning as part of the product, and involve your production engineering people early.
Over-the-air updates. Firmware is not a one-off deliverable; it is a running commitment for the service life of the equipment. Security patches, bug fixes and new features all need a safe path to devices in the field — staged rollouts, verified updates, and recovery when an update fails on a machine in a plant room three hundred miles away. If a device cannot be updated remotely, every future fix is a site visit or a product recall. Over-the-air update capability is the single most important feature to demand of the very first firmware version, precisely because it cannot be added remotely later.
Security by design. A connected product is an attack surface with your brand on it. The essentials are well understood — unique credentials per device (never a shared password baked into firmware), encrypted communication, signed updates, and the ability to revoke a compromised device — and the managed cloud platforms support all of them. What they cannot do is retrofit security into a device architecture that ignored it. It is also worth saying plainly: customers increasingly ask about product security in procurement, and regulation in this area has been tightening for years. Treat it as a product requirement, not an IT afterthought.
Data ownership in dealer channels. If you sell through distributors and dealers, decide early whose data the telemetry is. The machine may be sold by a dealer, owned by a finance company, operated by an end customer and serviced by a third party — and all four have a claim on, or a sensitivity about, its data. Who sees fleet data? Does the dealer get access to machines they sold? Does usage data flow back to you as the manufacturer, and do your terms say so? These are contractual and commercial questions, and they are far easier to settle before launch than to renegotiate after a dealer discovers the factory can see “their” customers’ machines.
Connecting the Connected Product to the Business
Here is the part most IoT vendors skip, and the reason connected-product work sits naturally alongside systems integration in our practice: telemetry only becomes revenue when it reaches the systems your business already runs on.
Consider what “predictive maintenance revenue” actually requires end to end. The device reports rising vibration. The cloud platform raises an alert. And then: a case must be created for the service team, the machine must be identified against a serial number and an install base record in the ERP, its warranty and contract status checked, an engineer scheduled in the field-service system, and the parts likely needed checked for stock. Every step after the alert lives in systems that predate the IoT programme — ERP, CRM, field service, the service desk. Without industrial IoT integration into those systems, a connected product produces dashboards that someone must remember to look at, and manual swivel-chair processes to act on what they see. With it, the machine effectively raises its own service ticket.
This has two practical consequences for scoping. First, budget for integration from the start — as a rule of thumb it deserves similar weight to the device work itself, and it is the half of the programme where the business case is actually realised. Second, take an honest look at whether your back-office systems are ready to participate. Install-base records keyed by serial number, an ERP that other systems can talk to, a field-service process that can accept work orders from software: these are prerequisites, and if your core systems are too old or too closed to play their part, that is worth knowing before the pilot rather than after it. We have written separately about legacy system migration for exactly this situation.
The Failure Modes to Avoid
We will spare you the horror stories, but the patterns behind stalled connected-product programmes are remarkably consistent:
- Connecting everything, for nothing. Instrumenting the whole product range because connectivity is strategic, with no single costed outcome. The result is impressive data volumes, a growing cloud bill, and a business case still marked “TBC” two years in. The discipline of ones exists to prevent this.
- Treating firmware as a one-off. The launch firmware ships, the embedded contractor rolls off, and eighteen months later a security issue or a protocol change finds nobody able to build, test and deploy an update. Firmware needs an owner, a roadmap and a budget line for the life of the product.
- Underestimating fleet operations. A ten-device pilot needs no operations. Ten thousand devices need dashboards for fleet health, processes for devices that go quiet, connectivity cost management, certificate renewals and update campaigns — a small ongoing operational function that someone must own. Plan for it at the point the pilot is declared a success, because that is exactly when it becomes real.
- Stopping at the dashboard. The programme delivers telemetry and a portal, integration with ERP and field service is deferred to phase two, and phase two never comes because the dashboards alone do not move a commercial number. Integration is not the follow-on; it is where the value is.
None of these are technology failures. They are scoping and ownership failures, which is precisely why they are avoidable at the stage you are at now.
How McKenna Consultants Can Help
McKenna Consultants has been building connected products and the systems behind them for years — from the award-winning myEnviroVent app, integrating mobile software with ventilation unit electronics over wireless protocols, to the Internet of Things and systems integration work that connects device data to the ERP, service and commercial systems where it earns its keep. We are engineers first: our value is in scoping the version one that proves the business case, and building the device-to-dashboard-to-back-office chain so it survives contact with a real fleet.
If you are an equipment manufacturer weighing up your first connected product — or holding a stalled pilot that never reached the business case — we are happy to talk it through, from outcome selection to architecture to integration. Get in touch and tell us about your equipment.
