Today, it’s hard to find a product development team that doesn’t describe itself as agile. In fact, agility, or the ability to respond to change in your market, is often considered one of the most significant predictors of a company’s success. But with all of the emphasis placed on an agile approach, some teams worry that the idea of creating and maintaining an agile product roadmap isn’t feasible.
However, the practice of maintaining a product roadmap isn’t as inherently anti-agile as some might have you believe. In fact, there are plenty of techniques that can not only help you craft a more agile-friendly product roadmap but even one that supports your team in their agile goals.
Making the Most of Your Agile Product Roadmap
But to better understand how a roadmap can better enable your agile team, we must first distinguish between two often-confused concepts: a product roadmap and product vision.
1. Understand your product vision.
In its simplest form, a product vision describes the value that your product will deliver to your customers, as well as how that value will ultimately enable your company to win in the marketplace. Great product visions are clear, inspirational, and paint a compelling picture to which your team may aspire. While unexpected events may arise in your market that can force your product vision to change. Write your vision at a high enough level that such reactive changes should be rare.
A product roadmap, on the other hand, describes your company’s plan for achieving that product vision. However, like all plans, this plan can change as new, previously unknown opportunities emerge to achieve your vision.
For example, incremental advancements in technology may emerge that result in some product ideas becoming more feasible. Or, unexpected opportunities in the market might appear on the horizon that your company would be foolish to pass up. These might include a previously unattainable prospect initiating a discussion with your company, or a stumble by a competitor that unexpectedly opens up new market opportunities.
In any case, the important takeaway is that not only can agile product roadmaps change, but for companies to survive in a volatile marketplace, they must change.
2. Find the right amount of flexibility.
For this reason, it should come as no surprise that the key to getting the most from your product roadmap, especially in a dynamic and rapidly changing market, is flexibility. But how much flexibility is enough?
An agile product roadmap must remain flexible to better respond to emerging opportunities. However, it also must still provide clear direction for your team—at least in the short term. This direction often appears through prioritization, by painting a clear picture of what your organization feels is the most valuable for your team to work on today versus what is likely to be the most valuable 6 to 12 months in the future.
This glimpse into the future not only gives your team insight into the bigger picture of your product, and how the work they are doing today fits into that picture, but it also enables them to make better-informed decisions in their work today.
It’s this use of your product roadmap to better communicate your long-term strategy to your team that highlights one of the most useful benefits of a product roadmap, a communication tool.
3. Inspire a discussion around team goals.
While agile product roadmaps are excellent tools for planning both your product strategy and the supporting execution, where they truly excel is in the communication of that strategy.
A well-crafted product roadmap should inspire a discussion about the goals your organization is striving towards in the next few months as well as your plan to achieve those goals. These discussions should elicit questions that assess if your roadmap accurately reflects your organization’s priorities, what dependencies exist between items on your roadmap, and if the items on your roadmap are the best investment for your organization.
It’s this last question that’s possibly the most important. It highlights a common criticism about product roadmaps: that organizations can sometimes become constrained to the items already placed on their roadmap, robbing them of the opportunity to innovate. But by regularly re-evaluating the items on your roadmap, you can help protect your organization from becoming a slave to its product roadmap.
4. Communicate your agile product roadmap at the right level.
Despite the value that a product roadmap offers as a communication tool, to be truly successful, you must remember that not everyone in your organization will require communication at the same level. For example, you’ll often find that your executive team is most interested in discussing items at the strategic level, while your product development team benefits most from a discussion at the tactical level.
Adept roadmap authors recognize this disparity and often create multiple views of the same roadmap, each tailored to their audience’s specific needs. For example, you might develop a view of your roadmap that only discusses items at the outcome level, which can better facilitate a discussion of priorities with your executive team. However, you might also create a more granular view of that same roadmap that discusses items at the epic level to help your development team more easily spot dependencies between those items and better formulate a plan of how to make your roadmap a reality.
Whatever views you create, if you want to use your roadmap to drive the most productive discussions possible, then you must tailor the views of your roadmap to meet your audience where they are.
5. Make the most of your agile product roadmap.
While your first attempts to introduce a product roadmap in an agile environment might meet some resistance initially, there are some steps that you can take to ease this introduction.
Manage a level of detail
First, remember that roadmaps should have a rolling level of detail, with the most detail appearing in the next 2 to 3 months and progressively less detail as you move further out on the horizon. This progressive level of detail better communicates how your level of uncertainty increases as you attempt to plan further out into the future.
Avoid dates
Next, you should avoid committing to specific delivery dates for the items on your agile product roadmap, especially as you move further out towards the horizon. While communicating specific delivery dates is often necessary as you near the launch of a particular feature, especially one that requires advanced coordination with your marketing team, you should avoid committing to these dates as long as possible. Doing so will help you avoid setting unrealistic expectations both inside and especially outside of your organization.
As a general rule thumb, features expected to be delivered in the next 30 days should be communicating at the date level, while communicating features likely to be delivered in the next 90 days is at the month level. Features not likely to be delivered in the next 90 days should be communicated at the quarter level, if at all, and even then with a healthy amount of caution that your team’s priorities and delivery timelines are likely to change before reaching those features.
6. Focus on outcomes over features.
And finally, and likely most importantly, remember that your agile product roadmap should speak in outcomes, not features. Outcomes are specific changes in either your organization’s or your customers’ lives that you wish to achieve with your product. Features are merely the means of making those changes, and there may be multiple ways to accomplish that change.
For example, imagine that your organization notices that a significant portion of your newest users tends to abandon your product within 30 days after their first login. Since this trend doesn’t bode well for your product’s future, your organization wishes to increase the percentage of users who you retained beyond the first 30 days in an attempt to grow your overall active user base. This desire to increase retention is the outcome you wish to achieve.
However, there may be many ways to achieve this outcome. For example, you could introduce an in-app user onboarding feature that walks new users through the most compelling features of your product, so they better understand how to get the most out of your product’s capabilities. Or, you could introduce an automated remarketing feature that attempts to re-engage lapsed users outside of your product, such as by an email campaign, in an attempt to bring them back into your product. Finally, you could even implement an in-app messaging system that enables your users to instantly connect with your customer support team at any moment that they feel confused or unsure of how to proceed.
Any of these approaches might be successful at increasing new user retention. But which method will work best for your users? The right answer might only present itself after engaging with your users and better understanding their reasons for abandonment. But choosing one specific feature and placing it on your roadmap months ahead of its delivery is likely to commit you to the wrong path prematurely. Instead, frame your product roadmap in the outcomes that you wish to achieve. That framework will give you the flexibility to choose the right features that best enable those outcomes, at the right time.
A Happy Coexistence for Your Agile Product Roadmap
At first glance, the idea of a product roadmap may seem antithetical to an agile approach. However, a product roadmap can not only coexist with an agile approach, but it can enable that approach.
Remember that a hallmark of agility is the ability to define clear goals and then continuously inspect and adapt in an attempt to find the most effective way to realize those goals. A well-crafted product roadmap clearly conveys the outcomes your organization wishes to achieve. It communicates a clear strategy and will be instrumental in helping your team deliver product experiences that keep your users coming back time and time again.
Ready to build your own agile roadmap?
