One of the biggest frustrations I encounter working with both development and product management teams is the lack of a clear product roadmap.
Often when you dig under the covers, the core problem isn’t that there is a lack of understanding of what features are coming next, but more importantly a lack of understanding of the priority, and why features are being built in the first place.
I have major problems with roadmaps. They are often put together just to give stakeholders a false sense of security that the team have a plan and aren’t wasting their precious time & money.
Roadmaps distract teams from building their relationship with the customer and developing a deep understanding of their needs/pains. Instead, the result is a chronology of features which may not improve the product.
They explain what, not why
One common problem with roadmaps is they focus too much on features, and not on the strategic drivers that suggested those features were important. They hide the decision-making process away from the team, and assert “this is the plan, deliver it”.
They take decision making power away from the team
We should be looking to empower teams to make their own decision on the best ways to solve a strategic need. Instead of feeding teams with a long list of features, we should be giving the team a list of objectives required, and then get out of their way.
They become delivery plans
Product roadmaps are often mistaken as delivery plans. Without context, they communicate “this is the list of features and the deadlines we are working to”.
Even if you have the best intentions to run an agile delivery, or treat each feature as a hypothesis, a stakeholder with the unrealistic expectation that a feature will be delivered on a certain date can undo all the good work.
They are full of assumptions
Planning is an essential activity, but any plan will very quickly become incorrect and out of date as new information is uncovered, dependencies change, or technology challenges arise.
A few months ago, I worked on a roadmap which needed to be changed the following day. In this case a new strategic objective outside of our control was added which meant we needed to shuffle everything!
Product roadmaps do not easily communicate the level of uncertainty contained in them. To an outsider, they communicate that each feature is equally well defined.
A better roadmap?
A good roadmap should then follow some basic principles:
It communicates that as time gets further away - so does our clarity around what will actually be developed.
It communicates the product and business strategic goals, tactics and the ultimate vision.
It communicates that features are hypotheses, and could be changed for others as new information is learned.
That the roadmap is a tool to prototype delivery options, and the team has the ability to change it as new information is learnt.
Product Goal Canvas
Earlier this year, I created the Product Goal Canvas to build a better roadmap.
It’s been a great tool for both myself and my clients to understand the link between our vision, business & product strategy, and the hypothesis features being built.
You can use the canvas to describe, design, challenge and pivot your strategy, and hypothesis features.
The Product Goal Canvas works great to prototype options in workshops, as well as a team communication tool.
I hope you find the Product Goal Canvas useful. I’d love to hear about some of the ways that it has helped, if you’ve adapted it, or even just that you used it!
Next time you’re building out a roadmap, question how you can better communicate your goals, uncertainty and timelines. Then finally, run an ideation session and prototype the roadmap with your team.