Roadmaps aren't just for Products

What's on your product roadmap? It's a common question to those of us working in software development and one that we're probably happy to answer, or at least find someone who can. I was speaking with a developer just last week for a potential supplier who was excitedly describing the new capabilities they had 'on the roadmap'. Despite my natural cynicism that comes from years of software testing, I'll confess that I do like roadmaps. The beauty in concurrently providing a vision of the future and the stages to get there whilst avoiding committing to unnecessary detail or deadlines - makes them far too useful to be restricted just to defining product feature sets.

What's in a good roadmap?

The use of product roadmaps to present our visions of the future is ubiquitous enough that there are entire books devoted to the subject. My favourite, is "Product Roadmaps relaunched" by Todd Lombardo which uses some excellent examples to show different ways of putting a roadmap together. As with any useful technique there are products designed specifically for the purpose, yet many find as much value from a simple Trello board or even a well structured PowerPoint. The format is far less important than what is being communicated, which boils down to some very simple messages

• Here is our vision of what we want to achieve in the future
• Some things we'll do soon and are in more detail
• Some things are further off, are in less detail and are less likely to be done

This is a nice example from the Aha! site

I like the fact that it identifies clear stages of progress without unnecessary or impractical levels of commitment to timescales. What I really like is how powerfully a roadmap can bridge the communication divide and motivate the people responsible for delivering. It establishes expectation and vision but doesn't take the recognition for successful delivery and place it in the hands of a manager. The work has been identified but it's up to the team to set the pace and deliver the value.

What's not?

It's not about fixing dates. I personally avoid any tools that represent the roadmap in the form of a Gannt Chart or timeline like this:

For me, this isn't a roadmap it's a project plan which has a very different perspective. For agile teams that respond to change, and are likely to encounter a lot of emergent need, baking expectation into a string of deadlines that they're unlikely to meet through no fault of their own is hardly inspiring. With a roadmap you're always moving forward. Conversely once a deadline on a Gannt Chart starts slipping then in my experience motivation tends to slip with it.

It's not just about adding value

In the field of software development Roadmaps are most commonly associated with the future feature set of a product. Software development teams aren't just responsible for adding features though. As I discussed in my post on different perspectives on value, successful teams need to have a balance of three facets of value

• Identification of new value through new features
• Delivery of value through maintaining pace of development
• Protection of value through effective testing and identification risk

The traditional product roadmap revolves around the first column responsibilities here, yet to provide a true reflection of the responsibilities of a software company or team, all three elements here need to be included in their roadmap.

• Improvements to architecture, infrastructure and tooling are needed to prevent the delivery of new value from slowing down as the capabilities of a product grow. It's a frustrating situation to be in where a solid roadmap of features has been identified, yet the ability to add new capabilities to the system has slowed so much that the new feature roadmap has to be severely curtailed.
• A roadmap covering value protection, including testability improvements and test tooling/automation also needs to be considered. It may be that with a thin set of features and a small customer base a team can get away with very lightweight testing. As responsibilities and dependencies grow this is unlikely to persist and again the new feature roadmap will suffer drastically if a product starts to haemorrhage existing value through bugs and regressions.

Rather than being purely a responsibility of the product manager or product owner, I'd prefer to view the product roadmap as the representation of a collective responsibility in a development group to support healthy addition of value at a realistic sustainable velocity.

Roadmaps aren't just for software development

Despite their most popular guise, roadmaps don't have to relate to software development at all. I've also found them to be really powerful as a means to communicate and drive improvements in supporting teams or services. When building a support function years ago I worked with the team to create a roadmap of service improvement. Delivering the roadmap involved working from the introduction of an email parsing ticketing system to manage support through emails through to introducing a customer web based portal with on-line knowledge base and self-help.

I could have managed this through traditional project management tools and tasks, but that would have been a far more negative, command and control experience for the team. Establishing a roadmap together as a team shifted the perspective from an obligation on the team to deliver, to a vision of how they were going to improve their value to the business in the future that they could proudly present to senior management - a far more motivating and aspirational experience.

It's not the case either that roadmaps have to come 'top down'. For a team who are struggling to get buy in for improvements to the way that they work from management, a roadmap can be a powerful communication aid to support their desire to change. A team presenting their own vision of the future and how they can incrementally improve their ability to deliver value is much harder to reject than a team simply demanding large scale changes.

Vision and ownership

At the same time as defining a future of work, roadmaps also subtly define the relationship between a team or company, and that work. Created in the right way they can shift the perception of the future from something that is demanded of a team, to encapsulating a vision that they are bought into, and proud to deliver. This relationship provides a great reference point when discussing personal development, as you can communicate not just in terms of the current needs of the team but also in terms of how an individual sees themselves contributing to that future that the roadmap defines.

Sometimes something as simple as how work is presented can make the difference between individuals being inspired and motivated to deliver and feeling threatened and worried about failing. Having an outcome based roadmap allows you to motivate a team in improving value to the company while maintaining some flexibility and autonomy in how to achieve that.

References

• The example roadmap images in this post are from this handy collection of excel templates from the Aha! website https://www.aha.io/roadmapping/guide/templates/gantt-charts
• I recommend the following book as an excellent reference for what a good roadmap looks like "Product Roadmaps relaunched" by Todd Lombardo

This article was originally posted on https://a-sisyphean-task.com - please visit for more articles on Product, Agile and Testing Leadership