7 Best Practices On How To Build A Product Roadmap

Published in

Age of Product

4 min readNov 18, 2015

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. (Yub, my favorite quote from Lewis Carrollworks 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 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, for example because of the cool stuff with higher a customer value that you have 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 time, that never works out.)

A Roadmap Regularly Needs Attention

Roadmap building needs to be regularly exercised — not just once a year or qurater. 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.

Please hit the “heart button” if you found this post useful, or follow my Medium publication. Read more on the Age of Product blog.

My Reading Recommendations:

Nicolas Nemni (via Medium): The Lean Roadmap

There are so many features you may want to add to your product, but there never seems to be enough time, am I right?

Source: Medium: The Lean Roadmap

Author: Nicolas Nemni

Roman Pichler: 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.

Source: The GO Portfolio Roadmap

Author: Roman Pichler

Marty Cagan: 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.

Source: Roadmap Alternative FAQ

Author: Marty Cagan

Marty Cagan: 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).

Source: The Alternative to Roadmaps

Author: Marty Cagan

Roman Pichler: Three Common Product Roadmapping Mistakes

This post discusses three common product roadmapping mistakes to help you avoid and rectify them.

Source: Three Common Product Roadmapping Mistakes