The roadmap is possibly the most common product document and simultaneously the least standardised. Too frequently, the roadmap is an instrument of destruction preventing empowered teams and killing innovation.
In this article, I want to share how to position the roadmap to do good and support autonomous teams building high-performance products.
- The roadmap is a prototype of the product strategy (a plan). Reading the roadmap should share in pragmatic terms the strategy.
- All plans are a list of the current next best actions. This is key, it means as we progress on the journey the plan can and should change. The probability that we got it right when we forecast what we should do in 9 months' time or 18 months' time is not high.
- The roadmap is not a commitment to build specific features. If we know the exact solution to build to deliver the value we don’t have much need for product management.
- The best way to avoid this feature trap is not to include features on the roadmap. The roadmap should have themes that might be problems to solve or outcomes to achieve.
- A release plan is a different document from the roadmap. A release plan is a promise of delivery, with expected dates and feature level details of the solution. The release plan only looks forwards to where we have concrete solutions, typically not beyond 3 months, in some teams, due to the level of uncertainty the release plan might only be the next few weeks.
- In general, the roadmap is not helped by including dates. This leads to promises being made that no one knows if they can be kept. However, this does not mean we have an unlimited budget and all the time in the world to deliver, the governance process can manage this as opposed to the roadmap blinding attempting to predict it.
- A great product roadmap is easy to align to the business strategy, it illustrates how product development will execute the business goals.
As product leaders, the roadmap is a powerful tool to communicate product strategy and manage high-level discovery and prioritization. As a tool, it is the catalyst for meaningful conversations and debate to funnel into your product governance process.
One of the Momentum program members recently transformed their feature roadmap into a theme-based roadmap. They used this to great effect to change the topic of conversation with senior leadership. The conversation moved from solutionising at the c-suite, to debating the value of outcomes and the impact of sequencing outcomes. The result was staggering, a huge realisation of driving active users up before broadening the product capabilities was going to deliver far bigger commercial wins, and faster. The product leader is now leading the conversation instead of being dictated to by sales or customer success.