Update: April 09, 2024
I wrote this article 4 years ago from a very practical point of view. While I believe that what I describe in the article is being lived in practice, in the meantime I have changed my opinion on whether it’s a major flaw or not to see backlogs and plans as roadmaps. Short answer: It is a major flaw.
I’m in the process or editing this article so that it reflects my today’s view on the topic better.
Soon to be updated…
Original: May 26, 2020
An Agile Coach approached me and asked me for reference documents or people to share with him. He wanted to gather some examples on agile roadmaps but it was difficult for him to find good examples of agile roadmaps. Most of the examples that he found were far from agile.
Here’s my answer:
“To be honest, I believe there’s nothing like an agile roadmap. There are attempts to make a roadmap as flexible as possible by trying to ditch timelines but if you ask me you can never fully remove the time aspect – even if you remove milestones.
Some starting points for you could be Roman Pichler’s approach on roadmaps (start here: https://www.romanpichler.com/blog/category/product-roadmap/), or Janna Bastow’s approach (start here: https://www.mindtheproduct.com/free-your-product-roadmap-and-ditch-the-timeline/) or Jeff Gothelf’s (https://medium.com/@jboogie/what-does-an-agile-product-roadmap-look-like-cf0dbe5be4ef), and look for c. todd lombardo (https://www.mindtheproduct.com/roadmaps-are-dead-long-live-roadmaps-by-c-todd-lombardo/). The links are really just starting points, when you google for them you’ll find more articles.
I believe, an agile roadmap needs to be flexible enough that you can adapt your strategy to the response that the market gives you to the increments that you release. However, the nature of a roadmap is that it guides you and your stakeholders through the future. That’s what your Sales and Marketing teams will rely on and work with, too. In order to do that, you need to have an idea of what the future will bring. What you can do is, you can set up so called ‘dual track agile’ processes. That means, you start with research & discovery to understand what you want to build next. While you’re delivering on what you’ve found out, you continue your discovery efforts and find the next things to build for your customers. And so on and so forth. This way, you can build up your near term roadmap with concrete topics/features, and keep your mid- and long-term roadmaps theme and hypothesis based. That’s the most flexible yet realistic thing that you can do that will also give your stakeholders guidance on the strategy. But it will still need to show some sort of horizon because the Sales and/or Marketing team, and investors as well if you have some, will ask for it.“
About timelines
I’m sure there are companies who work in a very special culture where it’s possible to work only with now-next-later roadmaps. However, I believe that the reality for most companies is that their setup requires to have some sort of a timeline in their roadmaps. Even if it’s not milestones with concrete dates, it’s some time horizon, for example quarters. Even “now, next, later” is some sort of a time horizon. If you’re working on a feature now, there will be a time estimation for that feature so that the company has an idea of when that feature will be ready. The advantage of “now, next, later” though for your product teams is that it gives you room for delays and helps your company to change the idea that fix milestones are the only way how to deliver features.
“Feature factory” supporting product roadmaps
I totally agree that we’re not flexible to respond to market reaction if we set up a roadmap that includes only features. Themes is really nice way to express important topics to work on without getting too deep into the solution level upfront. In practice I like to mix a couple of elements of different ideas out there on the field to communicate why the team will be working on what: The goal of the quarter, metrics to understand success, themes and features that we’ll work on, questions or hypotheses that we’re trying to answer or validate. And yes, in reality there are milestones, and they should be listed as well.
Roadmaps are fluid
They’re changing all the time. And this is good. They need to be flexible. There’s a constant negotiation between the roadmaps of the different levels.
Yes, there are different levels of roadmaps. The most abstract one is on the company level that demonstrates the strategy. Depending on if and how many product group layers you have, you’ll have product group roadmaps. For each product in the product group, you’ll have the product roadmap itself. And finally you have the product backlog, sprint backlog and release plan on the delivery side of roadmapping – yes, they’re kind of roadmaps, too.
The most solid is the strategic roadmap that guides the direction that your company is heading to. The most flexible are the sprint and product backlogs. The negotiations and adaption happen in every direction: vertical between the strategic, product group and product roadmap, as well as horizontal between product group roadmaps and product roadmaps. Even between the strategic roadmaps of different departments.
What’s the difference between Product Roadmap and Product Backlog?
The Product Backlog will be filled with stories for the items on the Product Roadmap. Here’s a simplification. And yeah, instead of quarters, you can really take any time horizon. Now, next, later works here, too. The emphasis is on the near term items.
So what makes a roadmap agile???
Simply put: It’s how people in the company treat the roadmap.
The only way to have a fully agile roadmap is a company culture where everybody understands that roadmaps – especially the ones below the company strategy level – can only reflect our guesses about the future. Roadmaps are nothing else but hypotheses that first need to be verified. A roadmap is not a promise that x, y, or z will for sure be done in 9 months from now. Again, it’s fluid. When your company, your colleagues understand that you can’t guarantee that your roadmap will look the same tomorrow, when they understand that your plans – and therefore the roadmap – must adapt to responses of the market, and don’t blame you for postponing or even ditching the feature that was planned earlier, then you have a 100% fully agile roadmap.
I like to visualize in my roadmaps that I can give guidance but no guarantee on the upcoming topics or features. I’m sharing here my preferred way of a practical product and product group roadmap that shows accuracy of prediction:
Depending on the clarity of the full year’s company strategy, you might have ideas for further quarters but they’re rather assumption or even only hypotheses from today’s point of view. Only the current quarter is the one that you can say for certain what you’re planning to work on. But be careful: Even in the current quarter you might want to decide against a planned feature or improvement as a reaction to market response. Therefore, this overview does not replace good and frequent communication with your stakeholders. It’s rather a supporting tool for your conversations. Therefore, I add a remark on the document – where ever I share it – that all of that, even the current “Certain” quarter is not guaranteed and that I will communicate changes with the stakeholders concerned.
Having the year’s hypotheses on a roadmap like this, I like to communicate the “now, next, later” way of planning for the current quarter instead of giving final dates when a feature will be ready. However, when in reality other departments need some sort of an estimation because they need to adapt their plans accordingly, then I like to give them a date that serves as orientation, not as a final date that we must meet no matter what. Internally – just for my own planning – I still like to use some sort of a gantt chart to see if we can really work on all those things in parallel, but I don’t like showing it to stakeholders to make sure that nobody accepts my thoughts and plannings as facts.
That’s my thoughts and my practices on roadmapping. What do you think? And what are your practices?
