Review: “The IoT Product Manager” course by Daniel Elizalde — Part 1
With the increasing complexity of IoT products the complexity of Product Management drastically increases.
Note 1: This piece is written fast without re-reading. Please excuse typo’s and imperfect sentences.
Note 2: I am Product-Market Lead at Kontakt.io, a leader in Bluetooth Low Energy based beacons and sensors for asset and people tracking.
Note 3: You actually find the course I am talking about here: The IoT Product Manager.
Note 4: Also see my article on Pricing for product managers here — fantastic topic which is difficult to master.
Back to why IoT Product Management is hard. The decision areas to build a compelling too get a chosen job done for a customer include: hardware, software that runs that hardware, the communication technology, data handling in the cloud and potentially on-premise backends and the ultimate the consumer interface.
On the business side, an IoT product combines both fixed upfront investments and recurring software elements that must be package and sellable. That makes it all quite complex because you anyway need to find a real user problem and sell your solution.
A piece of hardware has no value regardless of the number of sensors unless it solves a problem that people want to pay money to get it solved.
Daniel Elizalde, a former engineer turned Product Management Leader focusses on providing the frameworks and training for Product Managers and hast just released his new course: The IoT Product Manager. The courses is based on the structure of both his IoT Management Framework (not discuss here) and his teachings his course “Product Management for the Internet of Things”. Because it is easier I will write “Daniel” rather than “Lecturer” when discussing course content below
This is a review of his online course aimed both at people in the profession and those seeking to enter it. I am splitting my review up into the 6 parts of the course not in order of the course but in the order of my interest.
The value of the course is obviously in presenting a comprehensive framework so splitting things up runs a bit against that logic. I’ll summarise at the end.
The IoT Product Manager — The Technology Decision Area (Section 5)
As I am doing my review out of order, I am skipping the business decision area (future review). At this point the learner will already have been guided through the considerations and the focus now is primarily on the business side of things.
Daniels approached is very “framework oriented” which I personally really like because it helps frame detailed discussion in the bigger scheme of things and assign proprieties. With that approach the first natural step is to break down hardware further into the right frames.
Now, with “frameworks” I am somewhat doubtful about how helpful the frameworks are when you do not yourself have the evidence from which they are abstracted. In other words, the “generalisation” is great but it is much easier to internalise with examples of the given elements.
Fortunately, Daniel does that (here just one example for the rest — take the course) by looking at the different elements in more detail and providing technical knowledge rather than just (empty) frameworks. Obviously more value is in the discussion, this is just a screenshot from the slides:
In the following discussion Daniel outlines consideration to deal with sensor decision making around sample rate, resolution, signal conditioning and computing power on the sensor vs computing that will have to be done on the edge / cloud. (Side note: you need to check our this very readable paper from Carnegie Mellon out with regards to sensors with more computing power on them).
Highlight — considerations on edge devices
Now, the next really helpful element (because a lot of money can be badly spend here) is the discussion of computing requirements of an edge device, i.e. what sits between the sensor and the cloud. This is probably one of the areas where capital allocation must be most carefully considered from a “buy vs. build” perspective as value might shift to the sensor (with LPWAN technologies like LoRa, Sigfox or GSM based bypassing the edge device or to the sensor itself in #FogComputing) or to the cloud and the use-cases where the edge device is the value driver is.
I am happy Daniels spend quite some time here with information that is both useful for the beginner with info like.
It would be quite easy to withdraw to the technical elements, I am thankful that Daniel does add his own opinion in this critical decision area, quote
(With the Gateway)…it can be tempting to optimise for cost, size or performance from the very beginning. My recommendation: don’t do that until you find market fit.
(Check out the great analysis of Juicero, the exepensive tool build to press out vegetable juice packages which could have fallen into this trap: https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensive-6add74594e50)
Linking back to the business sections, Daniel outlines potential:
“buy vs build vs partner”
trade-offs, that again are very useful. Example of a slide.
According to Daniel, after talking to hundreds of IoT Product Managers, only about 20% have actual experience in hardware. This is a challenge as there is a number of specific issues associated with hardware like certifications and lead cycles.
Daniel points to this article (among many other very good resources included in the course): http://conceptspring.com/hardware-is-not-software/. From that article I can stress the point:
“REALLY invest in Step 1 — Customer Discovery — before embarking on a product development process. Take as long as you need to truly understand the market and the customers. Look for comparables. Founders should definitely do this themselves and on a very tight budget. An idea with no market is a non-viable idea. Learn how to do qualitative research properly. Conduct detailed / contextural interviews. Do observation studies. Do immersive studies. Anything and everything to maximize your understanding of the customer before you proceed.”
Simply because something is a physical object it does not mean it is a “product” in the sense that it solves a job somebody has. But, it definitly means heavy CAPEX. In summary: the cost is much higher and therefore the returns of understanding a problem well is much higher or much more catastrophic if not done well.
A good discussion point here (jumping further in the course) is
Now, this is especially interesting for me. Not only because I work in this field but because there is a lot of action here:
(Plug: check out our solutions: https://store.kontakt.io/ — asset and people tracking using Bluetooth Low Energy)
Consequently, the focus of the course is on the communication technology. This makes sense because both sensors and the cloud are relatively well developed to support a number of IoT use-cases (obviously, there is still great innovation just speaking from a “product” perspective for high level use-cases.
Selecting the right communication technology
Cool part of the course — Daniel goes through the decision making process life. This is the most straight forward for people with experience, but for people new to IoT this is super valuable. FYI: the is a picture of car with sensors in the wheels with a central gateway that relays to the cloud.
Selecting an IoT Cloud Platform
The wealth of IoT Cloud Platforms is massive from established players like Salesforce, AWS, Oracle, IBM, Robert Bosch. I suspect because it is a) Software but b) in the hype IoT space.
I just wrote this before actually watching the lecture, so happy to see that Daniel starts with this:
Another very good point on what obviously is the key for all product management what not to do:
The course ends with an inspection of options for applications but has these are build with known technologies and personally not too interesting for me, hence I do not go into depth.
This section is extremely useful. I’d strongly recommended it to anybody new to hardware product management but also to marketing, sales teams and customer success teams. As IoT is new and filled with strong trends and hype it helps all involved to have a solid grasp on the considerations in building and designing solutions.
The high level technology overview coupled with the business & strategic considerations are very insightful and help make the hard trade-offs.
The frameworks down to the sensor level help guide the decision making are key to engage in actually useful technical discussion because it is these trade-offs that are crucial.
Lastly, Daniel’s opinion and complementary information like the view on IoT Cloud Platforms and the role of Gateways are much appreciated (partly since I share similar biases).