In this IoT primer, I describe how the Internet of Things will require a new breed of Product Manager—one who can incorporate the 5 layers of the IoT technology stack into their product strategy and roadmap. You’ll gain a high-level understanding of these 5 layers and what it takes to manage a product for the Internet of Things.
It’s estimated that 15 billion devices are already connected to the Internet. By 2020, that figure will rise to over 50 billion connected devices.
This is the Internet of Things (IoT), the latest industrial revolution that will have an enormous impact on business and daily life.
Each industrial revolution has created the need for a new kind of engineer who can implement, maintain, and innovate on its new technologies.
The First Industrial Revolution of the late 18th and early 19th centuries gave birth to the field of Mechanical Engineering.
As electrification began to spread across the world during the Second Industrial Revolution of the late 19th century, universities began to offer programs in Electrical Engineering for the first time.
Yours Free: IoT Product Strategy Template
Get the template I use at Stanford University and with my Fortune 500 clients.
The same need emerged in the 1960s and 1970s with the Digital Revolution (the Third Industrial Revolution). The rapid explosion of the computer industry gave birth to new degrees in Computer Science.
The Internet of Things is considered by many to be the 4th Industrial Revolution. But unlike the first three, it is not a new technology—it is a new way of combining existing technologies. As a result, it will not require a new kind of engineer.
But it will require a new kind of Product Manager. Today, very few Product Managers understand how an IoT product works, but this understanding is critical for creating IoT product strategies and guiding the creation of IoT solutions. Understanding the basic building blocks is what you’ll learn in this IoT primer.
For those of you who think the Internet of Things is just about connected toasters and coffee machines, think again. The real impact of the Internet of Things will be on the industrial side. Companies are already working to tackle the biggest problems of our generation by applying the Internet of Things to modernize the electrical grid, transportation, food production, water supply, health care, and other critical infrastructures.
In this IoT primer, I challenge you Product Managers to get ready to deliver what the world needs from you.
Over the coming months, I’ll be posting a series of articles on Product Management for the Internet of Things. In this first post, I provide a brief description of the 5 layers of the IoT stack. In future posts, I’ll provide a lot more detail on how to manage each of the components and how they all fit together.
IoT Primer: The IoT Technology Stack
So let’s get started! The first step to becoming an IoT Product Manager is to understand the 5 layers of the IoT technology stack. By breaking down a full IoT solution into these 5 layers, Product Managers can better understand and analyze the business and technology tradeoffs that are needed at each level, and in the system as a whole. These 5 layers are:
As an example, let’s imagine you’re creating a product that monitors a wind turbine. This product anticipates when the turbine needs maintenance, thereby saving millions of dollars in potential damage to the turbine and avoiding interruption of service.
So let’s take a look at each layer and explore what Product Managers need to keep an eye on, using our wind turbine monitoring product as an example.
Recommended article: A Product Management Framework for the Internet of Things
1. Device Hardware
Devices constitute the “things” in the Internet of Things. They act as the interface between the real and digital worlds.
The first thing to consider is whether your product is the connected device itself (i.e. the Nest thermostat) or your product is turning an existing device into a connected device by adding instrumentation (i.e. adding sensors and communication to a wind turbine). In our example, you’re not selling the wind turbine, just the device that connects to the wind turbine.
One of the main goals of your device (from an IoT perspective) is to collect data. So next you need to think about what kind of data you are collecting, and what hardware is needed to do that. For simple data collection needs, you may need a single smart sensor. For more complex data collection, you may need an industrial computer that houses many sensors, a powerful processor, local storage, a gateway, etc.
At this level of the stack, it’s also important to understand some implications of cost, size, ease of deployment, reliability, useful lifetime, etc. For example, for small devices like smartwatches, you may only have room for a System on a Chip (SoC). For more demanding solutions, you may need an embedded computer like Artik module, Raspberry Pi, Arduino or BeagleBone board. For really serious computing needs, you may need advanced industrial computers like compact RIO or PXI.
For our wind turbine monitoring product, we’ll need an accelerometer as the sensor to collect vibration data. If the vibration is outside a certain range, that means the wind turbine needs servicing. Since this is a heavy industrial application, we’ll probably need to use an industrial computer like compact RIO, since it has enough computing power and already has integrated accelerometers.
Your device will also need hardware to communicate the data up to the cloud. More about this in the communications section.
2. Device software
Continuing with this IoT primer, the device software is the part that turns the device hardware into a “smart device”. This part of the IoT technology stack enables the concept of “software-defined hardware”, meaning that a particular hardware device can serve multiple applications depending on the embedded software it is running.
Device hardware and software work together to create a smart device, so why keep them separate? It’s helpful to think of them separately because they are built by different teams using very different requirements, processes, and timelines. Device software will be developed by software engineers using an Agile approach. Devices, on the other hand, will be developed by a hardware engineering group following a hardware NPI process. This separation will make your job much easier as you plan roadmaps and work with various teams.
Device software allows you to implement communication to the Cloud or to other local devices. You can implement real-time analytics, data acquisition from your device’s sensors, and even control. This part of the IoT technology stack is extremely important because it serves as the glue between the real world (hardware) and your Cloud Applications. It’ll be up to you and your team to decide how much functionality is placed here versus in the Cloud.
You can also use device software to reduce the risks of hardware development. Building hardware is expensive, and it takes a lot longer than software. So instead of building your hardware for a narrow and specific purpose, it’ better to use generic hardware that can be customized by your device software, to give you more flexibility down the road. In this way, you can update your embedded software remotely via the Cloud, which will update your “hardware” functionality in the field.
The device software layer can be divided into two categories:
Edge Operating System
The complexity of your IoT solution will determine the type of Edge Operating System (OS) you need. Some of the key considerations include whether your application needs a real-time OS, the type of I/O support you need and whether you need support for the full TCP/IP stack. Common examples of embedded OS include Linux, Brillo (scaled-down Android), Windows Embedded, and VxWorks, to name a few.
This is the application(s) that run on top of the Edge OS and provide the functionality that’s specific to your IoT solution. Here the possibilities are endless. You can focus on data acquisition and streaming to the cloud, analytics, local control, etc.
For the wind turbine monitor, our accelerometer will be taking very frequent samples to measure vibration. This produces an enormous amount of data. But we don’t need to send all that data to the Cloud—just the data that indicates there’s a problem. Therefore, our Edge application software will be monitoring the data locally and will only send warning and error conditions. It will also perform real-time control to shut down the turbine if the vibration goes out of the parameters you specify.
Communications refer to all the different ways your device will exchange information with the rest of the world. This includes both physical networks and the protocols you will use. It’s true that the communications mechanisms are tied to the device hardware and device software, but it’s worth thinking of this as a different layer.
Selecting the right communication mechanisms is a key part of constructing your IoT stack. It will determine not only how you get data in and out from the Cloud (for example using Wi-Fi, WAN, LAN, etc.), but also, how you communicate with third-party devices in the same building.
For example, it is common for systems in smart buildings to communicate with each other using the BACnet protocol. If your device is involved in building automation, it’s a good idea for your device to provide BACnet support, even if you’re not sure yet whether you want your device to talk to other devices in the building.
Your communication strategy has an impact on the overall topology of your system. For example, if your system has ten sensors, should each sensor perform control and communicate to the Cloud? Or should you have ten simpler (and cheaper) sensors that communicate to a central gateway for aggregation and long-range transmission of data?
These are not purely technical decisions. These are business decisions that Product Managers need to make while considering the impact to cost, deployment, and technical complexity of the solution.
For our wind turbine monitor, your first inclination might be to connect to a local area network. But your wind farm is in the middle of nowhere, and all you have is a nearby cell phone tower. So you will have to connect to the Cloud via cellular communication. This will have implications for your device’s hardware and software, and your cost because you will have to pay a cell phone carrier for the connection. This additional cost also supports our decision to only send the error data to the Cloud, not the entire data set produced by the accelerometer, because the more data you send, the more it costs.
4. Cloud Platform
The cloud platform is the backbone of your IoT solution. If you are familiar with managing SaaS offerings, then you are well aware of everything that is entailed here. Your infrastructure will serve as the platform for these key areas:
Data Collection and Management
Your smart devices will stream information to the cloud. As you define the requirements of your solution, you need to have a good idea of the type and amount of data you’ll be collecting on a daily, monthly, and yearly basis.
One of the challenges of IoT applications is that they can generate an enormous amount of data. You need to make sure you define your scalability parameters so that your architects can define the right data management solution from the very beginning.
Recommended article: Big Data: 6 Key Areas Every Product Manager Should Address
Analytics are one of they key components of any IoT solution. By analytics, I’m referring to the ability to crunch data, find patterns, perform forecasts, integrate machine learning, etc. It is the ability to find insights from your data and not the data alone that makes your solution valuable.
The Internet of Things is all about connecting devices and sharing data. This is usually done by exposing APIs at either the Cloud level or the device level. Cloud APIs allow your customers and partners to either interact with your devices or to exchange data. Remember that opening an API is not a technical decision, it’s a business decision.
Recommended article: The Business of APIs: What Product Managers Need to Plan For
Product Managers need to provide clear direction on the vision for the overall IoT solution, so the technical teams can determine the right Cloud architecture. Product Managers also need to evaluate the cost and complexity of development of the Cloud platform via a build versus buy analysis.
The inclination of every technical team is to build the complete solution from the ground up. But regardless of whether the team is capable of doing it, it’s important for the Product Manager to determine if building your Cloud platform makes “business sense” not only from the development perspective, but also considering the total cost of ownership, maintenance, support, reliability, and time to market.
In many cases, it might be better to leverage existing PaaS (Platform as a Service) frameworks like GE’s Predix platform or SAP’s Hana. The IoT industry is very young, but we are already seeing some giant software players starting to enter this space. Examples like Parse from Facebook or Thunder IoT Cloud from Salesforce are indicators that the IoT platform industry will continue to evolve rapidly, and that building everything from scratch might be counter-productive very quickly.
For our wind turbine monitor, let’s think about how much data we’ll have to store. The data from one turbine might not seem like a lot. But over years, it will add up. Plus remember that your Cloud platform needs to support data from thousands of wind turbines. In time, this will be an enormous amount of data, so our Cloud infrastructure needs to allow for flexible storage and processing of this data.
Additionally, your Cloud analytics need to process incoming data in real time, to detect trends and be able to make predictions of when the turbines will need service. You’ll also need to open an API to surface this information to your application layer, which we discuss next.
Recommended article: How to Reduce Cost and Boost Quality with an IoT Platform
5. Cloud Applications
This is the part of the stack that is most easily understood by Product teams and Executives. Your end-user applications are the part of the system that your customer will see and interact with. These applications will most likely be web-based, and depending on your user needs, you might need separate apps for desktop, mobile, and even wearables.
Even if your smart device has its own display, your customer is very likely to use a cloud application as their main point of interaction with your solution. This allows them to have access to your smart devices anytime and anywhere, which is part of the point of having connected devices.
Product Managers must understand your users and the “job to be done” of your product. When designing your end-user applications, it is very important to understand who is your user and what is their primary goal for using your product. Keep in mind that for Industrial IoT applications, you’ll probably have more than one user.
Applications can also be divided into customer-facing versus internal apps. Customer-facing applications usually get the most attention, but in the case of IoT, internal applications are equally important. These includes applications to remotely provision and troubleshoot devices, monitor the health of your device fleet, report on performance and predictive maintenance, etc.
These internal applications will require a deep understanding of your external and internal customers and will require the right prioritization and resourcing to make sure they don’t fall through the cracks. They are a key component of an IoT solution, so it’s the Product Manager’s responsibility to ensure they get done.
For our wind turbine monitor, one possible application would be a web app used by wind farm operators working in a central control room. This app displays information and trends on the thousands of turbines that they manage and alerts them when a particular turbine needs service. The operator can get this information in real time and dispatch the service team to perform preventive maintenance, avoiding costly repairs and service interruptions.
Recommended article: How Internal Tools Can Make or Break Your IoT Solution
The Bottom Line
As the Internet of Things continues to grow, the world will need an army of IoT-savvy Product Managers. And those Product Managers will need to understand each layer of the stack, and how they all fit together into a complete IoT solution. Product Managers will need to make strategic business and technical decisions at each layer in order to ensure the success of their products.
Quick favor. If you really enjoyed this article, then it’d be a HUGE help if you shared it with other product folks (you can use the share icons). It might seem insignificant, but it helps me more than you might think. Thanks!
So where do you go from here? In my next post, I provide an IoT Decision Framework to guide Product Managers through the specific questions you should ask yourself (or your teams) for each layer of the IoT technology stack.