Product Management for IoT

Coming from a networking background, seeing the networking world move towards Internet of Things (IoT), I was researching on IoT in my spare time. Wanting to learn more, I started to look around for courses on IoT and entrepreneurship. Interning with the Product Management team at work, I was also interested in ramping up on my product management skills via a course, there were many but I was confused.

I came across Daniel Elizalde's Stanford course on 'Product Management for IoT', a unique course which captured 2 of my present interests. Having attended 2 previous Stanford courses, one on Marketing and the other on Design thinking. I was hoping that this IoT course would also stand up to the hype. It did! Thanks to it, now I have a better understanding of the IoT world and the complexity involved in managing an IoT product. In this article, I would like to share the most important learnings for me from the course.

Simplification of the IoT technology stack into the below 5 components

1. Device Hardware: Sensors to read inputs, transmit/receive data to/from cloud, perform an action. e.g. Sensors on a windmill to measure rate of rotation and wear-n-tear.
2. Device Software: To control the device hardware, compute the input, decide if action is to be performed at hardware or in the cloud. e.g. Software to compute wear and tear based on sensor readings.
3. Communication: Cellular internet 2G, 3G, 4G, LTE / WiFi / WRAN / LoRaWAN / ZigBee / SigFox / Bluetooth link to communicate between the device and the cloud/gateway. e.g. Windmill sensor communicating to cloud controller via LTE.
4. Cloud Platforms: To host data, perform data analytics, store data. e.g. Cloud platform receives rotation input from the device over a period of time, compares it with historical data, performs data analysis and computes when the windmill blades might need a repair.
5. Cloud Applications: User output which displays the computed data in a human readable format, takes user inputs from cloud App, manage or send corrective action items to device hardware. e.g. Web UI through which windmill operators can see a decrease in windmill's energy output and when it might need a repair.

With this new outlook on the IoT stack, I understood that product management for IoT is actually product management for 5 different entities. In larger companies this is true wherein they have Product Managers for Device Hardware, Product Manager for Cloud etc. The biggest challenge as I see it, is to manage 5 different entities with 5 different teams but be on the same roadmap. The challenge lies in ensuring that integration works well and we can deliver the complete IoT solution and not just the device hardware delivery or just the cloud app release.

The IoT Decision Framework

Daniel simplifies product management for IoT by dividing the decision areas into 6 different categories. He eloquently captures the decision areas (rows) against the technology stack (columns) in the IoT Decision Framework. We will have to think about each decision area like UX or Data or Security at each stack like device hardware or software or cloud. This method helps us narrow down product requirements from each stack's perspective. Each of the decision areas was a class each, I wont be able to do justice by summing it up in this article alone.

How the Decision Areas helped in our project:

When we started our project of metropolitan traffic management system using IoT video cameras - something similar to what Cisco has here. Our project grew leaps and bounds. We were thinking and coming up with all the possible scenarios and kept extending our project to include various amazing new features and integration with Google maps or Uber. But when we started plowing through the decision areas and penning down the data points, we realized that we cannot conquer this Mt.Everest of a project in the given time.

Daniel's IoT Decision Framework helped us to trim down our enthusiasm about adding features and concentrate only on delivering a Minimum Viable Product (MVP) which had the basic functionality for our first release and hence ensuring a quicker Go-To-Market.

What is the "Circle of IoT"?

Let's say for example, initially in the Data decision area we have decided to live stream all the data from 5000 windmills to cloud directly to receive real time measurements. However, in the Business decision area we decide that it makes financial sense to send blocks of data to cloud once per hour and not live stream it. Then we will have to circle back to Data decision area and change the requirements accordingly.

That's the beauty of the IoT decision framework, it let's us retrace our assumptions and correct them based upon the present product deliverables.

Development:

Once the decision framework is ready and approved, we can get into development of the product. Daniel says that during the product planning phase, at each stack the question should always be "Do we want to build or buy or partner?". If there are cloud platforms like AWS IoT, Azure IoT and Cisco IoT already available, do you want to spend time building a new cloud platform or just use existing one?. If your IoT device is entering the home automation segment and Google NEST / Amazon ECHO are already available with open REST APIs, do you want to build a new interface or just partner? . These would be some of the questions we will have to ask ourselves at the intersection of each decision area and technology stack while planning.

During the product planning phase, all the minor details do not get charted down. It's up-to Engineering to decide how to get something done. That's the reason I would say that not only during product planning phase but even during development we should continuously ask ourselves "BUILD or BUY or PARTNER ?"

If there are multiple stacks which are being developed at the same time, then as Product Managers it is our responsibility to ensure that multiple teams involved are on the same page and are aware of the deliverables for the present roadmap, teams are in coordination to ensure that integration works smoothly. We do not want to end up with device hardware on one end supporting only WiFi capability while the cloud controller on the other end can only support LTE internet connection.

Parting thoughts:

To wrap this up, my 4 key takeaways from this course are

1. Do not build IoT, just for the sake of it. Try to solve a problem, and if the solution is IoT then be it.
2. At every stack, ask ourselves "Do we build or buy or partner?". Enhance, concentrate and build on our core competency skill/stack, gather the rest of the stacks.
3. As a product manager you should have your aim for long term goals with the best features, no bugs etc but at the moment keep an eye out on present deliverables. Iterate back to ensure that you are delivering the minimum viable product which will get us into the market sooner rather than build the perfect IoT solution but deliver only after 2 years of development.
4. Unlike most other products, IoT solutions need to be built with security in mind. Due to the use, penetration and acceptance of IoT into every aspect of our lives be it at home, cars or offices, security cannot be an afterthought. With IoT, the risks are not just with finances or privacy, it could very well be human lives. Especially in the IoT world, we will have to plan and build security into each layer.

Hope this was a useful primer to dissect the complexity in managing an IoT solution. Would love to hear from folks about your thoughts on IoT, any challenges you might have faced in building an IoT solution and how you ended up tackling it.

Thanks,

Prasanna Naik

PS: Next article "SD-WAN and IoT".