Let’s face it. Building an IoT product roadmap is hard—much harder than building roadmaps for “normal” technology products.
That’s because IoT products are complex systems. To create a working solution, all layers of the IoT Technology Stack—device hardware, device software, communications, cloud platform, and cloud applications—need to work together. It’s like having to manage five products in one, and your roadmap needs to be the glue that keeps all your stakeholders aligned with your vision.
The IoT Roadmap—Your Key to Aligning Stakeholders and Teams
An IoT 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 at 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.
Suggested 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 in the roadmap for internal buy-in.
Your high-level roadmap might look something like this.
Example of high-level roadmap
As you can see, this is no different than the 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 Roadmap
For your IoT roadmap to convey the full story, you need to provide another level of detail describing the features of the high-level 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 to 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 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 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.
Suggested reading: A Product Management Framework for the Internet of Things
Using The 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 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 team-specific 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.