How to Differentiate Your IoT Product: Provide Insights Not Data

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.

This is one of the key objectives of going through the Data Decision Area in the IoT Decision Framework.

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

The Bottom Line

Many IoT products today focus on producing data instead of insights. This results in disappointed customers that are not able to capitalize on the value of the solution and are forced to do extra work to extract useful information out of the data.

As Product Managers, it’s our responsibility to understand our customer’s world, including having a good understanding of the most common challenges of our target industry. Only then will we be able to craft a solid data strategy that solves our customer’s needs.