Many new products now come “connected” which justifies a premium price. Manufacturers are delighted. But having analysed the business model of several of these products I’ve become convinced that

many connected products lose money

for the manufacturer once the ongoing costs of supporting the connected features over the product lifetime are properly accounted for. So even as they focus on selling more and more such products, and claiming ever-higher annual profits, they are in fact creating ever-bigger future liabilities for themselves.

In this blog, we refer to classic business models used to sell "things":

• Product: a physical device is sold for one upfront payment
• Service: a benefit that is sold for an ongoing fee (for example, monthly payments)

The Internet of Things enables physical products to become services and thus enables a shift of business models from a one-off payment on an ongoing fee. A key point here is that "connecting" not only enables this shift, but often requires it for cost reasons.

All the world's a service

Connected products come into the world from broadly one of two lineages:

1. Startups creating connected product propositions (often novel) from scratch
2. Established companies connecting their products to the internet for the first time

Startups are often born citizens of the internet and intuitively understand that connecting a product turns it into a service. There are many benefits to be derived from having a close service relationship with your customer and many ways of monetizing that - outlined in our blog on monetising your connected product. "As-a-service" thinking comes naturally to startups and with it the idea of monthly revenue per device, from which the provider's monthly costs per device to deliver that service must be taken.

Established product companies don't always fully grasp this way of thinking. Their business model was historically a one-off product sale: they built the product, sold it to customers and then hoped to never see it again for its product life, which in many cases could be more than a decade. It's all too tempting for these companies to make the mistake of considering connectivity as just one more product feature - an attitude which can fail to capitalise on its benefits and fail to mitigate significant risks.

Let's take a step back to realise how much of everyday life is now effectively delivered as-a-service, if not overtly. Mass production delivers physical hardware at amazingly low costs - but much of this hardware is useless without the service that backs it. Your smartphone is a doorstop without its network. Your light bulbs are doorstops without the energy service that lights them. And of course, smart home services like Hive, Nest and Alexa would be dead in the water without not only connectivity but the ecosystem of other services around them. Even a typical washing machine costs more to run over its lifetime than it does to buy in the first place - so its service costs (its energy efficiency) will affect the customer's wallet more than its upfront product cost.

The fundamental realisation is that the actual "good" for customers is the utility of the service, not the "thing" that happens to be necessary to deliver the service. I want my house to be warm and well-lit, and my clothes to be clean. The heating system, lights and washing machine are just physical things that deliver the service, but it's the service that I want. In principle, I'd be happy to never have to think about - or buy - the physical things at all. In general, millenials don't seem to aspire to own "stuff" the way folks did in the 1950's peak of consumerism: why own a car when you can find a Zipcar within a few minutes anytime, use it on demand, and not have to worry about garaging, servicing, taxes, and all the associated hassle of ownership?

We're used to buying smartphones with a contract (with lock-in), effectively as-a-service. At my previous company, AlertMe, we launched the smart home platform that eventually became British Gas' Hive. We initally offered a pay-as-you-go service business model and found that consumers weren't expecting to pay in that way. But now, several years on, British Gas have succeeded in selling Hive as a service. Today it's even possible to pay for clean-clothes-as-a-service - not by employing a butler or popping down to the launderette, but with a washing machine paid for by a combination of monthly service fee and pay-per-use. There's no upfront cost, and you can say goodbye to worrying about servicing, repair or upgrade.

Turning a profit

If you're a company selling your product as a pure service then it's pretty self-evident that your monthly costs to support your devices must, on average, be less than the monthly revenue you receive from your customers. The picture becomes less clear when connected products are sold for an upfront cost with no recurring fee - which by default is the proposition that many established companies are choosing when they launch their first connected products today.

Service-oriented people look with envy at a business model where on Day 1 of the sale you get to cover your cash-flow and make your profit. However, the risk with this model is that any connected product has ongoing costs to the vendor which will eat into that profit, potentially turning it into a loss. These ongoing costs include underlying services such as connectivity and cloud, but also the requirement to update the software in the device – at a bare minimum just to patch security holes which exist in all products no matter how carefully they are designed (if your CTO tells you this doesn’t apply to you then unfortunately history repeatedly shows that they are wrong!).

Lifetime profit analysis

In the appendix at the end of this paper we identify several sources of ongoing costs for a connected product, and attempt to estimate them. This leads to the following picture of total cost per device per month for some mythical connected-product company:

Ongoing costs per device per month (total $0.64)

For our company's previous unconnected product, the only ongoing cost incurred was Support. But now, in this example....

connecting the product has roughly quadrupled the ongoing costs.

Let’s assume that the original unconnected product sold at a retail cost of $100 on which the manufacturer made a $30 margin. The total cost of Support over the 10 year lifetime of the product was around $22, leaving a final profit of $8.

Now the new connected product sells at a retail cost of $150 (a premium price because of its connected features) and because there isn’t a huge amount of hardware cost in connecting something these days, this allows the manufacturer to double their margin to $60. Looks great, let’s sell lots!

But hang on a moment - the above ongoing costs over the average 10 year lifetime of the product amount to $76.80, which means that over that 10 years the company will actually make a loss on each product sold.

It may be a rational strategy (for a company with deep-enough pockets or other profitable lines which support the business) to launch such a product even though in its initial form it will be loss-making, in order to improve brand perception and capture market share. But clearly there is work to be done sooner rather than later to ensure that the product becomes profitable. And in that analysis the many "value-added" aspects of a connected product should be considered as a way to achieve this, for example the "freemium" model where a small percentage of customers are persuaded to sign-up to an ongoing fee in return for premium features.

In this example, charging just $1.00/month for premium features would put the product well into the black over its lifetime.

Conclusion

Connecting a product can bring many benefits to customers, allowing vendors to charge a premium for the product. However it also brings many new costs, and if those costs are not carefully analysed and controlled then it is very possible for a connected product to make a loss for the vendor over the product’s lifetime.

A significant source of ongoing cost is support and operations, which are the reactive and proactive tasks needed to keep the connected product doing the job that the customer is paying for – and therefore keeping the customer happy. Using DevicePilot to provide operational excellence for your product:

• drives-up the quality of delivery of your connected product by providing visibility, monitoring and automation, helping your support and operations teams to deliver a higher-quality customer experience
• makes your operations and customer support teams far more productive (able to manage more devices), reducing your costs.

The higher quality of deliver can in turn justify you charging an ongoing fee for service. So in short DevicePilot can help turn your connected product into a source of profit and growth for your company >>

Appendix

NOTE: Click here to see the spreadsheet used to calculate these numbers – to try your own numbers just sign in with a Google account and click "File/Make Copy".

The factors which affect whether you’ll make a profit on your IoT device vary enormously from one proposition to another so here we’re going to examine the case of a relatively simple connected home thermostat. As an exemplar of a typical IoT device it’s intentionally chosen to be somewhere in the middle: with a Total Accessible Market (TAM) in the millions and with each device being of some real significance to the customer. We’ll work this through to create a model with explicit costs – into which you can then plug the numbers for your connected product, which will undoubtedly be different. We’ll use dollars as our currency but at this broad brush level you can replace the dollar sign with euros or pounds as we’re only seeking to get accuracy to an order-of-magnitude.

Service companies often measure their activity in monthly recurring revenue ("MRR"), so we’ll use a month as our unit of time.

Communications

In this case we’re lucky because our device is connected to the cloud for free via our customer’s WiFi connection. Otherwise for cellular connectivity we’d typically expect to pay something like £1.00/month for devices which mostly only ping a heartbeat, or at least £10/month for devices which constantly talk or send media (and remember that code upgrades may be MB in size).

Ingestion

When a message arrives from each device some code must run to deal with it, for example by sending it to application logic and storing it. In a modern serverless architecture this code will probably be a “lambda”, running on-demand in a cloud service such as AWS. Today the cost of running a lambda with a median amount of memory for 500ms is $0.0000125.

There's an enormous variation in how "chatty" devices are. Some devices send messages only infrequently – such as once a day – because they’re limited by power (if they’re battery-powered) or communications (for example, if they’re using a LPWAN technology). Other devices may communicate very frequently, if they are mains-powered and on a free communications-link. One specific reason that consumer devices in the home sometimes do this is that they must poll the cloud to check for inbound messages, because home firewalls do not allow spontaneous messages in the other direction (though there are ways to mitigate this).

Once-a-day to once-every-ten-seconds is a range of nearly four orders of magnitude. For our specific thermostat example, let’s assume a message every five minutes – heating is slow, and so this is good-enough response time between turning the heating up on an app from the train carriage and your heating switching on at home in time to greet you with a warm house.

Each device sends 8,640 messages a month so will cost $0.10/month.

We’re ignoring here other spontaneous messages from the device, outbound messages to the device, and those "rare but expensive" events such as code upgrades.

Storage

In many applications, we want to store the data we receive from devices, allowing us to give our users historical information, and providing useful data for predictive analytics (e.g. in this case we can predict when the user will come home, and how long the house will take to warm up beforehand). Let’s assume our thermostat communicates a few basic pieces of information in every 5-minute message, for example the temperature and other status information. We’ll also want to store a time-stamp too, and some overhead for indexing, so let’s assume this takes up 32 bytes of storage (that’s probably rather an underestimate, but compression is now easy to apply so it’s probably about right).

AWS S3 is cheap, resilient, scalable generic cloud storage and currently costs $0.023 per GB per month. Each device produces 276,480 bytes a month which will cost $0.00000592 to store. But of course the next month you’re still storing that and now have a second month of data - so costs accumulate ‘triangularly’ (if that’s a word). The area of the triangle will be the total lifetime multiplied by the storage per month, divided by two.

But clearly this is a very small cost overall, and so for simplicity let’s here assume that we throw away data once it’s a month old (though there is a strong argument that this is rarely worth doing as long as your business is growing fast, because the data from next year will dwarf all the data stored to date).

Storage access

We must also pay to read and write that data. Let’s assume for now that we rarely read it (quite a big assumption), so the POSTs to write it are our only cost. AWS charges $0.005 per 1,000 requests, so each device will cost $0.0432 a month  – much more significant than the actual storage costs. There are various ways to mitigate this with some R&D investment.

Support

We can consider Support as all the “front-line” activities required to keep a device happy. Primarily this will be 1st-line customer support (the people answering phones and emails) and 2nd-line customer support (the people who can do some triage, and characterize stubborn problems to hand off to 3rd-line support which is technical and often considered part of R&D).

Let’s assume that we get an inbound inquiry roughly once every 18 months on average, that it takes ten minutes on average for a support person to resolve completely, which is 0.55 minutes a month. If our average support person gets paid $25,000/year then their true cost is probably something like $35,000/year which assuming a working year of 220 days and a working day of 8 hours equates to about $0.33/minute.  So our support costs are $0.182 a month.

As an aside, it’s worth noting that support can occasionally be a source of new sales leads too, so here’s one activity that can actually generate revenue as well as driving cost.

Operations

We can consider Operations as all the non-customer-facing activities required to keep a device fleet happy. Operations teams are responsible for:

• Proactively monitoring the overall customer experience and root-causing issues (which may be technical functional issues, or propositional, design or usage problems)
• Keeping the connectivity and cloud services running, including:
  • Responding rapidly to unexpected outages
  • Scaling-up services ahead of demand within the existing architecture
• Device estate “hygiene” – through the life of the connected device there may be events such as provisioning, upgrading, recovery from faults, replacing batteries etc. which sometimes require human intervention (especially if they go wrong).
  • In particular, planning and monitoring upgrades is non-trivial, as is the constant “war of attrition” of trying to get all devices running the latest version of code (in order to reduce support calls and increase customer satisfaction).

Operations staff typically earn more than support staff, say a salary of $40,000/year or $60,000 total cost to the business. The drivers on their time will be a combination of operations on a specific device, but also the portion of the total cost of dealing with larger outages such as cloud problems. Although it is common to have less operations than support, they are more expensive, so let’s assume that they also cost $0.182/month.

Post-sale R & D

Unconnected products in this cost bracket are generally “fire and forget” – there’s no expectation that functionality will change during the life of the product. Not so with connected devices where within a product lifetime there will almost certainly be a need to upgrade the code to:

• fix security problems
• fix bugs (IoT devices are complex)
• fix compatibility with other systems (for example a new WiFi router may become common which behaves in a way that reveals deficiencies in the product implementation)

Since the customer is buying a service, there’s also increasing the expectation that connected products will continue to evolve after purchase to add new features, just like your laptop and smartphone do. E.g. If your customer buys Alexa, they’ll wonder why your product doesn’t support Alexa. Whilst this could eventually be a driver in motivating them to upgrade and buy a more recent version of your product, there is an expectation that certainly for e.g. the first five years of a thermostat’s lifetime there would be ongoing upgrading to support what the user will see as usability issues.

R&D people are expensive, but their efforts are amortised against the volume sold. Conservatively let’s assume that during its first five years (half its product lifetime) the product requires three developers to work for three months each in total to provide all the upgrades and this is amortised across 10,000 devices.  If we assume their cost to the business is $100,000 a year, $8,333 a month then that’s $75,000 spent over five years which is $1250/month, or $0.125/month/device.