Over the last few years, I’ve noticed how people can cling on to product roadmaps. Some people seem to derive the same sense of certainty and predictability from a roadmap which they used to get from a Gantt Chart. One could argue that a detailed roadmap is a remnant of the traditional Waterfall approach to product management, an approach which favours detailed documentation upfront.
As a result, a lot of roadmaps tend to be very detailed; filled with specific features and timings, with product managers getting hung out to dry if they fail to deliver on features promised in their roadmaps. The hard everyday reality is that both business environments and product development are too unpredictable and volatile to be able to plan an entire roadmap upfront. This is one of the reasons why great product people like Marty Cagan and Brad Murphy argue that OKRs are a viable alternative to (traditional) roadmaps. Instead of focusing on outputs, product teams should be given the autonomy to focus on critical business outcomes instead.
Product Roadmaps Relaunched, a book published in 2017 by C. Todd Lombardo, Bruce McCarthy, Evan Ryan and Michael Connors, aims to achieve a bit of a reset of flawed perceptions of what a roadmap is and isn’t. Lombardo et al. start “Product Roadmaps Relaunched” with the following statement:
“A good roadmap is not so much a project plan as a strategic communication tool, a statement of intent and direction.”
And the authors subsequently set out requirements for Roadmap Relaunch — A product roadmap should:
- Put the organisation’s plans in a strategic context
- Focus on delivering value to customers and the organisation
- Embrace learning as part of a successful product development process
- Rally the organisation a single set of priorities
- Get customers excited about the product’s direction
A product roadmap should not:
- Make promises product teams aren’t confident they will deliver on
- Require a wasteful process of up-front design and estimation
- Be conflated with a project plan or a release plan
I found it very refreshing seeing a roadmap as a two-way communication device, steering your company to delivering on a company strategy to achieve an overarching vision.
In the book, the authors distinguish between primary and secondary components of the roadmap. The primary components are necessary for an effective roadmap (see also Fig. 1 below):
- Product vision — This is the overarching vision that guides the product roadmap.
- Business objectives — Having well defined goals on the roadmap, will help you and your organisation to measure progress.
- Broad timeframes — Broad timeframes like calendar quarters or Now, Next and Later offer guidance about timings without committing to very specific deadlines.
- Themes — I like the authors’ suggestion to ask the question “What would need to be true for our product to realise its vision and attain its business activities?” Themes can be defined as customer needs or problems for the product to address.
- Disclaimer—Roadmaps can have a caveat just to make it very clear to any stakeholders, other team, etc. that anything in the roadmap is subject to change and evolve.
Secondary components:
- Features — Personally, I’m not a big fan of having lots of features on a roadmap, mostly because it will limit you and your team to come up with solutions, with people expecting whatever is on the roadmap to get delivered. The book explains that “features and solutions are the specific deliverables that will fulfil the needs and solve the problems identified in the roadmap themes.
- Stage of development — By including labels such as “discovery”, “design”, or “prototyping” on a roadmap, stakeholders and other people not close to day-to-day product development — should be able to see at a glance where the product is at.
- Confidence — Indicating the level of confidence you have in your availability to address each item or theme on the roadmap in the next release is a great way to help offset the sentiment that once it’s on paper, it’s a promise.
- Target customers — Highlighting which customer segment(s) your product is looking to address, really helps with the ‘communication’ aspect of your product roadmap. Instead of just seeing a bunch, you can now tell more of a story about upcoming themes and impact on specific customers.
- Product areas — A large and complex product — or a new product where basic functionality is still being laid down in many areas — many benefit from a roadmap where themes or features are annotated per specific area of the product.
Fig. 1 — A roadmap helps manage outcomes, underpinned by primary components — Taken from: “Product Roadmaps Relaunched”, p. 25
It’s worth highlighting the book’s chapter on ‘Themes’, which I’ve written about previously. Themes are described as “an organisational construct for defining what’s important to your customers at the present time.”
The difference between themes and subthemes is granularity, or level of detail:
Theme: a high level customer need; “content access across devices” for example
Subtheme: a more specific need; “visibility of which device is in use” for example
One can link specific features to these themes and subthemes on the roadmap, but it’s worth considering first whether features should be added to the roadmap in the first place. The book contains a number of useful questions to consider in this respect:
- Do we have enough understanding of the need and possible solutions to feel confident in a particular solution?
- Do we have any validated solutions from previous release plans that did not get completed and need to be carried over?
- Do we have any validated infrastructure needs?
- Do we have any mandates from decision-making stakeholders that must be addressed?
- What is the likelihood that this solution will be changed, postponed, or dropped from the schedule (i.e. what is your confidence)?
In the light of the roadmap acting as a two-way communication tool, the authors make some valuable point about the different stakeholders, and how they benefit from and contribute to roadmaps. For example:
Customers — benefit: Get excited about how they will benefit in the future
Customers — contribute: Provide feedback on value and priorities
Executives — benefit: Understand how resources are being used and potential ROI
Executives — contribute: Provide strategic context for product direction and priorities
These stakeholders are likely to work with what the authors call the “Product Core”. This is a small group consisting of those who work directly on the product: product manager or product owner, designers, and engineers. The book introduces the “Shuttle Diplomacy Canvas”, as a practical way to plan and conducting “shuttle diplomacy”, tracking stakeholder meetings and moving one toward to final roadmap buy-in and alignment.
Main learning point: I’d highly recommend Product Roadmaps Relaunched to anyone keen to learn more about how to best communicate product vision, business objectives and associated themes. Lombardo, McCarthy, Ryan and Connors offer some useful insights and practical pointers if you’re looking to relaunch your product roadmap!
