Getting Started with Product Delivery

Product Roadmap (Part 3 of 10)

“Everyone Has a Plan Until They Get Punched in the Mouth” — Mike Tyson

Vincent Carter

Published in

Straight Scrum

6 min readJun 30, 2021

Once you have a Product Vision and a Product Strategy, the next step is to create a Product Roadmap… or is it? A Product Roadmap is a high-level visual “plan” that communicates a strategy for how the goals of the product will be achieved over time in order to move the product towards its vision. Some of the benefits of having a roadmap are that it facilitates stakeholder collaboration, it provides the team with direction on how the strategy will be executed, it helps with securing funding, it provides the team and management insight into the skills that may be needed for future development, and it can make it easier for the team to coordinate dependencies with other areas.

The issue with a Product Roadmap is that it can communicate a commitment and the idea that we have some kind of certainty of the future. One of the biggest reasons for adopting an iterative agile development framework such as Scrum is because with knowledge work there is uncertainty. That uncertainty creates an environment of complexity where you are not able to determine what will cause a particular result, therefore making the future hard to predict. Scrum attempts to handle this complexity by using an empirical approach of sensing and responding, which is the foundation of what Scrum is built on. Because of this complexity and uncertainty, there are agilist that insist you should not use or create a roadmap.

Drinking from the Firehose of Empiricism

Not everything you face in software development is going to be complex. Some of it is just complicated which usually can be addressed using an existing process. Not all knowledge work requires an empirical approach and just because some parts of Product Development dip into the pool of complexity, it doesn't mean we have to drink from the firehose of empiricism on everything. We wouldn't have an electric car like a Tesla if we didn't already know how to build a car and how to build a computer. Yes, there are still a lot of things about building an electric car that are complex, but a lot of the stuff that is required has already been worked out.

Here’s another thing to take into account. If your organization provides product funding on a quarterly basis, then maybe you can get away with not having a roadmap. Every quarter, you meet with finance, share your expenses, discuss what value your product has created, and if they like the results, they will continue to provide your product with funding for another quarter. However, from my experience, organizations that are in the midst of switching from project-delivery to product-delivery haven't yet figured out how to make the switch with their funding model. Most organizations start off by funding products on a yearly basis and you are still required to provide some kind of 3 to 5 year plan (aka a Product Roadmap).

Steps to Take

Regardless of your funding model or development framework, the pluses of creating and maintaining a Product Roadmap far outweigh the negative of possibly communicating a commitment. The following are some steps you can take to help with this:

Consider giving the Product Roadmap a different name. Call it a Product Options Portfolio, Product Opportunities Overview, or Product Outcome-Based Roadmap. Giving it a new name will help convey that it is something different from a traditional roadmap and that it is not a commitment.
This is a great place to embrace one of the latest additions to the Scrum Guide which is the Product Goal. Whereas the Product Vision describes the purpose of your product and the reason your product is being created, think of a Product Goal as an opportunity that provides the intermediary step that gets you closer to your Product Vision. Make your roadmap a series of rolling Product Goals that show what you currently believe to be the intermediary steps needed in order to meet your Product Vision.
Make sure that everyone you share your roadmap with also understands that it is not a commitment by stating a level of confidence with percentage. “I am 80% confident that we can build an affordable, high volume electric car.” Be upfront about your uncertainty on the overall roadmap and the individual steps. When you provide a roadmap with a percentage of certainty it shows your beliefs as a level of confidence, not as a commitment.
The Scrum Guide describes the Sprint Backlog as being made up of 3 things: the why (the Sprint Goal), the what (Product Backlog items selected for the Sprint), and the how (the plan for delivering the Increment). However, it only describes the Product Backlog as containing 2 things: the why (The Product Goal) and the what (the items in the Product Backlog that fulfill the Product Goal). I say, add a 3rd element to your Product Backlog with the “how”. Consider the Product Roadmap as an extension to your existing Product Backlog that describes the “how”.
But what about dates? I get it. Several agilist will tell you to not put dates in your Product Roadmap and if you can get away without adding dates then definitely don’t add them. However, for a lot of people, it would be a career-limiting move in their organization to not provide dates and good luck securing the funding. In this case, where you are required to provide dates, make the scope of your roadmap opportunities as broad as possible.

Templates

There are some good Product Roadmap templates that are available for free on the Internet. The goal-oriented roadmap from Roman Pichler called GO Product Roadmap is one that I like and use quite a bit. My one recommendation is to add another row to it that includes a percentage confidence level as discussed earlier.

Conclusion

There are some good arguments out there for avoiding the creation of a Product Roadmap. Most of them seem to be about avoiding the habit of falling back into our old command-and-control practices and forcing employees to make commitments at a time when they know the least about what they are delivering. This is not only a transition for you and your product but also for your organization and you will need to work with your stakeholders and management to gain their support and trust. It will take time. Start by providing a roadmap that contains a confidence factor. Also, revisit and update your roadmap on a regular basis with your team and stakeholders so everyone knows that the Product Roadmap is a living and breathing artifact.