Internet of Things vs. Hardware-as-a-Service
What’s the best way to deploy your connected product?
The Internet-of-Things (IoT) domain is still growing rapidly, and everyone wants a piece of the enormous market potential. However, as much as it is an incredibly exciting technological area to be a part of, there are many challenges to long-term product success. Many products have launched with great fanfare, but fell through because of a lack of a continuous support strategy.
My contention is that a lot of new IoT products are not, and should not be IoT products at all.
If this article is really about semantics, let’s clear up what these terms actually mean.
Internet-of-Things: “…a system of interrelated computing devices, mechanical and digital machines, objects, animals or people that are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction.” (from TechTarget)
Hardware-as-a-Service: “… a business model where companies sell packages that include hardware, software, maintenance and, sometimes, installation, for a monthly fee.” (from TechCrunch)
So, one is a system, and the other is a business model. However, from a technology implementation and deployment perspective, what do they have in common?
The similarities between the two, at the root level, have clear overlaps.
- Fairly low hardware cost
- Connected to the Web
- Based on simple sensors or actuators (lights, buttons, environmental measurement, and/or screen)
This seems rather trivial — obvious, even. So why make such a fuss about it? Because the Devil is in the details, and in this case, the goblins are everywhere.
This is where the waters get choppy. Although both categories offer smart technology as the product, the deployment strategies and their effects on customers vary quite strongly.
- Value comes from presence in a network of other similar devices
- Acts as a node
- Hardware is usually purchased upfront
- More data is better data
- Requires constant connectivity and omnipresence for customer value
- Expected ROI is 6 months to a year on a five-year strategy
- Value comes from capturing events personalized to the user
- Acts as a portal to a greater service or value offering by connecting to a server
- Only needs to be on when used
- Users subscribe to a monthly service, and the hardware is provided for free upfront
- Easy to secure thanks to user credentials and clear firmware update messages
- Expected ROI is measured in days or weeks
Should I switch to HaaS?
It depends on a few key factors. The following criteria should help determine in which category your product falls.
Does the device provide value through being present, or from interacting with the user?
If the user constantly interacts with it, then there is more apparent value per interaction. This brings us closer to a HaaS offering due the long-term monetization potential.
Can similar (or parallel) functionality be abstracted through an app or web application?
If so, and your customer would use sometimes the device and sometimes the app, then the app is also a product. As such, it will require ongoing maintenance, and revenue should come from a subscription.
Does the customer only need one widget to get most of the value?
If a single instance can do most of the heavy lifting (in the case of a Nest thermostat, one can take care of most smaller houses and apartments), and there are diminishing returns to adding more of these devices, then focus on making a single instance of your product as good as it can be.
What is the replacement cost when breakage occurs?
If you can ship a new item overnight, or can be covered in less than 4 months with the client’s subscription, then we’re talking HaaS. If you need to set up a time for a technician to come inspect, replace, configure and restart the service, then we’re completely in the IoT camp.
Why does it matter?
There are three major reasons why this distinction is more than a “tuh-may-toe” vs. “toe-mah-toe” situation:
- First, it can give you clarity on your business plan, and your future relationship with your customers. Rather than selling as many widgets as you can to your potential customer, or even selling to as many people and companies as possible, you can focus on improving the customer lifetime value through ongoing development cycles.
- Second, problems that would have needed be solved in hardware can now be solved in software. One does not stop the other, of course, but later customers would be ready to pay more for additional features that can be offloaded to a server and deployed over time.
- Third, your minimum viable product does not need as many features to start producing revenue, as your early adopters may see the feature roadmap and understand the growing value offering over time.
Overall, from the client’s perspective, they may not paying for the hardware; instead, there are paying for the functionality that is partially offered by the hardware. This gives you a chance to offer the best potential product to your client, which is what everybody wants.