A Simple IoT Framework for Product Managers


Product Management for an Internet of Things product can be very daunting and confusing, even for the most seasoned Product Managers. That’s because IoT products are more complex than your average product since you need to consider the complexity of five layers of technology: device hardware, device software, communications, cloud platform, and cloud applications.

Not only do you need to make critical business and technical decisions at each of these five layers, but you need to make sure this myriad of decisions is consistent with your overall strategy and consistent across the five layers. This exponentially increases the difficulty of managing an IoT product.

To help Product Managers tackle this complexity, I developed a framework I call the IoT Decision Framework.

This IoT framework provides a structured approach to creating a robust IoT product strategy. What I mean by that is, this strategy is all about making decisions. The IoT Decision Framework helps you understand the areas where you need to make decisions and ensures consistency across all of your strategic decisions.

My IoT framework will help you uncover pitfalls early on before you have invested time and money in the wrong direction with your product.

I’ve seen it firsthand when seasoned Product Managers from top Silicon Valley companies attend my IoT strategy courses either online or at Stanford University, as well as with my consulting clients.

Throughout my courses, participants drastically alter their product strategies as they work through the IoT Decision Framework. It helps them uncover questions they otherwise would not have considered—questions that could make or break their products.

To get started with the IoT Decision Framework, let’s take a look at the five layers of the IoT Technolgy Stack.

The 5 Layers of the IoT Technology Stack

The greatest challenge of managing an IoT solution is that there are five layers in the IoT technology stack, and decisions need to be made at each layer.


To put things in perspective, a SaaS application only includes the two layers on the right side: Cloud Platform and Cloud Applications.

Those two layers alone are usually enough to keep any Product Manager on their toes. So you can imagine how adding three extra layers becomes exponentially more complex because you have to make decisions at each of these layers and make sure your decisions are consistent across all five layers.

As an IoT Product Manager, it can be very daunting to know where to start or how to organize your thoughts. One of the hardest parts is knowing which questions you should be asking.

The Solution: An IoT Framework for Product Managers

The IoT Decision Framework provides you with a structured approach to uncover the questions you need to ask and navigate across the various departments to make the best decisions for your product.

Think of it as a map to help you discover all the necessary considerations as you build your IoT business plan, roadmap, backlog, etc.

The IoT Decision Framework focuses on six key Decision Areas you need to consider for any IoT product. These areas are:

  1. User Experience (UX)
  2. Data
  3. Business
  4. Technology
  5. Security
  6. Standards & Regulations


 Each of these Decision Areas must be evaluated at each layer of the IoT Technology Stack. You’ll start with UX and work with your teams to discover what makes for a great user experience at the Device Hardware layer, then at the Device Software layer, and so on.

Then you can move to the Data Decision Area and explore Data considerations for your Device Hardware, Data considerations for your Device Software, and so on.

Once you are done with the Data Decision Area of the IoT framework, you can move to the Business Decision Area. You get the idea. Continue through the framework left-to-right and top-to-bottom until you cover all areas.


I know this sounds like a lot of work, and it is. But believe me, you’ll be glad you spent the time thinking about the implications of all Decision Areas throughout the IoT stack before you start building anything.

That’s how you’ll create a consistent product strategy and learn about all the gaps that need further refining.

Each bubble in the IoT Decision Framework is an opportunity to use Product Management tools to make decisions and discover gaps—tools like market research, design research, customer development, prioritization, Lean, NPI, etc. This framework is not a replacement for any of those. On the contrary, it provides you with a map and a structure for your discovery process.

The Decision Areas of the IoT Decision Framework

It is very important to go through the IoT framework in order. Each of the Decision Areas are organized so that the information you collect in one area informs the subsequent area. I recommend you start with the UX Decision Area because your goal is to understand your users’ needs first and then move to the other Decision Areas.

Let’s take a closer look at each Decision Area of the IoT framework.

1. User Experience (UX) Decision Area

In this area, you need to understand who your user is, what their needs are, and what would make for a great experience at each layer of the stack. Don’t worry about the technical details at this point. Just think about what this person wants, not how you will deliver it.

Plus, you’ll want to consider the needs of secondary users, like your internal Fleet Operations team, developer partners, sales team, installers, and more.


Why creating a consistent IoT user experience is hard

Most Product Managers entering the IoT space usually have experience managing either hardware or software products. But IoT products include both software and hardware, bringing new challenges that most PMs are not familiar with.

From a product development perspective, hardware and software are likely to be developed and managed by different teams. But keep in mind that users don’t really care who’s building what. They expect a cohesive experience across every touchpoint of your product, regardless of whether it’s software or hardware.

Let’s look at a couple of real-world examples to show the complexities of delivering a cohesive IoT experience.

Exhibit A: UX challenges in consumer IoT products

Think of a smart thermostat. Although this is a relatively simple product, it provides several user experience elements that pure software products don’t have.

First of all, there’s a physical device. And that device needs to be visually appealing, otherwise, your customer won’t be willing to install it on the wall in the middle of their living room. This is a challenge that industrial designers are very familiar with, but if you are a new IoT PM coming from a software background, this might be new terrain for you.

Next, the device itself provides a user interface to enable the user to set the temperature, display the time, etc. Right there, you have a second experience that you need to create. The user interface for your device needs to be intuitive and attractive, and it needs to fit in a small space.

As you work with your team to craft the user experience at the device level, you’ll need to decide whether to have a simple display, physical buttons, LCD screen with a touch interface, etc. Not only does it need to be easy to use and fully functional, but it also needs to be aesthetically pleasing and on-brand.

In addition to the physical user interfaces, connected devices usually have web interfaces that address different use cases. For example, a smart thermostat is likely to have a web dashboard to provide detailed information about usage patterns or energy consumption. And it might have a mobile application to provide summary information and remote control on the go.

These form factors provide you with different levels of real estate to display information, so it’s important to understand the user’s mental model (what they are looking to accomplish) when interacting with each of these user interfaces.

All these different experiences need to be consistent with each other. Although the user is interacting with the thermostat through three different user interfaces (the thermostat, desktop, and mobile), your goal is to ensure that she feels like she is interacting with the exact same product, her thermostat, and not three different products.

Exhibit B: UX challenges in Industrial IoT products

Industrial products have even more challenges when it comes to user experience. Let’s use solar panels as an example. Imagine an array of solar panels installed on the roof of a commercial building. All the panels might be connected to a centralized hub or gateway to aggregate the signals coming from each panel.

This gateway might not need to be as good-looking as the smart thermostat. After all, it will be installed on the roof of a building. But on the other hand, it needs to be rugged and waterproof since it’ll be installed outdoors. Other design considerations include how technicians will interact with the gateway. Does it need an LCD display or should it only have a couple of LED lights to show it is working properly? Those are design decisions you’ll need to make.

Just like the smart thermostat, the product probably has a web dashboard for the facility manager to monitor performance, and it may have a tablet app for technicians to troubleshoot things in the field.

In addition to these interfaces, the gateway might need to connect to the building management system via a direct cable connection or via an API accessible directly from the gateway. Though it might not be obvious, APIs and connectivity points are also user interfaces that you need to develop and craft a good experience for. These connections will be used by developers and system integrators who will form an impression of your product based on the interface you provide.

For them, it doesn’t matter if your end customer dashboard is very polished. If the interface they are using is not equally polished, they’ll have a bad user experience and will rate your product poorly.

Let’s recap. In this commercial solar panel product not only do you have multiple software and hardware interfaces, you also have four users to please: the technician, the facility manager, the developer, and the systems integrator.

So how do you ensure consistency of experience across your product?

What makes IoT products complicated is that now you have to address usability across the full IoT Technology Stack and likely across multiple users.

Plus building an IoT product is a big undertaking, and it’s very common to have multiple teams involved throughout the development lifecycle. Most likely you’ll interact with other Product Managers, and there will be different Engineering teams responsible for developing different parts of the IoT Technology Stack. If that’s not enough, you’ll also have input from Sales, Marketing, Customer Success, etc.

So as a Product Manager, what can you do to address these challenges? In a nutshell, you need to be the source of alignment between everybody involved. You need to have a deep understanding of all of your users and be a communication hub between every team within your company.

2. Data Decision Area

The goal of the Data Decision Area is to help you define your overall Data Strategy. In a nutshell, you need to decide how data should flow through the stack to fulfill the user’s needs.

For example, what type of data does your device need to produce? How much data should be transmitted to the cloud, and how often? Do you need to perform analytics at the edge, in the cloud, or both?

What is your data strategy?

At the end of the day, an IoT product is no different than any other product in the mind of the customer. It either delivers value or it doesn’t. It either solves the job it was hired to do or it doesn’t. 

Why am I telling you this? Because one of the biggest challenges companies face when building IoT products is having a data strategy—a plan for how you’re going to derive value from your data. A way to deliver insights, not data.

A data strategy goes beyond the collection and management of the data. It starts with defining an ultimate goal you want to achieve with your product and then walking the IoT Technology Stack to understand what data you need to collect, store, analyze, and transfer at each layer of the stack.

The more data, the better, right?

Wrong. Let me share a story about the importance of having a clear data strategy.

Early in my career, I developed a turn-key IoT solution for a semiconductor manufacturing company. My customer, let’s call him Kevin, hired the company I was working for to automate their process for characterizing new hardware chips.

Characterization is just a fancy word for putting a computer chip through every possible input you can imagine, and then recording its output to ensure it performs as closely as possible to the mathematical models’ engineers used to design that chip.

Configuring every possible input combination by hand is an impossible task. But if you could have a computer do the inputs for you and store all the output data in the Cloud, then you could save a lot of time and improve the overall quality of your product. That’s where we came in. 

Once we installed and provisioned the solution, Kevin and his team were very excited, since for the first time they were able to execute all sorts of input combinations they weren’t able to test before. The project was a big success.

A few months later, I received a call from Kevin asking for help. “We are drowning in data,” he said, “and we don’t know what to do with it.” The system we developed had a lot of high-speed sensors and actuators, producing many Gigabytes of data per second. Yes, per second. 

Running the system for just a few minutes would create so much data that they’d need weeks to make sense of all the new information. They had solved the problem of visibility, but in doing that, they had created another (maybe bigger) problem of having a lot of data they weren’t able to manage, analyze, or process in any meaningful way.

Always focus on providing insights, not data

They say hindsight is 20-20. Today it’s clear to me that I should have done a better job at understanding the ultimate goal of the customer, as opposed to just delivering what they asked for in this custom solution. Don’t get me wrong, from my company’s perspective the deployment was a success. We delivered on time and within budget, and the customer gladly signed off on their shiny new system. But in reality, we made the problem worse.

This story is not a one-off. In fact, I see this occurring over and over as I talk to Product people around the world. Companies too often focus on addressing the problem’s symptoms, rather than digging deeper to understand what the customer is really trying to accomplish. More often than not, we put a lot of emphasis on providing just data, not insights.

I was fortunate that Kevin trusted my company enough to bring us back to help them on phase 2 of the project, to address the problem of too much data. This time we were careful to dive deeper into the needs of the whole company, not only of his team.

We quickly learned that they had no expertise manipulating data, they had no data analysts on staff, and they really didn’t have the necessary knowledge to take over the system we developed for them. I spent the next few months working with them implementing a data strategy and a data management solution to address these concerns. We dialed down the amount of data they produced and were able to centralize all data (even the data coming from other departments) in a private cloud where we later added a layer of analytics and visualization. Things looked much better after that.

I’ll never forget that lesson. Machines or “things” can produce an enormous amount of data. They never get tired, so they can produce data day and night. Non-stop. Without a clear data strategy and a clear path to providing value with that data, IoT solutions are useless. They are just adding to the noise.

The importance of industry knowledge

There’s an old joke that goes something like this: A shepherd is looking after his herd when suddenly a young man in a sports car stops by. The young man asks the shepherd, “If I can guess how many sheep you have, can I keep one of them?” The shepherd agrees. The young man starts running calculations using the latest and greatest technology. “You have 280 sheep,” he says. 

The shepherd sighs and tells the young man, “If I guess what your profession is, can I get my sheep back?” The young man agrees. “You are a consultant,” he says. Surprised, the young man asks, “How did you know!” “Well, you are charging me a steep price, you are telling me something I already know, and obviously you know nothing about my business because you are taking away my dog!”

This story applies to Product Managers as well. It’s not uncommon for PMs to develop products for industries we are not that familiar with, and so we end up solving a problem that didn’t need solving or just producing a lot of data and no value.

Looking back, a lack of industry knowledge contributed to the issues we had when building Kevin’s system. It was a new industry for me (and my company). We knew how to build high-performance IoT solutions for other industry knowledge contributed to the issues we had when building Kevin’s system. It was a new industry for me (and my company). We knew how to build high-performance IoT solutions for other industries, and although the solution space translated very well, the problem space was very different.

We had spent a good amount of time learning about our customer and their pains, but we didn’t have a frame of reference for the challenges of that industry. The result: a product that was partially valuable, but didn’t solve the problem all the way.

So what is the moral of our shepherd-consultant story? Know your customer’s industry. Product Managers need to understand as much as they can about their customer’s business. In other words, you need to have deep domain knowledge. When you become an expert in the challenges that your customer and their industry peers face, you can ask better questions and make better decisions for your product, and in turn, provide more value for your customer.

3. Business Decision Area

The goal of the Business Decision Area is to help you determine whether your product idea has financial potential. In other words, will you be able to make money?

Based on the user and data decisions you made in the previous decision areas, you can now begin to make business decisions that will feed into your business plan and financial projections.

For example, you’ll need to decide your overall business model and which layers of the IoT Technology Stack you will monetize, as well as understand the costs of providing your service at each layer of the stack. You’ll also make critical business decisions, such as whether to build or buy each layer of the stack and whether to open APIs.

A recent report drawn up by the prestigious annual event, the IoT Solutions World Congress (IoTSWC), organised by Fira de Barcelona, which every year brings together the world’s leading companies and representatives of the Internet of Things for industrial application, emphasises the six drivers that will speed up the implementation of IoT in businesses and companies of every kind. For those businesspeople who are still displaying signs of scepticism, there are some very good reasons why they should consider integrating the IoT in their business processes.

1 Automation of processes


The automation of certain tasks such as stocktaking, money counting or the maintenance of staff job schedules is one of the great breakthroughs of the IoT. Entrepreneurs and managers need to distinguish between the time they spend on tasks that are really important for the progress of the business and those that, albeit necessary for the company to operate, are not directly aligned with its strategic objectives. In the latter case, finding mechanisms that automate certain repetitive tasks ends up saving time and workforce labour. However, automation also entails certain risks that need to be bolstered by cybersecurity measures.

2 Depth metrics

Management and entrepreneurs in every field will learn to interpret depth metrics relating to the behaviour of every client, as well as every worker and the progress of their business, and will also get access to detailed information on the operation of their businesses. All this valuable information needs to be processed properly using analytic systems and visualisation software. Conventional communication channels such as voice, email and even videoconferencing will be complemented by IoT devices that will take physical presence to a whole new level of interaction.

3 More flexible workforces

As well as smart factories, we will also be talking about ‘smart offices’ and ‘smart warehouses’. The emergence of the IoT in companies means that everything is speeding up. From the moment that the interconnection of devices can include any kind of element, from traffic lights to vehicles and public transport, employers and employees alike will be spending less time on commuting.

Thanks to cloud-hosted software and the tremendous versatility of certain devices such as tablets, teleworking will become a serious option for professionals from numerous sectors, from healthcare staff through to salespeople and journalists, not forgetting office workers in all kinds of public and private companies.

4 Increased productivity, reducing the IT budget

In general terms, the IoT will facilitate an increase in productivity and a reduction in IT budgets in all kinds of businesses and companies. It is likely that the costs involved in implementing sensors and updating devices and networks to host the analytics platforms will be high; but businesses will benefit almost immediately from savings in staff costs thanks to the fact that the technology will effectively resolve problems to which they previously had to devote time and manual effort. As and when the IoT becomes a generalised standard, industries such as logistics and freight transport will almost certainly automate almost all their processes.

5 Preventive maintenance with M2M communication

When the IoT becomes a fact of daily life and all devices become manageable elements of a single network, it will be even easier to manage everything remotely. With a tablet and an internet connection it will be possible to manage an entire production line, a warehouse or a library with millions of references. Many industrial machine systems for manufacturing goods that show the operational state of the production chain through local displays are getting feedback from a wide variety of supplementary sensors. These sensors connect to the factory networks to provide real-time information that will be analysed and used for preventive maintenance programmes to adjust production parameters and coordinate multiple pieces of equipment. M2M communications, which lay the foundations of the IoT, are helping to reduce the costs of the entire production chain.

6 More streamlined data analytics

Some people are calling for a deeper understanding of the importance of operating in IoT deployments equipped with tools that streamline analytics – especially those that take place at the data site (edge analytics) – in order to innovate.

4. Technology Decision Area

Based on the decisions you made in all previous areas, it is time to work with your Technology teams to decide what technology is needed at each layer to deliver the final solution. The key here is not to choose the technology yourself but to provide your Engineering team the information and requirements they need to choose the best technical solutions.

Together with Engineering, you’ll identify which sensors, device hardware, and device software are needed. You’ll design a communications topology and decide on communications protocols.

You’ll work with your team to choose a cloud platform based on data needs and performance requirements. And you’ll decide on the form factors of your cloud applications that best fit your user’s needs.

Why Do I Need to Understand the Hardware Inside My IoT Device? Doesn’t Engineering Make Those Decisions?
Yes, Engineers are responsible for researching, proposing, and executing hardware choices for the IoT device. But it’s important for the Product Manager to be involved and guide Engineering on what the product needs are so that they can choose the best solution. After all, hardware decisions will impact your product’s cost, user experience, application capabilities, and more.

The more you understand how the hardware inside an IoT device works, its nuances, and its terminology, the more empowered you’ll be to have smart conversations with your Engineering team.

The 4 Building Blocks of IoT Device Hardware
First, let’s take a look at the main hardware building blocks of any IoT device.

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:



IoT Device Building Blocks

Let’s look at each of these components.

Building Block 1: Thing
I define “thing” as the asset you want to control or monitor.

Many IoT devices integrate the “thing” into the smart device itself. 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.


IoT Smart_Device_Building_Blocks

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.

 

3rd_Party_Device_Building_Blocks

This approach 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, conveyor 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 determine 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 contains the necessary hardware to convert the sensor signal into digital information for the computer to use. It includes signal conditioning, analog-to-digital conversion, scaling, and interpretation.

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

What real-world 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.

Recommended article – Data Acquisition: A Primer for IoT Product Managers

Building Block 3: Data Processing Module
The third building block of an IoT 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 robust 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 increase the processing power needed.)
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 to perform calculations or to serve as a buffer in case you lose the connection to the Cloud.

If your IoT device 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 the radio technology for wireless communications such as Wi-Fi, LoRA, ZigBee, 3G, 5G, 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.

5. Security Decision Area
Once you’ve worked with your teams to select the implementation technology, it is time to decide how to secure each layer of the stack.

The goal of the Security Decision Area is to help you think about how each layer could be compromised and how to respond when your devices are hacked. You’ll also need to decide whether you’ll implement security testing in-house or with a vendor, and how to protect your product from being hacked from inside your own company (by employees or unwanted guests).


I gave this talk as part of Product School’s ProductCon 2018 conference in Silicon Valley. My goal was to complement the conference’s agenda with a topic that is often overlooked: securing our products.

To learn about product security, professionals usually have to attend security-focused events. This segmentation of responsibilities is having a significant impact on the overall health of our IoT products.

Covered in this talk:

Why security is the biggest challenge facing IoT products today

The devastating consequences of lacking IoT security, beyond loss of data or identity theft: a compromised product can harm human life

Real-world examples of how compromised IoT devices are causing havoc in critical industries such as transportation, energy, agriculture, and water

Why securing the Internet of Things is much harder than securing non-connected products

An updated version of Martin Eriksson’s Venn diagram with Product Managers at the center of UX, Technology, Business, and Security—showing how security is an essential responsibility of Product Management

Three ways for Product Managers to start embracing security as a key part of their role

Watch the talk (18 minutes):

 
 

Securing the Internet of Things needs to be at the forefront of our priorities as Product Managers. As attacks continue to increase, we can’t just shrug our shoulders and believe this is someone else’s responsibility. We are responsible for the whole product, and security is a part of that.

6. Standards & Regulations Decision Area

During the last stage of my IoT framework, you’ll identify the standards and regulations that will affect your product at each layer of the stack, based on your type of product, customer, and industry.

For example, does your industry have a standard data format or communications protocol that will enable your product to talk to other devices? Do your customers require you to meet certain device safety or cloud security requirements? What laws must your product comply with at each layer?

Iterate, Iterate, Iterate

There are a lot of decisions that you will need to make during the life of your product. You can’t expect to get them all right in the first pass. Therefore, it’s important for you to iterate several times throughout the IoT Decision Framework to make sure you find a balance across all the areas.

The choices you make in each Decision Area and IoT Technology Stack layer will impact all of the other Decision Areas and stack layers. You’ll need to iterate several times across the framework before you reach a solution that is consistent with all the areas and has considered all the gaps.


IoT Decision Framework - Check

For example, let’s say that in the Data Decision Area, you decide that ideally, your product would provide real-time data to your user. In the Business area, you outline the costs of providing device hardware, device software, and a cloud platform that can handle real-time data. And that’s when you realize providing this service will cost more than what your customer is willing to pay.

So you go back and decide that receiving data once per minute will be sufficient to meet your user’s needs. Then you work through the UX, Business, and Technology Decision Areas once again to make all your decisions consistent with the new once-per-minute approach.

An IoT product is more of a system than a stand-alone product. Everything is interconnected. By using this framework, you can make sure the decisions you make across all layers are consistent.

What Questions Should I Be Asking at Each Decision Area?

You may have noticed that in this post, I’m only including the IoT framework, and I’m not including a list of questions that you should answer in each Decision Area. That’s because the exact questions will depend entirely on your industry, application, and goals for the particular release you are working on.

For example, the questions you’ll need to answer for a brand new product or MVP will be very different from the questions you’ll need to answer for a mature product or even for a “version 2” product.

My IoT framework is intended as a tool to help you organize your thoughts and come up with the questions you need to answer as you develop your product strategy.

How to Get the Most Out of the IoT Decision Framework

When to Use this IoT Framework

You should use this IoT framework after you have done the preliminary product work, including defining your target audience, detailing your value proposition, analyzing competitors, and estimating the revenue opportunity.

Once you have a solid idea of how an IoT product can add value to both your company and your customers, then you can use this IoT framework to guide you through the decisions you will need to make at each layer of the IoT Technology Stack to support your overall goals.

The Internet of Things (IoT) continues to be one of the biggest buzzwords around. You hear about it everywhere: from industry publications, tech publications, blogs, and even in the news. Every article I read usually starts by stating that by 2020 (or some year in the near future), we’ll have billions of connected devices.

And it’s true that more and more IoT products are being launched every day. But unfortunately, most of the products that make the news are not giving IoT a good reputation.

In fact, IoT has gained the stigma of being “The Internet of Useless Things.”

Everywhere we turn, there seems to be a new “connected this” or “smart that.” Many applications are novel but not very useful. I can think of many silly examples, and I’m sure you can too.

So here’s my point: The fact that we can connect any device to the Internet doesn’t mean we should. And if we’re not careful, we can fall into the trap of having technology looking for a problem instead of starting with a problem and looking for the best way to solve it. This is Product Management 101.

It’s a shame the useless products get most of the airtime because there are many applications today that solve significant problems—in healthcare, manufacturing, transportation, energy, and more.

So this is a call to action for all you IoT Product Managers: Leverage IoT only if it provides more value to your customer or your company.  

IoT Is Not a Silver Bullet

During a Mind the Product conference in San Francisco, Des Traynor, Co-Founder of Intercom, said that Product Managers should keep an eye on technology trends but only adopt them if they enable you to provide a better/cheaper/faster solution for your customer.

Product Leaders need to realize IoT is not a silver bullet or a way to make easy money by jumping on the latest trend. IoT should be considered another tool in our toolbox that helps us provide more value to our customers.

In my training courses, students go through my IoT Decision Framework to analyze the viability of their proposed solution.

On several occasions, students actually discovered that IoT was not the best solution, and their customer’s needs were better solved by other types of innovation, such as service or supply chain innovation.

Imagine how much value this analysis adds in the real world, enabling a Product team to pivot before wasting time and money on a solution that won’t provide additional value.

Focus on Solving Customer Problems

IoT-solution Now let’s take a look at an opposite example.  The Brita Infinity Water Pitcher is an excellent example of a product team using IoT as a tool to solve customers’ needs.

During the 2016 IoT World Conference, I had the opportunity to hear the Brita PM explain the evolution of this product.

Brita knew that the main barrier to using their filtered water pitchers was running out of filters. To solve this problem, Brita went through several product iterations to alert customers that they would need to buy a new filter soon.

First, they added stickers to remind customers what month they would need to change the filter, but that didn’t work.

Then they added a chip that measures the amount of water you pour and blinks when it’s time to order new filters. But that didn’t work either.

Brita then realized the problem was not reminding customers to buy filters. The problem was that people had to go out of their way to actually purchase the filters. It was not convenient, or often forgot it on shopping trips, and therefore it never got done.

So they decided to create a pitcher that connects to Amazon and automatically orders filters when needed. The filters arrive just in time at the customer’s house, with no effort by the customer, solving the problem once and for all.

You see, Brita never set out to become an IoT company. They didn’t sit in their lab with IoT components trying to figure out what to build. Instead, they realized that IoT was an excellent tool to solve their user’s problems. Remember, people don’t buy IoT, they buy a solution to a problem.

You can also use the IoT Decision Framework when you are:

Creating your business plan

Defining your MVP

Building and managing your roadmap

Defining new features

Considering a product line extension

Evaluating potential partnerships

Analyzing the risks of changing any area of the technology stack

Building Your High-level IoT Product Roadmap

Let’s use an example to illustrate all the moving parts of an IoT product roadmap. Let’s pretend your company builds industrial water pumps.

After talking to a lot of customers and sales folks, you discover that a major concern for your customers is to keep operations going at all times. They would like to know if a pump is about to fail so they can proactively order parts and schedule service. This would reduce downtime and save them a lot of money. Such “predictive maintenance” is very valuable to your customers, and they are willing to pay a lot for it.

Researching solutions with engineering, you learn that as a pump ages, it starts to vibrate. The more it vibrates, the closer it is to failing. Therefore, if you were able to monitor pump vibration and perform analytics on that data, you’d be able to predict failures. With this information and some business due diligence, you determine this is a great solution and you are ready to put it on the product roadmap for internal buy-in.

Your high-level product roadmap might look something like this.


Notice that not all layers have to be impacted on every single release. In this example, there are no features in the “Communications” layer after release #1. This example assumes that the release #1 features in the “Communications” layer will be able to support the functionality of releases #2 and #3.

From this visualization, it is easy to see that release #1 is the only one that impacts your device’s hardware. Therefore, it’s easy to explain why release #1 will take longer than other releases.

You can also see that fewer layers are impacted in releases #2 and #3. The initial release will be the longest because you need to build a lot of infrastructure. Once you build that initial “plumbing”, then you’ll be able to add features on top of it at a much faster pace. You can use this tool to explain that evolution as well.

Using The Product Roadmap to Coordinate Engineering

You can also use the story mapping roadmap to coordinate multiple engineering teams across various layers of the IoT Technology Stack. Every team needs to share a unified vision of where the product is going. But at the same time, they need to understand the work that lies ahead for their specific team. This product roadmap can help you with both goals.

As shown below, you can take “vertical slices” to create specific roadmaps for each engineering team across multiple releases. As long as the data format and the interfaces between layers are well defined, this approach will enable each team to work independently and make progress faster.


Work as a Team

Product Managers are accountable for having a strong and consistent product strategy. But that doesn’t mean you should make your decisions in isolation. This IoT framework gives you an opportunity to collaborate with various departments to develop a common understanding of what the product will be.

Start by identifying who needs to be involved in creating your product strategy. Lead strategy workshops to make sure everyone is aligned; host working sessions with various departments (UX, Engineering, Finance, etc.) to gather information, generate questions for the framework, and discuss options, and get feedback from stakeholders and executives.

The result will be a stronger, more consistent strategy and a deeper level of support from your peers and executives.

Frequently Asked Questions

Is this IoT framework designed for consumer IoT or industrial IoT products?

This framework can be used both with consumer IoT products and industrial IoT products. It is true that consumer and industrial products have different outcomes, different processes, and different ecosystems. Although the process of creating those products is different, the process of creating the IoT product strategy is the same.

I know this because over 1,500 professionals have completed my IoT Product Management courses and have taken this knowledge back to their companies in all industries, verticals, and types of products.

Can I use the IoT Decision Framework for IoT product development?

The IoT decision framework is designed to help you with product strategy, not with product development.

However, the strategy informs your development process, so you need to understand the information the framework provides you before you jump into any development.

If you complete each component of the IoT Decision Framework, your team will have a much better sense of direction for your product; your product development process will be much more efficient, and you will deliver products to market faster and with less wasted development effort.

How long does it take to complete all areas of the IoT Decision Framework?

If you already have all the information, it can take as little as an hour to go over the framework. For example, if you know who your target audience is, have identified all of your users, and created all their personas, then going through the UX Decision Area will be a breeze.

The same is true for all the other Decision Areas. If you don’t have the information, then it will take you longer to complete the framework because you have to complete some research. That is one of the biggest benefits of using a framework: the IoT Decision Framework can help you understand where you need to conduct research.

In a way, it will provide you a roadmap for your product team on what research activities you need to define, where you need buy-in from internal stakeholders, the areas you need to discuss with engineering, how to approach security, and how to engage your policy team.

It’s not about how long it takes you to go through the framework itself. It’s about understanding all of the questions you need to ask and how to create a product strategy that can lead to successful market fit.

Why does the framework start with UX? Shouldn’t we start with the IoT technology instead?

No. The IoT Decision Framework intentionally starts with the UX Decision Area because from a Product Management perspective, understanding your users is the most important activity you can do. If you don’t understand your users and you can’t articulate their pain points, then it will be very hard to create a data strategy, a business model, or a technology strategy.

Many companies start with a technology-first approach, meaning they develop some piece of technology and then attempt to find a problem their product solves. But that approach is backward.

We need to start with understanding our users, and from there, we can figure out how the user’s needs flow throughout the rest of the framework, including data strategy, business models, and build vs. buy strategy. Only then can we start working on a technical solution. Remember, Product Management is about being customer-focused, not technology-focused.

Ending

IoT products are more complex than most other technology products. Using the IoT Decision Framework can help you organize your thoughts, identify opportunities and pitfalls, achieve consensus, and release the right solution faster.

Smart Bin and Smart Waste Management System: How IoT is Enhancing Waste Collection