Resources > Articles

Internet of Things: A Primer


The internet of things will require a new breed of product manager—one who can incorporate the five layers of the IoT technology stack into their product strategy and roadmap. In this article, you’ll gain a high-level understanding of these five layers and what it takes to manage a product for the IoT.

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 creates 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.

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 fourth Industrial Revolution. But unlike the first three, it is not a new technology—it is a new way of combining existing technologies. It will not require a new kind of engineer, but it will require a new kind of product manager. Today, few people understand how an IoT product works, both as a whole and within each layer. This understanding is critical for creating IoT product strategies and guiding the creation of IoT solutions.

The rise of IoT will require a new generation of highly skilled IoT product managers.

For those of you who think IoT is just about connected toasters and coffee machines, think again. The real impact of IoT will be on the industrial side. Companies are already working to tackle the biggest problems of our generation by applying the IoT to modernize the electrical grid, transportation, food production, water supply, health care and other critical infrastructures.

The IoT Technology Stack

The first step to managing an IoT product is to understand the five layers of the IoT technology stack. By breaking down a full IoT solution into these five layers, you can better understand and analyze the business and technology tradeoffs that are needed at each level and in the system as a whole. These layers are:

• Device hardware • Device software • Communications • Cloud platform    • Cloud application

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. Let’s take a look at each layer and explore what product management needs to keep an eye on, using the wind turbine monitoring product as an example.

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 (e.g., the Nest thermostat) or whether it turns an existing device into a connected device by adding instrumentation (i.e., adding sensors and communication to a wind turbine). In this 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 you need to think about what kind of data you are collecting and what hardware you need 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 smart watches, 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 the wind turbine monitoring product, you’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, you’ll probably need to use an industrial computer, because it has enough computing power and already has integrated accelerometers. Your device will also need hardware to communicate the data up to the cloud.

Device Software

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 vs. 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, 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.

Edge Applications

These applications 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 and more. 

For the wind turbine monitor, the accelerometer will take frequent samples to measure vibration. This produces an enormous amount of data. But you don’t need to send it all to the cloud—just the data that indicates there’s a problem. The edge application software will monitor the data locally and only send warning and error conditions. It will also perform real-time control to shut down the turbine if vibration goes out of the parameters you specify.


Communications refers to 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 device hardware and 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 communications strategy has an impact on the overall topology of your system. For example, if your system has 10 sensors, should each one perform control and communicate to the cloud? Or should you have 10 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 management needs to make while considering the impact to cost, deployment and technical complexity of the solution.

For the 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 the decision to only send the error data to the cloud, not the entire data set produced by the accelerometer, because the more data sent, the more it costs.

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 three 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 beginning.


Analytics are one of the key components of any IoT solution. 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.

Cloud APIs

The IoT 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 interact with your devices or exchange data. Remember that opening an API is not a technical decision, it’s a business decision.

Product management needs to provide clear direction on the vision for the overall IoT solution, so the technical teams can determine the right cloud architecture. Product management also needs to evaluate the cost and complexity of development of the cloud platform via a build vs. 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 product management to determine if building your cloud platform makes business sense not only from the development perspective, but also in terms of 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 young, but some giant software players are already entering 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 quickly become counter-productive.

For your wind turbine monitor, let’s think about how much data you’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 your cloud infrastructure must allow for flexible storage and data processing.

Additionally, your cloud analytics must process incoming data in real time to detect trends and make predictions about when the turbines will need service. You’ll also need to open an API to surface this information to your application layer.

Cloud Applications

This part of the stack is most easily understood by product management and executives. Your end-user applications are the part of the system that your customer will interact with. These applications will most likely be web-based and, depending on user needs, you might need separate apps for desktop, mobile and even wearables.

Even if your smart device has its own display, your customers are 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 management must understand users and the jobs-to-be-done of your product. When designing end-user applications, it is important to understand who the user is and 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 and 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, and report on performance and predictive maintenance.

Internal applications require a deep understanding of your external and internal customers and 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 product management’s responsibility to ensure they get done.

For the 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 the operators 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.

The Bottom Line

As the internet of things continues to grow, the world will need an army of IoT-savvy product teams. These teams will need to understand each layer of the stack, and how the layers fit together into a complete IoT solution. Product management will need to make strategic business and technical decisions at each layer to ensure the success of their products.



Other Resources in this Series

Most Recent


Four Methodologies for Prioritizing Roadmaps 

In this blog, we'll explore four common approaches to roadmap prioritization and discover the practical tools and frameworks that can propel your product to new heights.
Prism photo: Product management Lessons from Pink Floyd

Product Management Lessons from Pink Floyd: a Lighthearted Look into Their Epic Music and Unlikely Product Expertise

Few people (actually, no one!) spontaneously associate product management with Pink Floyd, but if you look closely, you can find good examples of best product management practices in their journey, as I hope to reveal...
Creating a product roadmap: what should you include

A Guide to Product Roadmaps: How to Build One That Works

A product roadmap is a frequent request from the sales force and others in the company. ‘What’s coming in the next release and the ones after that?’ Long buying cycles common with strategic products often...
Dry erase board with product roadmap drawn on it

How to Build a Brilliant Visual Product Roadmap

Building roadmaps is a crucial part of a product manager’s job. Yet most product managers still use outdated tools for roadmapping—Excel, PowerPoint, wikis, etc. The good news is that there’s a better way. Executives have...
Product Datasheet

How to Write a Kick-Butt Product Datasheet

If your datasheet passes the all-important skimming test, it's more likely that buyers will read it in detail. Here are 10 tips to help you write a datasheet that buyers actually read.

OTHER ArticleS


Four Methodologies for Prioritizing Roadmaps 

In this blog, we'll explore four common approaches to roadmap prioritization and discover the practical tools and frameworks that can propel your product to new heights.
Prism photo: Product management Lessons from Pink Floyd

Product Management Lessons from Pink Floyd: a Lighthearted Look into Their Epic Music and Unlikely Product Expertise

Few people (actually, no one!) spontaneously associate product management with Pink Floyd, but if you look closely, you can find good examples of best product management practices in their journey, as I hope to reveal...

Sign up to stay up to date on the latest industry best practices.

Sign up to received invites to upcoming webinars, updates on our recent podcast episodes and the latest on industry best practices.

Training on Your Schedule

Fill out the form today and our sales team will help you schedule your private Pragmatic training today.