How to Build Solutions Your Customers Want (And Are Willing to Pay For)

The Internet of Things, both for enterprise 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. This is where incorporating Design Thinking techniques can really help you bridge that gap.

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 leverage Design Thinking to discover product opportunities that leverage IoT?

The approach I recommend in my IoT courses leverages Design Thinking and has three parts: Discovery, Ideation, and Validation.

If you are familiar with UX research or Lean techniques, you’ll find this Design Thinking 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.

If you are new to these ideas, I recommend this article that explains in more detail what Design Thinking is about and how it relates to Lean and Agile.

Design Thinking – 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 better solve their existing problems.

In this stage of the process, we are in the “problem space,” as Dan Olsen described in his book, The Lean Product Playbook. You can also listen to my conversation with Dan Olsen in my podcast.

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.

Onsite Interviews

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 their pains and the environment in which those pains occur.

There is nothing more eye-opening than visiting a customer’s space and realizing that the pain 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 onsite interviews 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 Enterprise or Industrial 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 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.

User interviews

Sometimes it is hard to visit all these customers to 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, in his book, A Good Hard Kick in the Ass: Basic Training for Entrepreneurs, Dr. Rob Adams states 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.

Surveys

Surveying your customers and prospects is also an excellent way to get valuable insights. In this case, you are gathering quantitative information instead of 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 to get their input and 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, you discover that the biggest pain for building managers is water efficiency. 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 develop 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.

At this stage, 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 could 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

Let’s continue with the Design Thinking journey. Now that you have some possible solutions that might solve the customer’s problem, it’s time to continue your research to determine 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 prevalent term, but I wanted to make that distinction.

When validating a proposed solution, you need to evaluate whether it is desirable, feasible, and viable:

• Your solution meets your customer’s needs – desirable
• Your company is able to monetize that solution – viable
• Your company can realistically implement, deploy, and maintain that solution – feasible

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

Design Thinking and the process I share in this post provide 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 to quickly arrive at a solution that has potential in the market.

I guarantee you that if you are willing to invest time incorporating Design Thinking techniques into your development 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.

*Photo by Alvaro Reyes on Unsplash