Types of Software Roadmaps
Roadmaps have been a centerpiece of product development for a long time, and recent advancements in tooling have put them squarely in the spotlight. Every week seems to bring along another online service meant to build visually stunning roadmaps such as ProductPlan, Aha, and OnRoadmap.
With all the focus on roadmaps, I wanted to take a moment to look through how roadmaps can be used. Depending on your organization and the purpose of the roadmap, the importance of it can be very different, and the messaging to the rest of the organization can be different as well. I’ve found two key types of roadmap items I see, and the type of roadmap they end up comprising is very different, and has different applications to businesses. I’ll examine both of them with some thoughts about each.
Note: In this article I’m speaking specifically about a Product Roadmap. This means, broadly, the products and features a company is planning to release over a set period of time. There are many different kinds of roadmaps that you may see, ie a DevOps Roadmap, Technology Roadmap, etc.
Flavor 1: Themes
With this type of roadmap, a product team will decide on high level initiatives that they would like to spend time on and those become the “lanes” of the roadmap. A lane, representing an objective or theme, could be something like “Improve Customer Onboarding.” The lane will have a start and an end date, but will be vague on how this theme will be pursued. Typically, these themes will have a few core features or improvements that must be completed during the listed timeframe, but the rest is left up to stakeholders and product mangers to flesh out.
This type of roadmap is easy to translate into sales conversations as it highlights broad areas of improvement that are easy to convey. Knowing the high level theme with two or three core specifics makes it easy for all stakeholders to understand and buy into the roadmap. It’s also easy to UPOD (under promise, over deliver) this type of roadmap, as the only items committed are the bare minimum of what would deliver value and accomplish the high level objective.
If this is the type of roadmap that your company has, I’d recommend pairing it with an OKR (Objective, Key Result) metric so you can quantify progress.
Flavor 2: Feature Releases
With this roadmap, you should expect to see actual release dates next to each feature the product team commits to releasing. Often these roadmaps will correspond with some sort of release cadence. In Scrum, that may be sprints. A stakeholder would expect to see this roadmap in order to plan on having certain features or products available at given times.
Sales and marketing would use this roadmap to intrigue new customers, customer success would use it to start educating existing users, and operations may use it to inform internal processes. It’s important that dates on this roadmap are reliable, as anyone with visibility into the roadmap could start planning around what they see.
If your company has this kind of roadmap, I’d recommend tracking at least two different delivery dates: estimated delivery and actual delivery. This will allow the organization to measure and improve the accuracy of estimates over time.
Summary
If your organization is going to use a product roadmap, consider its purpose and how it will be used. One type of roadmap may be a better fit for your organization or the current stage of your product. If you find that your current roadmap isn’t effective, it may be time to re-evaluate the type of items that are added to it.
