You’ve probably heard a lot about how the Internet of Things (IoT) will revolutionize many areas of our life. And even with all this potential, many Product Managers are still struggling to understand the basic concepts of IoT and how they can use it to provide additional value to their customers and company.
Note: If you are new to IoT, I recommend my article What is the Internet of Things.
When getting started with IoT, it’s easy to be intimidated by the complexity, the jargon, and the hype. But there’s nothing to worry about. The first step is to stop looking at IoT as a black box and start looking at it as a system comprised of a few distinct technology blocks.
I call these blocks the 5 layers of the IoT Technology Stack. Once you get familiar with the IoT technology stack, you’ll see that there’s nothing magical about IoT. It’s just sensors, computers, and networks put together. By the way, all IoT products have these 5 layers, regardless of whether they are consumer or industrial products.
Later in this post, I’ll also describe how you can use this conceptual model to interact with your team, customers, and vendors. But first, let’s talk about the IoT Technology Stack.
Let’s get started!
Introducing the 5 Layers of the IoT Technology Stack
The first step to becoming an IoT Product Manager is to understand the five layers of the IoT technology stack. By breaking down a full IoT solution into these five 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 five layers are:
To put this IoT technology stack in context, let’s imagine you’re developing a product that monitors the health of 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.
This technique is commonly known as “predictive maintenance.”
Now let’s use the wind turbine example to describe in detail each of the layers of the IoT technology stack.
Layer 1 – Device Hardware
Devices constitute the “things” in the Internet of Things. Devices act as the interface between the physical and digital worlds. They are the first layer of the IoT technology stack.
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. In other words, our wind turbine example is a “brownfield” solution.
One of the main goals of your device is to collect data. So next, you need to think about what data to collect and, therefore, what device hardware you need to do that.
For simple data collection needs, you may need only one sensor. For more complex data collection, you may need an industrial computer that houses many sensors, a powerful processor, local storage, a gateway, etc.
In this layer of the IoT technology stack, it’s essential to understand hardware parameters such as cost, size, ease of deployment, reliability, useful lifetime, etc.
For example, for small devices like smartwatches, you may only have physical space for a System on a Chip (SoC). For more demanding solutions, you may need an embedded computer like Raspberry Pi, Arduino, or BeagleBone board. For critical computing needs, you may need advanced industrial computers like compact RIO or PXI. All of these solutions have different requirements around cost, size, battery life, etc.
For our wind turbine monitoring product, we’ll need an accelerometer as the sensor to collect vibration data. If the vibration is outside a specific 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 to the Cloud. More about this in the communications section.
Recommended article: How Does an IoT Device Work?
Layer 2 – Device software
The device software is the component that turns the device hardware into a “smart device.” Device software is the second layer of the IoT technology stack.
Device software 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 software allows you to implement communication with the Cloud or other local devices. You can perform real-time analytics, data acquisition from your device’s sensors, and even control.
This layer of the IoT technology stack is critical 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 you place 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 device 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.
This technique is often known as “software-defined hardware.” This way, you can update your embedded software remotely via the Cloud, which will update your “hardware” functionality in the field.
I divide the device software layer into two categories:
Device Operating System
The complexity of your IoT solution will determine the type of Device Operating System (OS) you need. Some of the key considerations include whether your application requires real-time processing, the type of I/O support you need, and whether you need support for the full TCP/IP stack. Common examples of embedded operating systems include Linux, Brillo (scaled-down Android), Windows Embedded, and VxWorks, to name a few.
Device Applications
Device applications run on top of the Edge OS and provide the specific functionality for your IoT solution. Here the possibilities are endless. You can focus on data acquisition and streaming to the Cloud, analytics, local control, etc.
For our wind turbine monitor example, our accelerometer will be taking 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 device 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.
Product Manager tip: If device hardware and software work together to create a smart device, why represent them separately in the IoT Technology stack? 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 more comfortable as you plan roadmaps and work with various teams.
Layer 3 – Communications
Communications refer to all the different ways your device will exchange information with the rest of the world. Communications are the third layer of the IoT technology stack. Depending on your industry, some people refer to this layer of the IoT technology stack as “connectivity.” In this post, I’m using the more generic term “communications,” but I’m referring to the same thing.
Communications include both physical networks and the protocols you will use. It is true that the implementation of the communications layer is found in the device hardware and device software. But from a conceptual model (not implementation model), I prefer to keep Communications as its own layer in order to facilitate discussions with the rest of my team.
Selecting the right communication mechanisms is a critical part of your IoT product strategy. It will determine not only how you get data in and out from the Cloud (for example, using Wi-Fi, WAN, LAN, 4G, 5G, LoRA, 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 IoT solution has ten sensors, should each sensor communicate directly 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 decisions are not purely technical. These are business decisions that Product Managers need to make while considering the impact to cost, deployment, and technical complexity of the solution.
For my wind turbine monitor example, the first inclination might be to connect the devices to a local area network. But the wind farm might be 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 decision will have implications on your selection of device’s hardware and software, and on your cost because you will have to pay a cellular service provider for the connection. This additional cost also supports our decision to pre-analyze sensor data in the device and only send actionable insights to the Cloud as opposed to sending the entire data set produced by the accelerometer, Remember, the more data you transmit, the more it costs you.
Layer 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 the role of this layer of the IoT technology stack.
A Cloud platform provides the infrastructure that supports these critical 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 determine the right data management solution from the very beginning.
Recommended article: Big Data: 6 Key Areas Every Product Manager Should Address
Analytics
Analytics is one of the critical 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. Analytics can be as simple as data aggregation and display or can be as elaborate as using machine learning or artificial intelligence. There’s no right or wrong here. Your customer’s needs will inform what type of analysis you’ll need to perform in order to solve their need.
Cloud APIs
The Internet of Things is all about connecting devices and sharing data, which you can achieve 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 their teams a clear direction of the overall IoT solution so that the technical teams can determine the right Cloud architecture. Product Managers also need to evaluate the cost and complexity of the development of the Cloud platform via a build versus buy analysis.
Every technical team inclines to build a complete solution from the ground up. But regardless of whether the team is capable of doing it or not, it’s essential 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). There are many in the market, so for a deeper dive into the Cloud platform layer of the IoT technology stack, I recommend my article:
Recommended article: What is an IoT Platform (and how to choose one)
For our wind turbine monitoring example, 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 the 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 might 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 might also need to open an API to surface this information to your application layer.
Layer 5 – Cloud Applications
This fifth layer of the IoT technology stack is the most easily understood by Product teams and Executives. Your end-user applications are the part of the system that your customers 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 goal 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 is and what their primary goal of 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 include 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: Why It’s So Hard to Create a Good User Experience in IoT
What about “the Edge”?
You’ve probably heard the term “edge” thrown around alongside IoT. Edge refers to “edge computing,” which is the ability to perform analytics or some other computational work closer to where your sensors are.
The question I often get is: Why didn’t you include the edge as one of the layers of the IoT technology stack? That’s a great question! And the answer is just: simplicity.
In this post, I’m presenting a conceptual model of the IoT Technology Stack to help you in conversations with all your stakeholders and customers.
This generic model is not intended as an exact engineering representation of an IoT solution. That’d increase the complexity and defeat the purpose of having a simple communication tool.
Another reason is that the definition of “edge” changes depending on who you are talking to. For example, depending on the vendor, the edge can be:
- The device itself
- A gateway
- An on-premise server that collects data before connecting to the Cloud
- The edge of the cellular network or “Telco edge” if you are talking to Telecommunication providers
- The edge of the electric grid (i.e., smart meters) if you are talking to Utilities
As you can see, the definition and interpretation vary. My recommendation is to keep it simple and use these 5 layers of the IoT technology stack.
But, if you need to add the edge for clarity, you can modify my diagram to add the necessary layers that better represent your solution. The goal is to have a conceptual model that YOU can use to communicate with all your stakeholders.
The IoT Technology Stack Is a Communication Tool
How should you use this model of the 5 layers of the IoT Technology Stack? Use it as a communication tool.
As Product Managers, we need to interact with many people in our organization as well as customers and partners. I’ve found that the first challenge is getting everybody on the same page. That’s where this tool comes into play.
Every time I talk to new groups, I flash the IoT Technology Stack to make sure everybody understands what I’m talking about when I say IoT or end-to-end IoT solutions. It gives everybody a frame of reference AND a common language to refer to the various building blocks. It eliminates the “black box” approach to IoT and puts it in terms everybody can understand.
I include this IoT Technology Stack in most of my presentations (internal and external), and I often open every meeting by aligning everybody on the 5 layers and then on the specific one we’ll be focusing on for this meeting.
It helps me anchor discussions not only with the technical team but also with sales, marketing, executives, design, data science, compliance, vendors, etc.
Now that you are familiar with the IoT Technology Stack, I highly recommend reading my article on The IoT Decision Framework. It’ll give you the next level of tools to approach IoT Product Management in a structured way.
Recommended online course: The IoT Product Manager Certificate Program
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 IoT Technology 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 to ensure the success of their products.
Quick favor. If you enjoyed this article, then it’d be a HUGE help if you shared it with other product folks.
Where do you go from here? Read my next post, where I share an IoT Decision Framework. My framework builds on top of the IoT Technology Stack to give you a structured method to develop your IoT product strategy and roadmap.