{"id":23096,"date":"2021-02-02T10:34:17","date_gmt":"2021-02-02T15:34:17","guid":{"rendered":"https:\/\/www.3pillarglobal.com\/?p=23096"},"modified":"2025-05-21T16:24:09","modified_gmt":"2025-05-21T16:24:09","slug":"how-to-build-and-maintain-product-roadmaps","status":"publish","type":"blog","link":"https:\/\/www.3pillarglobal.com\/insights\/blog\/how-to-build-and-maintain-product-roadmaps\/","title":{"rendered":"How to Build and Maintain Product Roadmaps"},"content":{"rendered":"

In a past article, The Art of Writing Good User Stories<\/a>, 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\u2019s recall a common approach to dissecting a product:<\/p>\n

Business Goals\/Strategy -> Product Goals -> Product Features -> Product Epics -> User Stories<\/p>\n

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.<\/p>\n

What a Product Roadmap Isn\u2019t<\/h2>\n

In order to get a better understanding of what a product roadmap is, it is important first to understand what a product roadmap isn\u2019t. A product roadmap is not a backlog<\/strong>, is not a release tracker<\/strong> (burn up chart) and definitely is not a release schedule<\/strong>. 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.<\/p>\n

So Then, What Is a Product Roadmap?<\/h2>\n

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.<\/p>\n

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\u2019t 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.<\/p>\n

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.<\/p>\n

Product Roadmap vs Release Schedule<\/h3>\n