Principles of an Agila Product Roadmap
Sally, the Technical Lead at Software Company ABC wants to know why her Product Manager insists on using a product roadmap;
“We’re an agile team right? It seems un-agile to set concrete dates on an out-dated document for stuff that we should (but probably won’t) get done.”
Ahhhhhh, yes. A common question in agile software development.
To first understand why every agile software development team needs a product roadmap (and yes, you all need one), we must first pull apart Sally’s question and see why she asked the question in the first place.
“We’re an agile team right?”
Now there are a few things wrong with this question.
The first is Sally’s assumption that a product roadmap is not an agile tool, rather an exhausted practice dragged across from Waterfall predecessors (*cough* Gantt Chart *cough*).
It’s a common misconception, and something that we’ve covered before in this blog post, but no, roadmaps are not the same as Gantt Charts.
In short, Gantt Charts assume that work will be completed in a linear fashion and are for task dependency and critical path management. Michael Dubakov contextualises it perfectly when he said;
“Agile is not about task dependency and critical path management — it’s about . flexibility and temporary dependency.”
Enough about Gantt Charts, let’s get back to Sally’s question.
“It seems un-agile to set concrete dates on an out-dated document for stuff that we should (but probably won’t) get done.”
I agree with Sally on this one. It is un-agile to set concrete dates on a document that is not kept up to date.
Here lies the problem. Sally is under the impression that the product roadmap is a time-bound, fixed promise for deliverables.
Now we know that if the environment you are operating in is agile, change is inevitable. Customer needs and requirements change on an ongoing basis, and your roadmap should reflect how you intend to provide value to your customers.This means your roadmap should be regularly reviewed and adjusted to accurately reflect that.
Product Manager’s need to educate their stakeholders that the product roadmap is not a promise. It is a living-document meant to serve as a guide and is subject to change. The roadmap represents the activities a team is looking to deliver on, based on providing the most value to their customers in that snapshot of time. We just discussed that these needs are almost always going to change through time, and the roadmap should be updated to reflect this.
This means communication between all stakeholders is extremely important. So how do we ensure that communicating these changes in deliverables is streamlined across all stakeholders? A product roadmap — who would have thought!
Guiding Principles to ensure your agile team gets the most out of your product roadmap
- Focus on Themes of Work not Features
In their simplest form, themes represent high-level groups of work (like epics). In an agile product roadmap, these themes should be customer-focused unlike traditional waterfall roadmaps where themes tend to be focused on business objectives.
Examples of themes include:
- Customer On-Boarding Experience
- Reducing Tech Debt
- Customer Satisfaction and Engagement
By grouping work into themes, teams are able to tell a story about where they are headed, and the goals, objectives and outcomes that will get them there. This high level visualisation allows teams to easily answer the following questions:
- What are we doing?
- Why are we doing it?
- How does this link back to our OKRs?
- Think of the Roadmap as a ‘Living Document’
As I mentioned before, Product Manager’s need to educate their stakeholders that the product roadmap is not a promise. It is a living-document meant to serve as a guide and is subject to change.
It is important to educate all stakeholders that the roadmap represents chunks of work valued most by customers over a certain period of time. It is inevitable that those customer preferences will change over time, and the roadmap should be altered/amended to reflect that.
- Actively Collaborate with Stakeholders when Setting/Reviewing the Roadmap
It is unrealistic to think that as the Product Manager, only you can represent the customer voice.
By engaging the perspective of developers, sales reps, customer support and engineers in the process, a holistic view of the customer experience is understood, thus a more realistic basis for determining what we should do and when, because we know our customers value this.
- The Roadmap Needs to be Somewhere Accessible to all Stakeholders
The product roadmap should be the team’s single source of truth, representing the plan of execution against the companies OKRs.
Visibility into ‘what is going on’ and more importantly ‘why am I doing what I’m doing’ is crucial in establishing transparency and confidence in your team.
The roadmap represents the overall vision for the team for a period of time, and ensuring the roadmap is accessible to all stakeholders is a way of achieving organisational alignment.