In today’s article, we’ll discuss the agile roadmapping process. We’ll start by reviewing the objectives of roadmaps and planning for agile teams, then share some special considerations for agile roadmaps. From there, we’ll walk you through the agile roadmapping process step by step.
Decades before agile’s inception, Dwight D. Eisenhower famously declared plans useless. But what many of us forget is the second half of his declaration; planning is indispensable. In most contexts, war and product development are completely different beasts. But in the context of planning, agile software development practitioners are wise to take Eisenhower’s words to heart.
“In preparing for battle, I have always found that plans are useless and planning is indispensable”
– Dwight D. Eisenhower
Why Agile Teams Need A Product Roadmap
We’ve discussed the importance of strategic product roadmaps for agile teams on several occasions before this one. I won’t rehash those articles in full, but, before we dive into the “how” of creating agile product roadmaps, a quick review. What purposes do product roadmaps serve for agile teams?
The roadmapping process facilitates planning activities.
The journey to an agile roadmap is just as important as the destination. Agile planning and the process of agile roadmapping itself has a great deal of value on its own—it forces teams to get out of the weeds and think strategically. “There is a stark difference between a plan and planning. In agile, we don’t plan the work and work the plan. Instead, we consider the idea of planning.” explains Amelie Watt, a Product Manager at Elevator Up, “This way, we’re able to remain flexible when plans change and quickly adjust according to new requirements and ideas….agile planning is a pretty grey area, and it’s meant to be treated that way.” We dive deeper into this quick guide to agile product management. I highly recommend the read.
High-level roadmaps highlight key focus areas.
As Claire Drumond, Atlassian Product Marketing Manager explains, the process of agile planning and roadmapping helps the entire team succeed. “Setting your high-priority themes will help you focus your time and energy to do a few things really well,” she explains. An agile product roadmap serves as a navigational tool. It helps teams focus on where they are going and why while also giving them the freedom to course-correct as needed.
An agile roadmap is a critical communication tool.
Agile roadmaps help product teams communicate product strategy with other parts of their organization and get buy-in from key stakeholders.
Traditional Roadmaps vs. Agile Roadmaps
There are several reasons people struggle to see how roadmaps align with agile practices. Usually, though, the disconnect comes from their perceptions of what roadmaps are. Oftentimes people think about roadmaps and picture “traditional,” static, sequential long-term roadmaps. While there’s nothing wrong with traditional roadmaps themselves, they’re simply the wrong tool for the important job of agile planning.
Jeff Gothelf, author of Lean UX explains the dilemma of agile roadmapping well, “One of the biggest challenges in product management is planning the work in a linear, visual way…Digital product development is not linear. It is iterative. We build some things. We ship them. We see how they impact customer behavior. We iterate them and ship again.”
That’s why the right tool for the job is an agile roadmap—built to reflect the iterative manner of agile development. Here are a few ways agile product roadmaps can differ from traditional ones.
Agile roadmaps communicate the strategy, not the plan.
Agile product roadmaps are high-level and strategic. They focus on outcomes rather than outputs and talk in themes and epics rather than features. And, they do not represent tactical plans. You can leave that up to the backlog.
“A lot of roadmaps are dominated by features and functionalities to be delivered. The disadvantage of focusing on features too much, is that there are always too many features that would add value, therefore creating a lack of focus on the vision and goals.” explains Robbin Schuurman, “By focusing on the features too much, the roadmap will turn into an overloaded product backlog, instead of a high-level, strategic plan for the product’s future development.”
In many ways, you can think about your agile roadmap as a communication tool. This brings us to our next point…
Agile product roadmaps communicate uncertainty.
Some agile product teams are roadmap-averse because they don’t see the value in planning and communicating a plan that is bound to change. Or, because they’re concerned about how stakeholders will respond to changing plans. But, when done correctly, agile roadmaps not only communicate a high-level strategy, but also the varying levels of certainty around each of their parts. This provides transparency into what parts of the roadmap are likely to stay as is, and what parts may be in flux.
In general, you want the near-term stuff to have the most certainty and detail, and the longer-term, further out stuff to have the least.
Update your agile roadmap often.
Whether a roadmap is agile or not, it should never be static. But agile product roadmaps, in particular, are highly dynamic by nature. That means they should also be easy to update on the fly.
Agile teams learn new things every day, which is part of the beauty of agile processes in the first place. These new findings frequently make their way onto the roadmap in the form of anything from shifting priorities to new solutions altogether. And agile roadmaps have flexible formats that support the addition of new findings, quick adjustments, and course corrections.
But a word to the wise. Use caution when deciding how many small details make their way onto the product roadmap based on new findings. Don’t forget that it serves as a high-level communication tool that helps other groups within your organization understand the strategy. If you add too many tactical items or “feature ideas,” you risk blurring the line between the roadmap and backlog.
Frequent communication about changes to the roadmap is critical.
The only constant is change. But agile roadmaps make communication a constant as well. When the roadmap changes (which it will), its entire audience needs to know about those changes.
6 Step Agile Roadmapping Process
Now that we’ve addressed a few considerations for agile roadmaps, let’s walk through the agile roadmapping process step-by-step. You may recognize many of these steps as being standard steps for creating any product roadmap. That’s because the process is fairly similar to any roadmapping process. What is different, however, is the final product and how it is used.
1. Understand business objectives and KPIs.
Like any other type of strategic planning, the agile roadmapping process starts with objectives. After all, if you don’t know where you’re trying to go or why, how do you expect to come up with a smart plan for getting there? So before you dive in, make sure you and your team have clear objectives and measurable KPIs to work with.
2. Revisit the product vision.
Business objectives and KPIs are usually tied to somewhat near-term timelines (i.e. current quarter, fiscal year, etc.). You also need to consider longer-term objectives while you’re making your agile plan as well. That’s where your product vision statement comes in. Revisit your product vision statement before you start planning and keep it top of mind throughout your planning process. The vision statement represents a long-term aspirational goal for the product and you want to ensure that your plan aligns with the vision as well.
3. Talk to customers.
Product managers, and quite frankly, anyone on a cross-functional agile team, should speak with customers daily. Insight into what customers need and want is fuel for planning. So if you’ve slacked off a bit on the customer calls, catch up before you attempt to make a roadmap. It’s worth noting that most product managers also serve internal customers in addition to end-users. Don’t forget to have conversations with internal customers as well.
4. Start thinking in themes.
Once you’ve spent some time thinking through both long and short-term objectives, and had some conversations with customers, you can start focusing on the problems you want to solve. Most likely, steps one through three in this process have helped you identify several problems worth solving. These make great themes to structure your product roadmap around. Rather than making a list of several frequently requested features, make a list of problems worth solving. These are your roadmap’s themes.
5. Prioritize.
Once you have identified several themes your team has deemed important, you need to prioritize them. After all, you’ve got limited resources and can’t tackle everything at once. So, with consideration given to your KPIs, product vision, and available resources, you can start ranking your themes. We recommend using one of the many objective prioritization frameworks out there to help prioritize your roadmap.
6. Build.
When you actually build your roadmap, consider its various purposes. For example, you may need to present it to executive stakeholders to get buy-in on your plan. But perhaps your engineering team also wants to see a version of it. Consider making different versions of your roadmap for the various different audiences who will see it.
Finally, there’s one last step in addition to the 6 above. Iterate. Much like the products produced by agile teams, agile roadmaps are iterative. Agile planning and the agile roadmapping process are ongoing activities, not boxes to check on your to-do list.
