7 Best Practices on How to Build a Product Roadmap

It’s Product 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:

Nicolas Nemni (via Medium): The Lean Roadmap

The Lean Roadmap
Image from cloudfront.net

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

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.

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.

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

Roman Pichler: Three Common Product Roadmapping Mistakes

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

Clémence Debaig (via Shake Up ID): How to build a product roadmap based on User Research

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?

Related Posts

No More LEGO® At Agile Workshops – I am Tired of Building Airports

Four Lessons Learned From Making Customer Value Your Priority

App Prototyping With Absolute Beginners – Agile Experiments

6 thoughts on “7 Best Practices on How to Build a Product Roadmap”

  1. I don’t currently have any customers, so I can’t give you any details about specifically how many conversions my roadmap plan would generate.

  2. I’ve been thinking about my roadmap (since I’m still fairly small) as a “where’s the money” sort of introduction for potential collaborators, investors, or even employees.

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.