Your focus naturally shifts according to which stage of your journey you’re at, writes Pilgrim Beart the chief executive of DevicePilot, so ensuring you’re always focused on the right things is the key to becoming established on a successful growth trajectory.
At the beginning, in the start-up phase of your journey you may start by building perhaps ten proof-of-concept/minimum viable product (MVP) devices to quickly answer a host of fundamental questions which address technical, commercial and human factors and thereby de-risk the project early.
Startup
At this initial stage you’ll be mainly testing your proposition and your technology. These are both important in different ways:
Capturing proposition metrics reveals how the device is being used, so, for example, you can answer:
• Did it get successfully installed?
• Which features are being used, such as which buttons are being pressed?
• Does it get used regularly? For consumer devices you want to check you’re not suffering from the fabled ‘time-tokitchen-drawer’ which presages churn.
Capturing technology metrics can reveal the underlying function of your devices. Some examples include:
• Battery life and how it varies
• Signal strength – by location, by SIM vendor and other factors
• Application crashes and free memory
You should take advantage of your product’s connection to the cloud to capture these metrics for easy analysis. Consider using structured metrics, such as JavaScript object notation (JSON) rather than text log files, because structured data is so much easier to pull apart and analyse automatically. As your hardware and software choices stabilise, you’ll be ready to trial your product, getting it into the hands of enough real users to both market-test your proposition and stress-test your technology. Several hundred units is roughly the scale required to discover the 1% problems in your proposition or bugs in your technology which would be expensive showstoppers at larger scale.
Trials are about looking for a mixture of anticipatable problems and unknown unknowns which could harm your business when rolling out at greater scale, for example:
• Software and hardware bugs
• Patterns of user interaction, including the unexpected
• Communications disruptions
• Real world effects, such as the effect of temperature on batteries
An important question will always be: is each device actually working? To answer this, you’ll want to start measuring uptime and build a process to respond when an individual device or set of devices dies or goes offline. During this stage your main goal is just to keep enough devices working to complete the trial successfully.
To test whether you’re ready to embark on your next stage of growth, decide on a set of quality metrics such as:
• Less than N% new software bugs reported
• Uptime more than X%
• Customer support calls less than Y% per week
• Battery life more than Z%
Scale-up
At this stage you’ll probably be growing to thousands and then tens of thousands of devices deployed.
This is the stage when the development mindset must give way to a day-to-day operations mindset – from manufacturing to logistics to support to service, creating a well-oiled machine that gets better and bigger every day. The team must become efficient at constantly scaling itself – which we can define as supporting an exponentially-growing estate of devices with only linearly-growing costs.
You’ll now find yourself needing to track more numbers such as:
• How many and which sort of devices have been deployed,where?
• Are they working? If not, why not?
• How many are running old software?
• Is the new firmware performing better than the old?
The problem, however, is that once you have a thousand or more devices deployed, manually-kept lists – whether on paper or a screen – become overwhelming, so various tools are needed to help keep track of devices, analyse their performance at scale and solve the most pressing issues first.
You can also now expect different roles in the organisation to become distinct, with each team member wanting different things out of their analytics tools:
• Technical: understanding how the hardware and software is performing
• Product: understanding how the customer is engaging with the proposition
• Support: keeping customers happy by fixing problems before they notice
• Operations: much like support, but with a higher level view of the whole device estate and its trends
Enterprise
At this stage, your product will be starting to mature as a category, though still growing fast – you should have good processes, clear ownership of responsibilities and a better idea of drivers for cost and profitability.
To grow even faster, you may choose to sell to larger enterprise customers or through channel partners, and increasingly they’ll demand reports proving that you are deploying devices as planned and keeping them running well.
You will define a set of key performance indicators (KPIs) and track them to prove you are meeting your service-level agreement (SLA), for example:
• A KPI called uptime might be defined as: number of devices working at least 95% of the time in the past week
• An SLA might be defined as: uptime >90% over the past 30 days
Contracts with penalty clauses might depend on these numbers, so more and more people in the company will want to start measuring leading indicators – measurements which predict whether we’re going to break our SLAs in the future, rather than just reporting that we did in the past when it’s too late to do anything about it.
By this stage your key company metrics may grow beyond just measuring technical delivery to also measure service delivery too. For example:
• Energy delivered for an EV charging company
• Parking space minutes used for a smart parking company
• Journeys completed for an electric scooter company
Alongside uptime metrics you should also consider clustering – if you have multiple devices in the same physical location then the question goes up one level. At any given time, what’s the probability you can deliver your core service at a particular site? In that case, you no longer care about the availability of a single terminal, but instead you want to know if at least one of the co-located terminals is ready for the customer.
Why does it matter?
All of this process and metrics stuff might start to sound like we’re a long way away from the original focus of developing a neat new product. But they’re essential because in reality, many IoT companies are really hardware-enabled services – they deploy products to deliver a service, and it’s really the service that the end customer is paying for. All the data we gather from our product in the field and the tools we use behind the scenes can get us into a position where we understand this class of product and how to use that data to deliver a service better than anyone else in the world – which is a very powerful position to be in.
Just as Google can see everyone’s web searches, and uses that data to become increasingly useful at search, so connecting our product lets us see how customers use our product, and measure how well we are doing at making them happy, and feed that back into becoming better and better.
If you’re unsure which stage your company is at, this quick and handy DevicePilot survey can help: devicepilot.com
