How to Build and Maintain Product Roadmaps

In a past article, The Art of Writing Good User Stories, I provided best practices for creating the most granular level of a product backlog definition, the user story. In this article, I want to focus on a higher level view, your product roadmap. Before I jump in, let’s recall a common approach to dissecting a product:

Business Goals/Strategy -> Product Goals -> Product Features -> Product Epics -> User Stories

With this approach, a product roadmap provides visibility of delivery and maturity at the Product Feature level, and which business goals are having an impact.

What a Product Roadmap Isn’t

In order to get a better understanding of what a product roadmap is, it is important first to understand what a product roadmap isn’t. A product roadmap is not a backlog, is not a release tracker (burn up chart) and definitely is not a release schedule. One of the most common misconceptions about a Product Roadmap is that it provides visibility of when a feature should be expected or the specifics of the feature to be delivered.

So Then, What Is a Product Roadmap?

The purpose of a product roadmap is to provide visibility of your product strategy. It provides insight into which features are currently being developed and more importantly, which features could be developed in the future. This artifact is commonly observed by internal stakeholders, sometimes by external stakeholders and mainly maintained and consumed by the product owner. Ideally, the product roadmap should be a single, living, simple and easy-to-read view of your product strategy.

Sometimes a product roadmap includes when certain features are expected to be delivered but it is best practice not to impose hard deadlines. Deadlines should be included on a release tracker. This is important because features listed in a roadmap may not even exist in the product backlog, therefore the product/feature/scrum team hasn’t had the opportunity to estimate the effort to deliver the feature. In other words, there has been no substantial analysis to commit to a date and scope.

In a way, the product roadmap states your intentions to develop certain features but is in no way a commitment. Once the product owner compiles information from industry trends, market needs, business goals, capacity planning, customer support feedback, business development feedback, marketing data and others, and refines the intended feature, breaks it into epics and stories to be prioritized, the roadmap will change. Features that are near being developed, will have more clarity in terms of scope and required effort, and then can provide a release scope and schedule for that specific feature. At that point, it is time to provide more accurate dates.

Product Roadmap vs Release Schedule

• A company is currently developing a music streaming platform.
• It’s business goal is to reduce subscriptions churn and increase new subscribers to increase it’s monthly recurring revenue by 15% YoY.
• A way to achieve that business goal is through the definition of one or more product goals. In this case the company would split it into two:
  • To reduce subscriptions churn, based on captive users feedback, product management has defined the following product goal: Provide a more enriching listening experience by suggesting new music to subscribers by holistically analyzing subscriber listening and browsing preferences.
  • To increase new subscribers, based on industry trends and market competitors, product management has identified this product goal: Increase accessibility of the platform by increasing total supported devices by 30%.
• Once product goals are defined, the company can specify the product features that will aid the product in reaching its goal. The relationship between Product Goals and Product Features is similar to Objectives and Key Results (OKRs) relationships, meaning Key Results drives Objectives completion, and Product Features drives Product Goal fulfillment. These are the product features that could help achieve the product goals that are aligned to the business goals:
  • Product Feature #1: Integrate with social media platforms to provide better content suggestions to subscribers based on the user’s social media browsing history and preferences
    • Helps to achieve Product Goal #1: Provide a more enriching listening experience by suggesting new music to subscribers by holistically analyzing subscriber listening and browsing preferences.
    • Helps to achieve subscription churn reduction Business Goal.
  • Product Feature #2: Support IoT devices to stream content without needing a mobile device or computer
    • Helps to achieve Product Goal #2: Increase accessibility of the platform by incrementing 30% the total of supported devices.
    • Helps to achieve 15% YoY increase of monthly recurring revenue Business Goal.

Based on this information, a simple but useful product roadmap would look like this:

In the above example, Product Management is surfacing visibility that the “Integrate with social media platforms for better suggestions” product feature is being worked now and will continue being worked. Also, the “Support IoT devices to stream content without needing a computer” product feature is longer than the integration feature and will take more time to be delivered.

Another aspect to notice in the product feature definitions is that they are specific enough to surface product goals fulfillment but are not that specific in terms of what those product features contain. For further clarification of a product feature scope, it is advised to make use of Business Requirements Document, Market Requirement Documents and Product Feature Specifications that will then feed the backlog in form of Epics.

Now that we have a solid idea of what a simple but useful product roadmap looks like, we can drill down to how a release schedule would look. Please note a release schedule drills down to a more granular level and specifies not only product features but epics that will complete those product features. The epics that are directly related to each product feature are color coded. (e.g. yellow for social media integrations, cyan for IoT integrations):

You can see that the social media product feature is going to be worked between October and November, and we will deliver a Facebook integration by mid-November and Instagram integration by the end of November. These dates are committed because they are already refined and estimated by the scrum team.

How to Connect a Product Roadmap to a Release Schedule and the Product Backlog

When you are working with complex products, complications are expected while trying to maintain the 3 living documents updated and consistent. One very useful artifact to keep those connected at all times is called User Story Mapping, defined by Jeff Patton. A user story map helps visually represent the connection between Product Features, Epics, Stories, and when those stories are going to be released. In other words, a User Story Map is a visual representation of how each product feature will be matured.

Final Thoughts

Now that you are familiar with the differences between and uses of a Product Roadmap, Release Schedule and Product Backlog and how those relate to provide visibility of Product Strategy and Execution, it is time to experiment and define your own artifacts to ensure you are surfacing the correct visibility and focus to add value in alignment to your business goals and initiatives.

[adinserter name=”Software-Development-eBook-Offer”]