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 to together and define what needs to be built to meet business demands in 2016. So, here are some best practices on how to build product roadmaps the agile way.

You Don’t Have A Product Vision?

If you don’t know where you’re going, any (product) road (map) will get you there. (Yup, my favorite quote from Lewis Carroll works here, too.) Before you try to come up with a product roadmap, fix the vision problem first.

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.

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.)

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.

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.)

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.

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.