Companies are looking for to the Internet of Things as inspiration to discover product opportunities. They see it as an opportunity to leap-frog the competition and significantly grow their revenues. And yet, many companies are failing and growing disillusioned. So how can Product Leaders leverage IoT to discover product opportunities that can take their company to the next level?
In this post, I look at proven Product Management techniques to identify problems and then explore how IoT can help you build products that solve those problems.
The Internet of Things, both for consumer and industrial applications, is still at a very early stage of development and adoption. A recent study by Cisco revealed that over 70% of all IoT initiatives fail. Although many factors contribute to this statistic, the one constant I’ve seen across companies large and small is the lack of a process to understand their customers’ needs and then build products to address those needs.
I’ve written before about this challenge, cautioning companies to avoid thinking of IoT as a silver bullet. “IoT” is not a strategy, it’s just a tool. In fact, people don’t buy IoT, they buy a solution to a problem. Therefore, how should companies work to discover product opportunities that leverage IoT?
The approach I recommend in my IoT courses has three parts: Discovery, Ideation, and Validation.
If you are familiar with UX research or Lean techniques, you’ll find this approach very familiar. I don’t plan to reinvent the wheel. My goal is to take the best of these approaches and look at them through the lens of an IoT Product Manager.
A Process to Discover Product Opportunities
The first step to discover opportunities is to identify potential problems your company could solve by leveraging the Internet of Things. I like to use the term “discovery” because our role as Product Managers is to understand the customer’s pains and then work with our teams to figure out a solution.
In other words, we are not “inventing” new problems that we hope our customer has and then providing a solution. Not at all. Our goal is to understand the problems they already have, and then figure out how we can provide a better solution to their existing problems.
In this stage of the process, we are in the “problem space,” as described by Dan Olsen in his book, The Lean Product Playbook.
As a side note, I want to debunk a common myth about innovation. Many people believe we shouldn’t “ask” customers what products they want, and therefore, we shouldn’t invest in customer research. The thinking goes that if we talk to customers, then we are not innovating.
This is the wrong approach. Customers have pains and needs, and those exist with or without your product. Innovation is not about “inventing pains and then solutions.” As Product Managers, our role is to understand the existing pains and THEN work to provide an innovative solution. Therefore, innovation happens in the solution space, not in the problem space.
OK, now that we all agree we need to talk to customers, how do we go about doing it? There are many ways to do it, but here are three of my favorite techniques. These are not mutually exclusive, so you can mix and match to get the best results.
The goal of this technique is to “observe users in the wild.” By visiting customers at their facilities or in their homes, we can learn a lot about how exactly they experience the pain and a lot about their environment.
There is nothing more eye-opening than visiting a customer’s space and realizing that the pain that you thought they had is not that important. Or to learn that they are “on the run” all day; therefore, they will never use your desktop dashboard.
Performing contextual inquiries requires planning and coordination since you have to find customers willing to give you access to their lives and then coordinate with their hectic schedules.
In the B2B space, this could mean a trip to a power plant or a manufacturing facility. If your customer manufactures trains, it could mean taking a ride on their trains. In short, you need to go wherever they are feeling the biggest pain.
So how many of these interviews should you do? It’s hard to say. The real answer is that you should do as many as needed for you to uncover patterns you can use to transition into the solution stage.
From my experience, visiting 10-12 qualified customers will give you a strong sense of what their pain points are.
Sometimes it is hard to visit all these customers, so you can complement your research with remote interviews via phone or video conference. This approach is also very revealing, and you can go through more interviews in less time and with less cost.
If you are new to performing these interviews, I highly recommend Steve Portigal’s book, Interviewing Users: How to Uncover Compelling Insights.
Now, how many interviews should you do? As many as you can. In fact, Dr. Rob Adams states in his book, A Good Hard Kick in the Ass: Basic Training for Entrepreneurs, that you should conduct at least 100 of these interviews. Only then will you know if the pain you’ve identified is widely spread across your industry or if you are looking at a one-off scenario.
Surveying your customers and prospects is also an excellent way to get valuable insights. In this case, you are gathering quantitative information, as opposed to the qualitative information you gather from utilizing the previous two techniques.
Surveys are useful for testing a problem hypothesis at scale. For example, if using the previous techniques you’ve honed in on a particular problem, you can then use surveys to query a much bigger audience to understand if that particular problem is something they experience as well. That way, you’ll have more certainty that the problem you discovered is worth pursuing. But more on that later.
By using these three techniques, you’ll be able to understand your customer’s pains, and you will be better armed to go into the ideation stage.
By the way, the discovery stage is a perfect opportunity for Product Teams to partner with other teams (i.e. UX and Engineering) to discover opportunities together. Discovery is not something PMs should do alone.
You’ll get the most value if you perform this (and all) activities as a multi-disciplinary team. Involving Engineering at this stage is very valuable, not only to get their input but also to get their early buy-in into the possible results.
Coming Up With Solutions – The Ideation Stage
Now that you’ve identified a few problems worth solving, you can move into the “solution space”. In this stage of the process, the goal is to work with your team to identify potential solutions you could implement.
Keep in mind that you’ll need to focus on ideating solutions that align with your company’s core strengths and strategic direction. For example, if you are working in the Energy Efficiency space, and you discover that the biggest pain for building managers is water efficiency, then you might need to do more research since water management might be outside your company’s capabilities. The fact that your customer has a problem doesn’t mean you are the best person to solve it (or that customers are willing to buy from you in that particular area).
An excellent way to come up with potential solutions is to facilitate internal brainstorming sessions with a multi-disciplinary team. By including members from various areas of your company, such as UX, Engineering, Sales, Marketing, etc., you increase your chances of coming up with the best ideas.
It is at this stage that you can start introducing the Internet of Things as a possible tool to provide the best solution for your customer’s pain. At its core, IoT products have sensors that collect data you can use to provide value.
Recommended reading: Internet of Things: A Primer for Product Managers.
So here’s a question you can use to lead brainstorming sessions to discover product opportunities:
“If we had sensors in the customer’s environment, how could we leverage that information to address their pains?”
For example, let’s say your company provides solutions for the trucking industry. In your research, you discover that their main pain revolves around the high cost of fuel. Therefore, if you were able to come up with solutions to reduce fuel consumption, you’d be directly addressing their problem.
In this example, the brainstorming session might go something like this:
Product Manager: “If we had sensors in our customer’s trucks, how could we leverage that information to help them reduce their fuel expenses?”
Brainstorming team (possible ideas that leverage the Internet of Things):
- “Deflated tires increase fuel consumption. If we add sensors to monitor tire pressure, we could create alerts or even create a self-inflating tire mechanism to fix the problem automatically.”
- “Speeding increases fuel consumption. We can add sensors to the engine to monitor driver performance and curtail speed as needed.”
- “We could also track fuel efficiency by driver and create a system of incentives for the most fuel-efficient drivers.”
From this brainstorming example, you can see that IoT is a tool you can use to solve a generic customer problem. The innovation on your company’s part comes from how you’ll implement your solution, where you’ll place the sensors, what type of data you’ll collect, what machine learning algorithms you’ll develop, what business model you’ll come up with to reduce purchasing friction, etc.
Validating the Proposed Solution
Now that you have some possible solutions that might solve the customer’s problem, it’s time to continue your research to figure out if those solutions are a good fit for both your customer and your company. In short, it’s time to validate your proposed solution.
I know the term “validate” is controversial since it implies you know what the right answer is and you are just validating it. But that’s not what I mean here. I’m using “validate” to imply the process of testing your hypothesis. I’ll continue to use the term validation since it’s a very common term, but I wanted to make that distinction.
When validating a proposed solution, you need to evaluate whether:
- Your solution meets your customer’s needs.
- Your customer is willing to pay for that particular solution.
- The solution is viable, meaning it is something that your company can realistically implement, deploy, and monetize.
This is the stage at which I see most companies struggle when planning IoT products. To determine whether your solution is viable, you have to anticipate many decisions you’ll need to make in UX, Data, Business, Technology, Security, and Regulation. Decisions in any one of these areas could make or break your product.
The hurdle most companies face is not having a structured approach to performing this validation. To get you started, I recommend getting familiar with my IoT Decision Framework as a structured approach to evaluating all decisions within your IoT product strategy.
Where You’ll Get Pushback
If you decide to implement this discovery-ideation-validation process at your company, be prepared for colleagues who will say that this approach takes too long or costs too much.
To that I would say, you can’t afford NOT to do it. If you can take a few extra months and a bit more budget to make sure you’re targeting the right problem with the right solution and a solid strategy, you will tremendously increase your product’s chances of success.
In fact, you will likely speed your time to market and reduce your development budget, because you will hit the target sooner, rather than struggle with failure after failure until you learn the expensive way.
The Bottom Line
The process I share in this post provides an iterative approach to discovering, ideating, and validating IoT solutions.
Although the approach has three stages, it can go as fast or as slow as you want. The goal is to iterate as fast as possible so you can quickly arrive at a solution that has potential in the market.
I guarantee you that if you are willing to invest time iterating on this process, you’ll accelerate your company’s innovation pace and you will save millions of dollars by not jumping into developing solutions that won’t meet your customer’s or company’s goals.