After a long summer break, getting back to writing is a bit difficult, so here is a first post for a new era. I’ll be switching jobs early September, so there might a slight variation in the subjects I’ll write about.
As highlighted in Gartner 2018 Cycle of Hype study, IoT is now a mature tech and we will see more and more large scale projects being deployed in the wild. I would like to expand a bit about what it entails to start an IoT initiative, whether it be to design a new product to sell, or to gain some insight and improve your own processes.
The steps are familiar to anyone who has ever come close to a project in his/her life:
1. Design the solution
2. Gather the requirements
3. Choose the components, protocols
4. Build all the processes (logistics, operations, IT, support)
5. Market and sell
6. Maintain and deliver new functionalities
In terms of project management, there is nothing to learn here. I just wanted to highlight the specifics of an IoT project for these steps. There some particularities due to the type of project, or just points to remember that should be obvious but are often forgotten.
Design the solution
What I mean here is a high level design, functional, that will describe what you are aiming to deliver to your users or customers. Nothing fancy, nothing technical, just plain business.
Gather the requirements
Nothing new here, just make sur you include the future functions and the way you are going to develop. For example, if you start with an MVP (Minimal Viable Product) and build from there in short cycles, you need to have a long term plan/strategy that will keep everything on track. And this plan should help you define your long term requirements.
Choose the components/protocols
This is a technical step, rather complex to execute today, as there are so many solutions to one single question out there. And you have to keep in mind the current state of the art, along with what you expect this state to be in 3, 5 or even 10 years.
Build all the processes (logistics, operations, IT, support)
From my experience, this a often disregarded step, even by some companies that have been in the industry for decades. The simple question is : you are going to deliver a product (physical) to your users. What happens when the product breaks? Who are they going to call (and no, the answer has nothing to do with an 80s movie 🙂 ), how are you going to manage your replacements, stock, warranties etc. How do you handle servicing the device? Remotely, using your current support team, or locally? One specific suggestion, coming from experience : remember to include the ability to remotely upgrade your firmware 😉
Market and sell
Nothing to declare here. This should be rather standard. One word of advice : most IoT project that succeed build on their ecosystem and integration of new functionalities. You should probably add that to your strategy, and to the marketing materials.
Maintain and deliver new functionalities
This point relates both to the maintenance and support I have raised earlier, and to the lifecycle of your product.
Think about the many product we have seen with an incredible starting point in sales or customer acquisition, that dropped of the board after a few weeks, because nothing happened beyond the first wow effect. There nothing more infuriating, as an end user, to have a product with no bugfixes, or without any new functionalities beyond what came with the product out of the box. For example, take a mobile game, Pokemon Go : they had an amazing start, with millions of users daily. But, as the hype faded out, rumored functions and abilities did not come out, and the game statistics went down.
https://www.wandera.com/pokemon-go-data-analysis-popular-game/
The short version is : a connected product is a product, physical, with all the requirements that should be included in such a project. Do not go too fast when your Proof Of Conecpt works. Think long term, and try not to be dazzled by a partner or consultant that show off what a POC platform does on a demo screen 😉