Earlier this week I spent some time helping a group of product owners get a better handle on what product ownership is, especially how it relates to their organization. One question I received during our discussion was “What must a PO include on their product roadmap?”
Since I had just updated the product roadmap for the Agile Alliance website, it seemed like a good time to dive into the topic of roadmaps.
What Is a Product Roadmap, Anyway?
It’s extremely important to understand what someone means when they say “product roadmap”. It turns out that the person who asked me the question was looking for some way to convey the expected timeframe of specific deliveries for projects she does for clients. In other words, a roadmap as SAFe describes it.
Most product people would say that’s not really a product roadmap, or at least not a very good one. They’d say that primarily because it doesn’t take uncertainty into account. Yes, the SAFe version of a roadmap indicates a “commitment” and a “forecast”. It also shows dates and specific features so it implies more certainty than is probably realistic. That said, stakeholders outside of the team like this type of roadmap because it tells them when things will be delivered… until things aren’t delivered on those dates.
A better way to think of a product roadmap is as a statement of intent for how you are going to implement your strategy. The product roadmap is a living thing that indicates your best understanding at the point that you last updated and it also reflects whatever uncertainty you faced when you last put it together.
What Should be Included on a Product Roadmap?
So with that in mind, the things you should include on the product roadmap are:
Different time horizons that reflect increasing uncertainty. Instead of dates, I use Now, Next, Later, and Never.
- Now are the outcomes you know you’re working to deliver now or will start working on soon.
- Next reflects the outcomes you think you’ll work on in the foreseeable future, with the understanding that things could change.
- Later reflects the outcomes you might tackle some time. Those are the most likely to change as time proceeds.
- Never reflects the outcomes you aren’t going to tackle. Sometimes it’s good to explicitly state what you just aren’t going to do.
Don’t put dates down because when you update the roadmap. You don’t know specifically when things are going to get done. If there are specific real time constraints driving the need to work on a specific outcome, you may want to note that.
Outcomes rather than outputs. Describe the needs you want to satisfy rather than the solution you’re going to use to satisfy that need. For the items in Now you probably have a solution in mind, but there’s no guarantee that will be the ultimate solution you use. Using this approach you’re properly setting expectations that you’re going to solve a specific problem – you just don’t know exactly how.
I will admit, it’s tough to do this all the time and I find myself occasionally listing a specific feature the team is going to deliver or an action I’m going to take. It’s probably ok once in awhile in the Now column, but not a good idea in Next or Future.
Ties back to Strategy. Depending on what you’re working on, this could be your organization’s strategy or it could be your product strategy. In the case of the Agile Alliance, I organize the outcomes listed in each Horizon under the “Value Dial” that outcome impacts. You can think of the value dials as the way that the Agile Alliance describes its strategy in order to make decisions about what to do and what not to do.
How To Make the Roadmap A Living Thing
You’ll want to revisit your product roadmap on a regular basis and update it to reflect the things you’ve done, the things you’ve learned and the changes in your organization and environment. This helps to keep the roadmap fresh and useful.
I revise the product roadmap for the Agile Alliance website about every 3 months as a means of providing an update to the Board of Directors. I find that’s a good cycle to revisit what we’ve done and adjust our thoughts about what things are coming up next.
My thoughts on product roadmaps are influenced by my experience and what other people have shared. Below are some of the resources I find helpful to get a better understanding of product roadmaps.
Product Roadmaps tell you why you’re building something
Product Roadmaps focus you on the best outcome for your customer
Rethinking the Product Backlog. Twice.
Melissa Perri has done a lot of thinking about product backlogs and has refined her thoughts with things she’s learned by doing them along the way. The crux of her thought is that product roadmaps should focus on problems to be solved and that you can do this for products in both discovery and delivery.
A Bit Longer Reading on Product Roadmaps
Here are some longer pieces on the topic of product roadmaps you may find useful:
- Product Roadmaps: Your Guide to Planning and Selling Your Strategy from ProductPlan
- Get Your Priorities Straight!: The Product Manager’s Guide to Smart Product Roadmap Prioritization from UserVoice (You’ll have to give them your email address)
- The Fall 2016 Issue of the Pragmatic Marketer Magazine on Product Roadmaps from Pragmatic Marketing