IoT Hardware & Devices - Introduction and Explanation

Hardware decisions impact your IoT product’s cost, user experience, application capabilities, and more. But only about 20% of IoT Product Managers have experience managing hardware. In this post, I demystify IoT hardware to help you understand how a smart device acquires, processes, and communicates data to the Cloud.

After surveying hundreds of Product Managers across industries and backgrounds, I’ve found that only about 20% of PMs working in IoT have hardware experience. By contrast, over 76% of them are familiar with managing software products.

But in IoT, hardware and software work together across the IoT Technology Stack. And managing hardware products requires very different skills than managing software. That is one of the reasons why building IoT products can be very daunting for new and even seasoned IoT Product Managers.

If you’re an IoT PM who comes from a software background, take a minute to arm yourself with the information in this post. You’ll be glad you did next time you talk with Hardware Engineering or are faced with a hardware-related challenge.

Based on my IoT Decision Framework, hardware is part of the Technology Decision Area. Therefore, you are here:

Image credit: Daniel Elizalde

Recommended article: A Product Management Framework for the Internet of Things.

Why do I Need to Understand IoT Hardware? Doesn’t Engineering Make Those Decisions?

Yes, engineers are responsible for researching, proposing, and executing on hardware choices for the product. But it’s important for the Product Manager to be involved and to guide engineering on the product needs so they can choose the best solution. After all, hardware decisions can impact your product’s cost, user experience, application capabilities, and more.

The more you understand about how hardware works, its nuances, and its nomenclature, the more empowered you’ll be to have smart conversations with your engineering team.

The 4 Building Blocks of IoT Device Hardware

With as many IoT applications as there are IoT entrepreneurs, it would be impossible to generalize a hardware architecture. But regardless of the application, all IoT devices share some commonalities or “building blocks”, as shown below:

Image credit: Daniel Elizalde

Building Block 1: Thing

I define “thing” as the asset that you want to control or monitor.

In many IoT products, the “thing” is fully integrated into the smart device. For example, think of products like a smart water pump or an autonomous vehicle. These products control and monitor themselves. In this case, your product includes all four building blocks in a single package as shown below.

Image credit: Daniel Elizalde

But there are many other applications where the “thing” stands alone as a “dumb” device, and a separate product is connected to it to make it a smart device. In this case, your product only includes the three modules in blue below.

Image credit: Daniel Elizalde

This is very common in industrial applications where companies have existing assets, and they want to make them “smart” by connecting them to the Cloud. Some examples include wind turbines, jet engines, conveyer belts, etc.

The reason I point out this difference is to make you aware that there are different business models you could choose from. Your company can decide to build brand new devices that are smart from the very beginning, or you can decide that your value proposition is to provide a way to turn existing things into smart things, opening the door to what’s called “brownfield opportunities”.

Either one is fine, just keep in mind that this distinction will affect many other decisions you make for your product.

Most of the examples above are B2B products, but what about B2C products? In the consumer product world, many IoT products only include the three modules in blue above. That’s because the “thing” they are monitoring is often a human or the environment of the home. Think of a FitBit or a Nest thermostat.

Building Block 2: Data Acquisition Module

The data acquisition module focuses on acquiring physical signals from the “thing” and converting them into digital signals that can be manipulated by a computer.

This is the hardware component that includes all the sensors acquiring real-world signals such as temperature, motion, light, vibration, etc. The type and number of sensors you need depend on your application.

The data acquisition module includes more than sensors though. It also includes the necessary hardware to convert the sensor signal into digital information for the computer to use. This includes signal conditioning, analog-to-digital conversion, scaling, and interpretation.

For the data acquisition module, the important considerations to focus on are:

• What physical signals do I need to measure? (i.e. what type of sensors do I need)
• How many sensors of each type do I need?
• How fast should I measure the real-world signal? (i.e. sample rate)
• How much accuracy do I need in my measurement? (i.e. sensor resolution)

The answers to these questions will inform the requirements for your data acquisition module, as well as give you an idea of how much data your device will produce.

In an upcoming post, I’ll detail how sensors work in IoT. Make sure you subscribe to my newsletter to receive the post in your inbox as soon as it goes live.

Building Block 3: Data Processing Module

The third building block of the device is the data processing module. This is the “computer” that processes the data, performs local analytics, stores data locally, and performs any other computing operations at the edge.

You don’t need to be an expert in computer architecture to have a solid conversation with your engineering team about this module. Your role should be to understand the overarching goal of the product and ask the right questions that will guide your team to the right decisions. The two most important considerations to focus on are:

• Processing power (i.e. how much processing will you do at the edge?)
• Amount of local data storage (i.e. hard drive size — how much data will you need to store at the edge?)

The decisions you and your team make will have a direct correlation with performance, functionality, cost, size of the device, useful life, etc. Let’s discuss each of those questions in more detail.

How much processing power do you need?

To determine how much processing power your device needs, you should start by understanding all the different tasks that the device needs to perform.

Items that will impact your decision include:

• How many sensors do you need to read? (More sensors will require more processing power.)
• Do you need to perform real-time control? (This will definitely increase the processing power required.)
• Does your application need to perform analytics at the edge? (This will also increase the processing power required.)
• Do you have enough processing power to support future software upgrades/releases? (Your new and improved software upgrades will likely require more processing power.)
• What are the size constraints of your device? (For example, a Fitbit only has so much space, limiting the computer size and processing power.)

How much local storage do you need?

The amount of local storage you need depends on your data retention policy. Once you define how much data you need to acquire, how often, and how much you will send to the Cloud, then you can calculate how much local storage you’ll need as temporary storage for doing calculations or to serve as a buffer in case you lose the connection to the Cloud.

If your product is expected to work offline, you need to define for how long it will operate without a connection, and therefore, how much data you need to be able to store locally. Some applications require no interruptions in the data, either because the Cloud Analytics won’t be able to handle data gaps or because you have a legal agreement with the customer for data continuity.

Building Block 4: Communications Module

The last building block of your device’s hardware is the communications module. This is the circuitry that enables communications with your Cloud Platform, and with 3rd party systems either locally or in the Cloud.

This module may include communication ports such as USB, serial (232/485), CAN, or Modbus, to name a few. It may also include radio technology for wireless communications such as Wi-Fi, LoRA, ZigBee, etc.

The communications module can be included in the same device as your other modules, or it could be a separate device that is specifically for communications. This approach is often referred to as a “gateway architecture”.

For example, if you have three sensors in a room that need to send data to the Cloud, you might have those sensors connected to a single gateway in that same room, and the gateway consolidates this data and sends it to the Cloud. That way, you only need one communications module, not three.

The Bottom Line

As an IoT Product Manager, you don’t need to be an expert in all areas of the IoT Technology Stack. But you do need a solid understanding of the major components and how an end-to-end IoT solution is put together.

My recommendation is to get as familiar as possible will all layers of the IoT Technology Stack. I’ll be covering all the other layers of the stack in future articles. Subscribe to my newsletter below to make sure you don’t miss out on those posts.

If you’d like to learn more about IoT Product Management, I invite you to subscribe to TechProductManagement’s newsletter.