Product owners and product managers use roadmaps to communicate the future direction of the product. The focus is typically on new features and functionality, but it isn’t necessarily restricted to these items.
Whereas a typical product roadmap might show expected release dates for these enhancements, in agile, the notion of sticking to deadlines becomes counterintuitive.
Agile development requires an ability to respond to change and address evolving needs at any particular moment. Agile teams also spend less time estimating and forecasting how long something will take and put that time back into experimenting and actually building the product.
As a result, we expect things to change in agile and dates quickly become wishful thinking or empty promises.
Another core principle of agile is fixed capacity. We achieve this by creating stable, long-lived, cross-functional teams. In doing so, we fix our capacity, meaning that scope and/or time are the dimensions that shift. Therefore, it is not possible to pin features to dates in agile.
When we do want to fix dates in agile, scope remains flexible. Both scope and time cannot be fixed in agile.
An agile roadmap, therefore, removes the notion of product deadlines. They still maintain the concept of time (i.e., feature A will come before feature B), but nothing is tied to a specific date.
To understand what makes a roadmap agile, we first need to underscore a couple of core principles of agile teams .
First, as mentioned, agile teams seek to respond to change. Rather than fixing scope and/or a time, we fix capacity in agile.
From there, scope and/or time must be flexible. This is because, in agile, we value our ability to respond to change over deliver a planned scope of work within a specific timeframe.
The second core concept to agile is focusing on value — more specifically, outcomes over output. Agile teams understand that delivering a new feature or product doesn’t mean that people will automatically use it, pay for it, and derive value from it — and, at any rate, these things do not necessarily translate to better business outcomes (i.e., revenue, customer advocacy, retention, etc).
Therefore, in agile product development, simply delivering something on time is not a core measure of success. There is risk associated with spending too much time and money delivering things that do not impact the customers or business.
Agile roadmaps strip timelines away. More advanced agile roadmaps also focus on outcomes over fitting a list of features or tasks into time-bound releases.
Let’s take a detailed look at two of the most popular agile product roadmapping frameworks:
The most common agile roadmap model is known as the Now-Next-Later roadmap:
Grouping items into categories of Now, Next, and Later allow for flexibility. Things in the Next and Later columns can frequently change without impacting expectations around precisely when something will be delivered. This makes changing and adapting your roadmap easy.
The Now-Next-Later also still provides a notion of time while not allowing the work to become subservient to time. We know that things in the Now bucket will be coming soon, things in Next will come after those in Now, and those in the Later” group will arrive at some stage in the future. This allows for enough information to help set expectations without compromising flexibility.
As mentioned, more advanced agile roadmaps will communicate the outcome that the team is currently working toward. They may also indicate possible future outcomes.
If moving to zero timelines is too much of a leap for you and your company, a happy middle ground that many agile teams employ is bucketing work into quarters.
Similar to Now-Next-Later, using quarters provides flexibility as far as exactly when within that quarter something will be delivered. A downside to using this model is that, when something moves beyond the quarter, it may be interpreted as falling short of expectations.
An agile roadmap using quarters would look something like this:
Every agile roadmap will look different and depend on your product and company’s unique needs and vision, but the steps outlined below are a good starting point for creating your own agile roadmap:
The first step to any form of product roadmapping is to ensure that you have a clear vision for the product. Your product vision should inform what goes onto the roadmap.
Strategy is a set of choices. In this case, you will need to make a set of choices on how you intend to realize your product vision. These will be choices on what markets you intent to focus on first, what customer problems you aim to address, what principles you want your product to display, what brand traits you want it to have, your positioning in the market, etc.
A product strategy isn’t set in stone, but these choices are key to informing your roadmap.
The final question in your strategy process should be, “How do I know whether I’m succeeding?”
To answer this question, you will need to develop a set of goals. These should be in the form of outcomes with clear measures that you intend to use to know whether you are achieving that outcome or not.
Product metrics are also particularly important because they help to indicate whether we’re heading in the right direction. For example, you may want to see more monthly active users (MAU), greater retention, or even more bespoke metrics, such as the percentage of new customers who transfer from a specific competitor.
Once you have your vision, strategy, and goals/outcomes, it’s time to translate all those into the actual work. From here, you will need to break these down into epics, opportunities, user stories, etc.
Using your strategy and chosen goal, you should be able to immediately begin to prioritize and lay out the work along the Now-Next-Later timeline.
It goes without saying that once you have your roadmap, you need to communicate and validate it. Ensure that your team and stakeholders are across your roadmap.
This should be a continuous process. As you learn more and things change, ensure that you are regularly reviewing your roadmap, making necessary adjustments, and then communicating those changes out.
Agile roadmaps are best suited for product development and agile teams that need to respond to change frequently.
Agile roadmaps are adopted by product teams all over the world. Some great example of public agile roadmaps include the following.
ProdPad is a been pioneer of the agile roadmap. Its public product roadmap uses the Now-Next-Later format.
Slack’s agile product roadmap is a variation on the Now-Next-Later format. It groups items into buckets labeled Near Term, Mid Term, Long Term, and Released.
Loom’s roadmpas also use a variation on the Now-Next-Later agile roadmap model, with three buckets labeled Coming Soon, Under Construction, and Launched.
Buffer also uses an agile roadmap. Its model groups items into categories labeled Exploring, In progress, Done and Leaving It For Now.
Unlike the roadmaps described above, Github’s agile roadmap is organized into quarters.
Although not in a kanban format, Atlassian uses both statuses similar to Now-Next-Later and quarters for their roadmap.
Features are marked as Future, Coming Soon, and Released. They also have a corresponding date, which gets more precise as they get closer to release.
For example, Future items are marked with an indicative year, whereas Coming Soon items are marked with an approximate quarter.
You may be thinking, “This would never work in my organization.” But, as counterintuitive as it may seem, agile roadmapping can be a breath of fresh air.
When we have features meticulously plotted along a timeline, how often do we actually meet those dates? Agile roadmaps seek to embrace the reality that we seldom meet the timelines we set in the first place. The truth is, building products is inherently uncertain, and things change.
Moreover, we must adapt to market and user changes to remain competitive. When we have feature tied to dates, we often find ourselves spending hours each week making constant updates to the roadmap as things shift. We then spend countless hours updating stakeholders and customers.
All that time is taken away from more important things, such as understanding our customers, formulating a product strategy, and actually building the product.
Would you rather spend your time obsessing over dates on a roadmap or working hard to deliver value to your customers? I know which I would choose.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Tyler Stone, Associate Director, Product at Sensor Tower, talks through how he’s led Sensor Tower through a complete product redesign.
AI agrees too easily. That’s a problem. Learn how to prompt it to challenge your thinking and improve your product decisions.
Chrissie Lamond, VP of Product at Mansueto Ventures, talks about how she builds product experiences across audience segments.
AI governance is now a product feature. Learn how to embed trust, transparency, and compliance into your build cycles.
Learn more →
