How to Build an IoT Product Roadmap

The IoT Product Roadmap —Your Key to Aligning Stakeholders and Teams

An IoT product roadmap needs to show the product direction as well as the impact of new features in a way that makes sense for all stakeholders. Your stakeholders might be from Sales, Marketing, the Executive team, Engineering, and more. They all have different needs and different levels of understanding of how the product is put together.

In fact, IoT introduces additional complexity because even the technical implementation is probably split across multiple groups. Depending on your company’s structure, you might have dedicated teams for hardware vs. software, embedded vs. cloud development, etc. No single team will have a holistic understanding, which makes it even more important for you (and your roadmap) to communicate the full picture.

Because of this complexity, managing an IoT product is similar to managing a portfolio of products, with the distinction that ALL the products in your portfolio need to work together to form a cohesive solution. Not an easy task.

The key to creating a solid IoT product roadmap is to balance a high-level view of the end-to-end product with more detailed views of each layer of the IoT Technology Stack. That way, you’ll be able to provide the right level of information for your different stakeholders and ensure nobody loses sight of the big picture.

Recommended reading: Internet of Things: A Primer for Product Managers

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.

Example of a high-level product roadmap

As you can see, this is no different than the product roadmap for a non-IoT product. The challenge here is that it is very difficult for your stakeholders—Executives, Sales, Marketing, and Engineering—to understand what it will take to build this functionality and what the final product looks like. It’s also difficult to understand why release #1 will take 6 months and release #2 and #3 will be shorter.

Using Story Mapping to Enhance Your IoT Product Roadmap

For your IoT product roadmap to convey the full story, you need to provide another level of detail describing the features of the high-level product roadmap across the IoT Technology Stack.

I’ve found that story mapping is a great way to dive into this next level of detail. I like to combine story mapping with the IoT Technology Stack to show how features align with the various layers of the end-to-end IoT product.

The result is a visualization that is still higher level than a “product backlog”, but gives enough information for all teams to understand the big picture. This view also empowers teams to understand how the planned functionality relates to the day-to-day work they’ll need to do.

Here’s how this approach would look for our “smart pump” example. From this view, it is easier to explain the work that needs to get done to support the predictive maintenance functionality. Notice how the names of the high-level features in the previous product roadmap became the theme for each of the releases. This helps your team keep an eye on the big picture while still focusing on smaller details.

Example of story mapping a product roadmap

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.

Recommended reading: A Product Management Framework for the Internet of Things

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.

Example of a team-specific product roadmap

The Bottom Line

As a Product Manager, you will always face challenges when communicating the product vision throughout your company. It’s a difficult task, and yet it is probably the most important function of our role. The approach outlined in this post provides you with a very powerful communication tool you can use to clearly express your product ideas and get everybody aligned. The result: increased transparency, which results in better communication, happy teams, and happy customers.

Quick favor. If you really enjoyed this article, then it’d be a HUGE help if you shared it with other product folks (you can use the share icons). It might seem insignificant, but it helps me more than you might think. Thanks!

PS: I originally wrote this article as a guest post for the ProductPlan Blog.