I believe the roadmaps for products developed using Agile methodology need to be composed and communicated slightly differently compared to those for traditionally developed products. This difference, however subtle, will without doubt be appreciated upon a closer look by everyone involved. The roadmap discussion approach discussed below will help build more trusting, collaborative relationships with your customers (or vendors if you are a customer).
Traditionally customers are using product roadmaps as means to manage uncertainty of investing in complex solutions. As a customer, whether you are talking to a plumber or a supplier of data center infrastructure or backup software, you want to know your costs and benefits as much as possible in advance, to help you optimize your investment decision. If you are a vendor on the other hand, you would want to understand and minimize your own risks and manage your customers' expectations accordingly.
For example, a plumber quoting a bathroom remodeling project may give you a minimum base quote, including estimated project duration and cost. An experienced plumber will also inform you about additional costs and time that may be needed if after opening the wall he discovers a rusted pipeline that needs to be replaced. In this case, the quote acts as a simple roadmap driving your purchasing decision.
Enterprise software development is significantly more complex than plumbing. The more complex a product or a service, the more challenging it is to capture, interpret and communicate consistently forward looking information (uncertainty) for the purposes of risk and expectations management for all involved parties.
In the world of traditional waterfall software development product releases are planned well in advance, and product managers tend to produce elaborate roadmaps loaded with details about releases well into the future, 2-3 years time horizon is not uncommon. These roadmaps rarely highlight the distinction between the levels of commitment to deliver features in the near and long term. For years, everyone involved in putting these roadmaps together, delivering them and listening to the presentations learned to be skeptical about the content, and yet we all still crave for these roadmaps.
With the adoption of Agile software development we find ways to take advantage of shorter release cycles, to benefit from the validated knowledge such as evolving customers' priorities and needs. As we adjust how we plan new releases in this setting we have an opportunity to make our roadmaps more relevant and insightful. Here are three easy to remember steps:
- The product vision needs to be kept up to date and shared with the customers. This will communicate your strategic intent and help customers understand and even predict future potential prioritization choices your product team will make during regular backlog grooming.
- The roadmap needs to articulate clearly what is a part of the current in-flight release. This planned content constitutes higher level of commitment since one or more scrum teams have scoped and sized the work in front of them and signaled their intent to deliver this within available number of sprints.
- Beyond the content of the release already in development, everything else shown on the roadmap is essentially a part of the product backlog prioritized in line with the product vision. You can refer to this as the content under consideration.
As a final thought, engaging your customers in close collaboration around ongoing product development will go a long way in establishing their confidence in your ability to execute on your roadmap plans.
