It’s Roadmap Building Time Again!
The end of 2015 is nearing and it’s product roadmap building time again—at least for those companies that are still dedicated to the old command-and-control model. In the next few weeks, execs and (key) stakeholders will come together and define what needs to be built to meet business demands in 2016. So, here are the seven best practices on how to build product roadmaps the agile way.
I. You Don’t Have a Product Vision?
If you don’t know where you’re going, any (product) road (map) will get you there. (Yub, my favorite quote from Lewis Carroll works here, too.) Before you try to come up with a product roadmap, fix the vision problem first.
II. Don’t Make Epics And User Stories A Part Of The Product Roadmap
A product roadmap is high-level plan—based on what you know now—where your product is heading. So keep out epics and user stories out of the roadmap to lower the information noise. It’s all about the big picture.
III. List Of Features Syndrome
By the way, a bunch of features does not constitute a product and a list of features doesn’t make a product roadmap. Therefore, focus on themes, not features. A theme is a promise to solve a customer problem. It requires user research and you will need to identify pain levels, effort levels and business values to prioritize your product roadmap. Focusing on themes shifts the attention from playing feature catch-up with competitors, pet features of individual stakeholders and the dreaded “we know what to build” attitude to delivering customer value. (There’s a great post on that by Clémence Debaig, see below.)
IV. Don’t Confuse A Product Roadmap With A Release Plan
A product roadmap is not a release plan either. The roadmap is covering the strategic planning for one or more years to come. The latter one is dealing with the next two or probably three sprints.
V. Don’t Put Dates In A Product Roadmap
Speaking of releases: Don’t put dates anywhere in the product roadmap. People will take any date in a roadmap for real: “You said Q3 and you haven’t yet delivered”. No stakeholder will understand or even be interested in the narrative why you haven’t yet delivered, e.g. because of the cool stuff with higher a customer value that you built in the meantime. And if you cannot avoid dates, then make the scope as broad as possible. (You can’t promise both date and scope at the same, that never works out.)
VI. A Roadmap Requires Regularly Attention
Roadmap building needs to be regularly exercised—not just once a year or quarter. Creating value for the customer is not about sticking to a plan, but being able to respond to change.
VII. The Roadmap Tool Question Is Overrated
You don’t need a tool to create a product roadmap. Whiteboards and index cards are just fine, as are Google docs, Keynote or Excel—whatever you feel comfortable with. The content of the roadmap matters, its presentation is secondary as long as all stakeholders buy in.
My Reading Recommendations:
Medium): The Lean Roadmap(via
There are so many features you may want to add to your product, but there never seems to be enough time, am I right?
The GO Portfolio Roadmap:
This post introduces the GO Portfolio Roadmap, a roadmap that describes how the members of a portfolio or product family are likely to grow.
Roadmap Alternative FAQ:
So I decided to sort through the feedback and write up an FAQ of your most common questions. Even if you didn’t have any questions on my prior article, I hope you’ll at least skim through these questions and answers in case something in there surprises you.
The Alternative to Roadmaps:
I have always loved the General George Patton quote: “Don’t tell people what to do; tell them what you need accomplished, and you’ll be amazed at the results.”
Unfortunately, typical roadmaps do just what the General warned against – they tell the team what to do. Usually that’s in the form of a prioritized list of features or projects that someone believes will actually solve some problem (even if that problem is often not explicitly stated or understood).
Three Common Product Roadmapping Mistakes:
This post discusses three common product roadmapping mistakes to help you avoid and rectify them.
Shake Up ID): How to build a product roadmap based on User Research(via
That’s it, your user research is done and you have found plenty of insights. (Well done!) But how to sort them? How to transform them into actions? Where to start?