101 Blunders to Avoid When Building a Product Roadmap
Product roadmap planning is perhaps the most demanding aspect of product management: it demands strategic thinking, being perpetually in command
To support product teams during these times we are offering 3 free months of Craft.io; Click here to learn more
24 Jun 2016
Product roadmap planning is perhaps the most demanding aspect of product management: it demands strategic thinking, being perpetually in command
Product roadmap planning is perhaps the most demanding aspect of product management: it demands strategic thinking, being perpetually in command of the big picture and above all – experience. Only in latter versions of your roadmap can one truly understand previous oversights.
There’s no shortcut through years of experience, or even months of acquaintance with a team and product. But there are certain mistakes, more common than others that can be avoided simply by sticking to your product strategy and remembering that the roadmap is, above all, a communication tool.
Words to live by: the roadmap is a living thing. In that, it reflects the agile product management process – priorities change, user needs shift, product strategy is slowly formed. It also reflects your team’s resources, stakeholders’ input and your growth rate.
When a roadmap reflects so many different needs that pull in different directions, it’s impossible for it to stay static. Or rather, if your roadmap is static – you’re doing it wrong.
I’ve met product managers who, in their desire to maintain control over the process and instill a sense of stability in the team – consciously made as few changes as possible in versions, sprints and priorities. This is a mistake. The only way to keep things under control is by adjusting your roadmap to new discoveries and insights.
That said, changing release dates for versions down the line every other week is, indeed, a recipe for disaster. The team will find it difficult to maintain structure and productivity under these conditions.
If you’re wondering what a mess looks like, take a look at a roadmap planned by a product manager who is having a hard time prioritizing. There’s a big chance it’ll show 12 releases in two months and then radio silence for the next 3 quarters.
Prioritizing can be a huge challenge for product teams. Balancing feature requests with product strategy and then calculating the team’s resources and other factors – that can be altogether confounding, as big decisions often are. However, feature prioritization is the only way to move forward, and that must be reflected properly in the roadmap.
Let’s settle this once and for all: the roadmap is a tool for communicating which direction you plan to take the product. It reflects the product strategy. Assuming you have a solid product strategy in place, make sure to revisit it ever so often, in order to validate its relevance to your target audience and confirm your goals are being met.
In this context, your product roadmap needs to reflect the strategy, mostly in choices you make about which features to develop, which improvements to prioritize and so forth.
Remember the part about your roadmap being a tool for communication? This is where you need to pay extra special attention to coherence and intelligibility. A communication channel is no good if it’s clogged, and a roadmap that won’t tell your product plan’s story is absolutely useless.
Your team, stakeholders and possibly users need to be able to understand where the product is going next, and endless spreadsheets or badly designed PPT flowcharts have the potential to be more confusing than clarifying. Download free product roadmap example