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

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"?

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.