Agile teams often view product roadmaps as an extra step that slows down the agile process. However, if you take a closer look at the Agile Manifesto, you realize that many of the principles are achievable with a product roadmap. Your agile product roadmap simply has to be different than the ones used by organizations that follow waterfall or other product development frameworks.
To understand why, let’s first understand the point of a product roadmap. We will then cover how an agile roadmap works, as well as four principles to help you create your own.
Why do you need a product roadmap?
Done right, roadmaps create functional alignment and unite your team behind a common purpose. These outcomes align perfectly with two Agile Principles — Agile Principle 4, which states that “Business people and developers must work together daily throughout the project,” and Agile Principle 5, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
You need everyone — from your customer success team to your CEO — to be on the same page about where your product is headed and why. Roadmaps enable this alignment by communicating the strategy, goals, and upcoming features of your product.
Agile Principle 4 states that “Business people and developers must work together daily throughout the project.”
If you’re using a product roadmap, achieving Agile Principle 4 becomes much easier because your team has access to a holistic view of all product-related work.
Well-executed product roadmaps also unite teams behind a common purpose. Your team can feel like a part of your greater product and business strategy rather than just a feature factory. This is what Agile principle 5 is all about.
Agile Principle 5 says to “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Creating alignment and purpose is very difficult without a roadmap. This is especially true in agile organizations where work happens very quickly, making it easy for product teams to lose track of the big picture.
How an agile roadmap works
There are a few types of roadmaps that make sense for agile organizations. Specifically, objective-driven roadmaps are an effective way to represent your strategy, goals, and high-level features. Granular features live on your backlog and don’t need to be included on your roadmap.
Here’s what an objective-driven roadmap looks like in practice:
This agile roadmap works well for a few reasons. First, it only looks two-three months in advance — a realistic timeframe for planning. In agile, you need a short timeline on your roadmap because of how quickly things can change.
Secondly, each feature is labeled with a different color so everyone can see what’s currently in production and what comes next.
The best part is that each feature is categorized under a specific objective. This helps your whole team understand how the features they own make an impact on the company and why they matter. Objective-driven roadmaps are also easy to update on a rolling basis, giving you flexibility on delivery dates and timelines. Flexibility is crucial in an agile environment.
This roadmap enables you, as a product manager, to explain to the entire organization why one feature may go into development over another. For example, your head of sales might ask why a feature they requested to close a sale is not immediately going into development. Pointing to your roadmap, you can refer to high-level product goals and explain why other initiatives are prioritized.
4 principles of agile roadmaps
If you’re familiar with the Agile Manifesto, then you’ve probably read the 12 principles of agile development. These principles were created by 17 software developers in the early 2000s and explain what agile is all about.
We think agile roadmaps need their own set of principles — loosely based on the original 12 agile principles — that tie your plan to the agile development process. This, in turn, makes your roadmap a living document that improves alignment and buy-in.
1. An agile roadmap must be a guide rather than a rigid set of rules
Product roadmaps are debated in agile because the roadmaps of times past have not been flexible. Traditional roadmaps place a lot of emphasis on the what and the when. As in, “Feature X will be delivered in our Q4 release.”
Modern, agile roadmaps must be flexible. This flexibility ties directly into the second principle of agile, which says “Welcome changing requirements, even late in development.”
To make your roadmap flexible, it should focus on the why and include just enough detail on the what and when so stakeholders understand what’s coming. That’s what makes objective-driven roadmaps a perfect fit for agile. The objectives help you focus on why you’re delivering specific features, and provides insight on delivery dates and what is being delivered.
To make your roadmap flexible, it should focus on the why and include just enough detail on the what and when so stakeholders understand what’s coming.
2. Agile roadmaps offer a high-level overview of where your product is headed
Agile Principle 10 states that “Simplicity is essential.” Take this same approach with your roadmap. A roadmap that looks like a backlog is not simple enough. It’ll be too cluttered with hundreds of features that may never make it into development.
Instead, only include “need to know” information on your agile roadmap:
- What’s the strategy?
- What are the goals you want to achieve?
- When do you want to achieve these goals?
- What high-level features are needed to achieve these goals?
Keep in mind that the roadmap is a high-level document for fostering alignment. There needs to be just enough detail, but not too much. For example, your product strategy may be a multi-page document, but on your roadmap it must be summarized concisely.
3. Agile roadmaps stay within realistic timeline
Traditional roadmaps were built for the long-term — usually at least 12 months out. Agile roadmaps can’t have this long of a timeline because of how often working software is delivered.
Agile Principle 3 says, “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Your roadmap needs to match the timeline of your development team. Keep your roadmap limited to the next few months and update it on a rolling basis. Though you’ll be reworking your roadmap more often, it will allow you to be more flexible.
4. Agile roadmaps make room for user feedback
Agile Principle 1 states that “Our highest priority is to satisfy the customer.” The customer is the whole reason your product exists. So, if you are a proponent of agile, you should invite your customers to have a say in what goes into your product roadmap.
Let customers view the features you are considering for you roadmap. You can do this by using a feature voting functionality in your product management system. Feature voting lets users vote on the features they want via a public portal that maps out what’s being considered for your product and why. This can help you validate any ideas that you have, and gives users a platform for proposing new ideas.
Stay agile with an objective-driven roadmap
We hope we’ve provided a compelling argument for why objective-driven roadmaps are the secret of high-functioning agile product organizations. Not only do they provide the most flexibility, they help establish a realistic timeframe for product development and reorient focus to the why of your product.
So, while some agile practitioners don’t believe in product roadmaps, it’s likely that they simply need to try a new approach. We encourage you to give agile-inspired roadmaps a try.
. . .
productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a free trial of productboard today.