Understanding IoT Business Models or “Who killed my Unicorn?”
- in Business Models, IoT
One of the memes that has been going around the industry this year, particularly amongst platform suppliers, is that the slow growth of IoT deployments is due to the fact that “Consumers don’t yet understand the real value of IoT”. It’s an incredibly arrogant statement, which tells us a lot about the current start-up mentality, where too many have the perception that they’re entitled to become a billion-dollar company just because they’ve had the presence of mind to jump on the IoT bandwagon. However, the fundamental fact remains that if you are going to succeed, you need a business model. Unfortunately, profitable business models in the IoT are rather thin on the ground, largely because many of the self-styled IoT experts don’t really understand the market.
What most people do agree on is that the IoT isn’t taking off at the rate which everyone had expected, although that’s no great surprise – technology growth curves almost never match the hockey stick curve that analysts predict. Gartner’s famous Hype Curve constantly reminds us that the path to ubiquity is strewn with failed ideas, many of which never emerge from the trough of disillusionment. The IoT suffers from a further problem, which is that the catch-all name has become to mean all things to all men (or maybe all machines). Many forget that the popular IoT poster children which the press pick up and promote as IoT are generally more fluff than substance.
Which brings us back to business models. The IoT will take off when companies work out how to make money out of it. Sadly, that’s proving harder than it may seem, with the more cynical concluding that the only people to profit from the IoT so far are conference organisers. So, let’s take a look at why developing a profitable business model is proving to be so challenging.
The difference between the IoT and M2M
Before we delve into the detail, it’s useful to understand the difference between M2M and IoT. It’s not a black and white distinction – there’s every shade of grey in the world of connected devices. But in general, M2M projects are driven by a need to report data, rather than to analyse it. The return on investment (ROI) for M2M comes from understanding a real-time part of your business. That might be location of a truck, the operating state of a valve or the temperature of a refrigerator. Traditionally these M2M deployments are in vertical industries that could put a price on the value of knowing a piece of information in real-time, so that they could do something more efficiently. Most M2M hardware was designed for that specific business application, which meant it didn’t benefit from economies of scale, so every new project was a new design, with all of the costs that incurs. In general, M2M deployments were justified by efficiency savings, i.e. making an existing business model more effective, not by the more intangible promise of disruptive new business models or digital transformation. Because everything in the M2M chain was designed afresh for each new deployment the entry cost was high, which mostly limited M2M to larger companies. Consultancies did (and continue to do) very good business on reinventing the M2M wheel for each new project.
Whilst M2M has always been easy to understand – it’s a straight ROI calculation, the Internet of Things has always been a more nebulous concept, where the argument is that everything can be connected, so data can be shared, giving us the benefit of new insight, which is then sold as the basis for disruptive, new business models. For the first ten years of its life, the IoT faced three problems:
- The hardware was too expensive to make it economically viable
- The communications costs to get data back were too high to make it economically viable
- There was a dearth of expertise in cloud and data analysis development
A few companies (John Deere is a good example), could afford to implement sensors in their products and begin to harvest data, but most of the IoT was small scale, typically from hobbyists and the maker community. They took advantage of low-cost sensors which had been developed for smartphones, used Bluetooth, Wi-Fi or the new, affordable LPWAN networks to implement low-cost comms and shared the data they collected within their community.
The advent of crowdfunding for hardware projects generated a perfect storm, combining consumer interest, seed funding and unrealistic expectations into a media belief that the IoT had arrived; everything was suddenly smart. Some of these projects started to develop into small companies, attracting the interest of VCs and a flood of investment into the IoT. Nest became the first unicorn – a success story that everyone wanted to emulate, missing the fact that the Nest sale had little to do with the IoT. Instead, the new IoT hopefuls remained donkeys with sticks on their heads, or found they had already been consigned to the knacker’s yard. Which is more or less where we find the industry today – still searching for workable business models.
The good news for M2M is that the traditional M2M models still apply and that the hardware to support them is getting cheaper. In theory that should be lowering the bar for more and more of these vertical applications, except for the fact that most of them are still being supplied by the same consultancies who are happy to continue with their existing business model, which is charging an arm and a leg for what now looks like a few old toenail clippings.
But these aren’t the new IoT models. They start with the prerequisite that hardware is cheap, or a small incremental cost to acquire data and the resulting insight, which can be inferred from large enough quantities of that data, will result in new streams of value. An IoT business model is predicated on the fact that this new value more than pays for itself, either by disrupting an existing business, transforming it beyond mere efficiency savings, or opening up a completely new sector. Compared to M2M that’s really hard.
The Catch 22s of scaling
IoT models face two challenges: the first is the cost of acquiring data; the second the delay in developing compelling and valuable insight from it. To illustrate these, I came up with the diagram below in an article about the battle between LoRa, Sigfox and LTE-M.
The left hand side represent traditional M2M models, whilst the right indicates the new IoT ones. Starting with the red line, we see the cost of deployment going down as components become cheaper. For M2M, that should just make the entry point easier. For the IoT, cost has to come down in order to achieve scale; without scale it is difficult to develop the insight which can pay for the cost of deployment. As cost comes down, we get to the green curve which represents the number of “things” deployed. That needs to rise to provide enough sources of data. This brings us to the first Catch22 of the IoT, which is that you need to deploy a lot of devices to gather sufficient data to analyse. The blue line shows that – there’s a significant up-front cost before you start to see the value. It means that a more realistic representation includes a Valley of Doom which is difficult to get across.
A problem with the IoT is that there’s not just one Catch 22 – there are three. The second one is that even once you start shipping your products, you may not have enough data to provide the compelling insight. That will probably need many months of real data from real users. If your product has a non-IoT primary function, such as John Deere’s tractors, that’s not a problem – they’ll get used, and then in a couple of years you’ll have enough data to offer the former some new services. But for most consumer products, whether that’s a fitness band or a thermostat, the user will expect to see the feedback before they get bored and buy a different device. Unless they get the positive feedback quickly, they’ll consider the product dumb rather than smart and dump it.
This means that there is a very short window to get to a sufficiently large user base to develop that compelling insight. So everything needs to be right first time to get some massive initial sales numbers to collect the data. Soft launches to small sets of early adopters don’t play well if any form of AI and feedback is part of the model.
The third Catch 22 is that your IoT product will probably lose you money. That’s because hardly anyone factors in the ongoing cost of supporting it. As the raison d’être of any IoT business model is to collect data for processing, there’s a cost element to do this for the lifetime of your product. That means paying for:
- An ongoing comms package, which is typically cellular
- A cloud server with the software to process the data
- Cloud storage to store it for as long as you intend to use it for insight analysis
- Ongoing R&D to provide updates, particularly to mitigate any emerging cyberthreats
- Operations, to make sure all of that works, and
- Traditional support
The first four are new and need to be factored into the device cost, unless you can persuade the customer to pay a monthly or annual charge to cover them – a strategy which is proving rather tricky. Pilgrim Beart of Device Pilot has written a comprehensive article explaining why your IoT device may not make a profit, which is well worth a read. Pilgrim has as many, if not more IoT battle scars than the rest of us and is a great source of practical knowledge. For a simple device such as a connected thermostat, he estimates the total support cost will be around $0.64 a month. It may not sound much, but for a product with a ten-year life, assuming that the costs rise by 3% each year, that’s a lifetime support cost of $88 that needs to be factored into the upfront cost. Which equates to around $125 extra on the initial sales price.
It’s worth mentioning that the UK Government is currently considering regulations for consumer IoT products which would require each manufacturer of an IoT device to explicitly state the minimum length of time for which the product will receive security updates. That’s currently in consultation, but it requires some very careful thought from manufacturers about the long term cost before bringing a product to market.
The IoT is all about scale
This bring us to the meat of which IoT business models work? For IoT, scale is everything, as that is what generates the quantity of data to give you insight. As I’ve said before, if your product uses an Arduino or a Raspberry Pi it’s not IoT as it’s not going to scale. That’s doesn’t mean it’s not a viable niche business, but it’s not an Internet of Things one. Scale also starts to chisel away at the ongoing support costs. They’re still there, but when you’re looking at millions or tens of millions of devices you’re able to amortise them over a larger number of units which makes the long term support cost more manageable.
Scaling up M2M and IoT platforms
Whilst it’s not strictly an IoT business model, the falling cost of hardware and cloud services means that traditional M2M deployments should become more cost effective, making them more attractive for many verticals. As I said above, one of the barriers is that the consultancies that have traditionally supplied M2M services have preferred to continue with their existing solutions rather than embracing the new IoT model. There is a short term logic driving them, as the IoT approach significantly reduces their revenue. However, their reticence to evolve provides business models for new players, in particular platform providers who understand hardware and hardware suppliers who understand platforms.
Not enough platform and hardware suppliers seem to have understood this opportunity. Instead they’ve concentrated on the fluffy end of the IoT, wanting to be associated with high profile, smart consumer products. Those that do, and who understand the benefit of a long term relationship with the M2M customer have real potential for growth. It may not be the most obvious sell to an investor, but it could be the best route to scale, which then places your company in a very strong position to serve the real IoT market.
Paying for the ongoing IoT support costs
Once we move past the M2M verticals, any IoT business model needs to work out how to pay for the ongoing support costs over the life of the product. This is fundamental if you expect to make money, but often seems to be an afterthought, because people get wrapped up in how brilliant their product is. It may be, but if it’s not profitable that’s all a bit irrelevant. To pay for these costs there are three basic approaches and every IoT business model has to use one of them, or if you’re lucky, a combination of them. At its most basic, you get the customer to:
- Pay for everything upfront
- Pay at specific events, or
- Pay a regular subscription
There is a final one, which is to get someone else to pay for it, but that’s even more difficult. Let’s look at the three approaches in turn:
The “Pay for everything upfront” IoT model
Surprisingly, given the burden this imposes on the purchase price, bundling all of the future costs with the initial purchase seems to be the most popular IoT business model, particularly for consumer startups. I suspect that’s because few of them ever thought through the ongoing costs they were going to incur when they made their first prototypes. Many may also have hoped to move to a regular subscription from satisfied customers, but those have been tricky to obtain.
That doesn’t mean that including everything in the initial purchase cost doesn’t work – it just means that you need to understand the ongoing support costs and work out how you can optimise your model to minimise them. That can be achieved by limiting the connected aspect of the product life or sending less data.
Limiting the product life may sound counter-intuitive, but you need only limit the connected portion of the product life. The simplest implementation of that is the electronic registration card, where a device connects just once to confirm that it has been correctly installed. If the hardware is cheap enough that may be cost effective for a simple IoT model.
The other route is to limit the quantity of data sent. Consider a consumer application like a washing machine, where a manufacturer wants to keep track of performance and usage. Unless something starts to fail, none of this information is time-critical information, so it could be stored locally and uploaded once a week or once a month.
Security has to be part of the equation, which means that there is still an ongoing R&D cost to develop firmware upgrades when threats are discovered and to deploy them. That may go away if you design a product which is transmit only, as any malware would need the product to be physically compromised. If all you want to do is monitor the performance of your range of washing machines across their life cycle that may be appropriate. Losing a return path prevents you from changing how it responds and loses any acknowledgement that data has been received in the cloud, but as long as no customer service depends on that, it may work.
If your product needs to get data from the cloud, then you need two-way communications, so you do need to support firmware updates. There is still a need to consider updates to cope with future security problems, as no company wants to suffer an ongoing liability of several million hacked devices, but if the necessary R&D can be spread across a large number of products, that cost can be mitigated.
The “Pay at specific events” IoT Model
Rather than loading the original purchase price with the cost of support, an alternative is to charge an incremental fee whenever the product is used. This approach is used in a number of consumer products, where a machine or customer action results in a purchase, when a portion of the event-based cost is used to support the IoT functionality. The concept gained initial notoriety and scorn with the Internet Fridge which would reorder whatever you used, but it is now commonplace in products such as coffee makers, washing machines where users can subscribe to a service based on usage, and the increasingly popular Dash buttons which order products from Amazon.
An advantage of the event-triggered approach is that the connection can be asleep between activations, so any updates need only be applied at the point of use. If a user stops using the device, there is no further support cost, although R&D will continue to be required for the remaining devices until they are declared end-of-life. The economics of supporting a dwindling number of products may dictate when they are finally switched off.
The Pay at event model applies to a lot of infrastructure applications, particularly where an event initiates a charge. Perhaps the most widespread application is for cycle hire; where the Chinese experience has become one of IoT press’ favourites stories. The other great white IoT hope of parking sensors also fits this model, where the ongoing IoT operating costs are paid for by regular parking charges.
Most of the pay at event models assume that the original hardware is sold for a fairly low margin without any ongoing costs included and that these are covered by future usage revenue. In the case of a coffee machine, that will come from the product owner drinking and hence buying more coffee; in contrast, IoT bikes and parking sensors will get revenue from multiple different users. An interesting extension to this model is the sharing economy, where individuals rent out their products to other users. China Mobile talks of a burgeoning sharing economy with “wide-ranging application scenarios, such as massage chairs, pedicure devices, rocking cradles, power chargers and doll machines”. I’m not sure what that last item is, but I’m hoping it’s an error in translation.
The “Subscription” IoT model
Although a lot of the pay at event models are part of the “As a Service” solutions that IoT proponents love, the gleam in many people’s eyes have been for the full live subscription model. This is where a customer purchases a device and then pays a regular monthly fee throughout its life. If you’re confident, you can give the product away for free, or a nominal sum, and rely entirely on the subscription income. Examples range from jet engines, through most smart agriculture to smart home products. The question for the supplier is how to make the insight / product performance sufficiently compelling to persuade the customer to go on paying the monthly fee, rather than abandoning it and choosing another product. That’s where we see our second Catch22, where, unless the experience remains compelling, consumers will move elsewhere and the subscription income ends.
This is the model which relies most on data insight to add value, as your customer relationship relies on providing them with ongoing value past the point where any initial novelty has worn off. Because of that risk, it’s probably the model which requires the largest amount of upfront investment, as it will almost certainly lose money in its early stages (and in some cases for all of the company’s short life). It’s also the model which is most likely for large infrastructure deployments, like smart metering, where the subscription costs eventually end up as part of the customer’s utility bill.
The “Get someone else to pay” IoT model
If the sums don’t work out for any of the models I’ve described above, there’s always the option of getting someone else to pick up the costs. Mad though that may sound, plenty of investment has been thrown at companies without realistic business models, because their investors hope there may be an exit before the money runs out. If other countries follow the UK’s regulatory lead of requiring that manufacturers must explicitly state the minimum length of time for which the product will receive security updates (which should be the same as your current business life expectancy based on remaining investment and burn rate), that could prove to be less attractive. Launching a product which carries a label saying it will stop working in 2 years isn’t a great sales technique.
The alternative is to move to China, where the Government is throwing money at companies to become leaders in IoT. Berg have just announced that they are deploying cellular IoT at “a monumental scale”, with the number of connections reaching 767 million at the end of 2018 – that’s almost two thirds of all global IoT connections. How long that will last is something we don’t know, but it demonstrates the power of regulation to get to scale.
Other IoT opportunities
Most of the above is about business models for companies embracing IoT, either to improve their products or service, or to disrupt the market. That obviously opens up opportunities for a myriad of companies supporting those deployments. The most prominent of these are platform companies, but they face the same challenge of scaling. Many are finding that hardware remains a problem, so are trying to embrace that, whilst hardware companies seeing the same challenge are moving up the value chain to add services. The first tranche of over-valued acquisitions has happened and companies in this area currently need to concentrate on how to get to the tens and hundreds of millions of users. Many are still plagued by volumes which are limited to trials, pilots and makers, so need to find ways to break out. Equally, their customers need to understand whether a platform supplier is already operating at scale, and if they’re not, ask them why?
There is no simple route to a successful and profitable IoT business plan. The IoT is hard. In my previous article on the IoT value stack I outlined the number of different disciplines which are involved and observed that few companies possess all of them. Designing the business plan needs to consider of all of those areas of expertise and how to access them.
However, the ability to support devices in the field is key to any business model, hence the three main models described. That need to pay the ongoing costs is fundamental to every IoT business model, but absent from most. We have seen many IoT products come to market, but are seeing an increasing number of them being turned off as their manufacturers go out of business or discover that they can’t afford to continue supporting them.
I’m not suggesting that every IoT model has to be an “as a Service” model, but that they start by understanding how the lifetime service costs will be paid for. We’re at the point where we can make a connected sensor with a ten year data contract included for under $10. At that point, the lifetime service cost is the dominant cost that needs to be covered. That may be upfront, as a service, or through business efficiency. It becomes the starting point for any business model, not the problem to be solved after you’ve sold your first few hundred products.
Successful IoT business models are long haul ones. The companies that succeed are likely to be the ones that focus on long term customer relationships. There may not be many unicorns around in the short term, but the ones that succeed should reap the benefit of old-fashioned perseverance.
I’m running a full day “Understanding the IoT for your Business” seminar with Cambridge Wireless on 29th May. There are still a few places available – book at the CW website.
(And, of course, upfront means you don’t need a real billing system.)
Really, the subscription option has two matching problems: on the vendor side, you have to deal with the the fact that significant numbers of customers won’t renew or won’t even keep paying. People really don’t like sneaky book club business models. So you have to model a lapse rate from the beginning.
The customer has to wonder whether you’re still going to be around to take their money, too, especially if the subscription element is critical to the product’s functioning. There have been so many tech industry disasters like this – DRMd music that vanished when the registration server went away, locks that failed closed when the cloud service went away, so on and so forth.
The nice thing about upfront is that it gets rid of problem 1 entirely – you just recognize the revenue at the time of sale and book the cash – and it helps a bit with 2 as there is at least some more expectation of getting a service you have actually paid for in advance. (It does require the vendor to resist temptation and reserve against the future cost of service delivery rather than just hookers’n’coking it all.)