Ask A Product Manager: Effective Product Roadmaps "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 11 June 2013 True Product Roadmap, Question, Mind the Product Mind the Product Ltd 784 Grafiti Question Mark Product Management 3.136
· 3 minute read

Ask A Product Manager: Effective Product Roadmaps

My question is what have you used to create and maintain the roadmap, and in your experience are there any good resources like sites or books where I could really learn more?

I’ve done searches and find lots of very high-level visuals, but I’m not sure that that is the correct way or whether it should be more detailed in nature. I’d like to gain a better understanding and learn the most effective way to present and maintain the data.

The prior company I worked for never really paid much attention to it – I did it more for myself – but our roadmap really consisted of a huge bug list and new features that I just managed based on our development schedule. So I mainly used Word and created a table with quarters and listed the main features (and larger bugs) per quarter I wanted to get developed, and called them new releases, and adjusted it along the way based on what didn’t get developed and executive non-rational decision making.

Chris Garby

I certainly feel your pain!  I have also had roadmaps that are overrun by bugs and feature requests. It took me a long time to figure out what was going wrong, because  – inevitably – the roadmap would slip as it’s impossible to plan to that level of detail on an 18-24 month horizon in a single document.

First up, stop thinking of your roadmap as a Gantt chart.  It’s an easy mistake to make because so many product managers use project management tools or techniques to make their roadmap. My ProdPad co-founder, Simon Cast, wrote about this – Don’t use Project Management Tools for Product Management

Think of your roadmap as a strategic communication document.  Its purpose is to show your team and other stakeholders what your product vision is and what the high-level initiatives will be to get there.  It’s not a device for showing off every last nook and cranny of your development plan, and doesn’t need to include your list of specific bugs or minor features you want to get out the door.

Now, realistically, as a product manager, you probably do have a list of bugs and little items that need to be addressed and moved through development. This is fine, but remember that at that point (when you’re helping the development team move items in and through their Kanban/Sprint/Backlog/whatever), you’re playing the role of a project manager or product owner rather than the product manager.  The roadmap is a product management document and should live separately.

Leave out the dates. You don’t know what the expected delivery dates are for anything that goes beyond a couple weeks – ie the length of a sprint, or however long ahead your team specifically plans out as a distinct project or deliverable – and so you shouldn’t fake it! Putting a date on a roadmap, even if it’s vague like ‘Q3 2013’, will more often than not end up setting expectations you don’t deliver on and cause undue stress and finger-pointing among various stakeholders.  While ideally, as the awesome product manager that you are, you’d like to think that you can put a rough estimate on something and stick to it, your estimates suck (from a great book called Rework I recommend everyone reads!).  You don’t know what bugs are going to creep up and change your plans, and even if you did, by the time you get to ‘Q3 2013’, your product strategy might need to adapt and change based on what’s going on in the market, your users, your competition, etc.

Think of your roadmap as a guide, intended to keep everyone aligned and in the loop, but not as a strict project plan. As Steve Johnson said here: “I’m okay with sharing the roadmap… as long as clients and sales people know that the roadmap is a plan and not a commitment.”

As for other great resources, there’s some really smart people you can follow:

  • Steve Johnson’s just published an ebook all about roadmaps.
  • Marty Cagan is hugely respected in the industry and always has me nodding along to his articles. Here’s some good stuff by him on roadmaps.
  • Martin Eriksson (hat tip for introducing me to the concept of roadmapping without dates) founded ProductTank events for product managers and knows his stuff. He’s written a very useful article on prioritising.
  • And finally, there’s, where a bunch of other smart product people write. Here are some posts about roadmapping.

Ask a Product Manager is a new series of articles based on great questions and answers given by product managers.  Got a question of your own?  Ask away:

Comments 17

can someone help me find few example regarding this question :
What are all of the right questions to ask when trying to understand the size of an initiative in digital


My name is Rodrigo, before anything I will apologise for my english, it is not my first lenguaje.
I was reading your article (this one) and it was really helpful, but after reading it, I started looking for some templates on how to document the roadmaps for my product and every template that i could find was with dates. So those wont work.
My question is if you have some templates on how to document a roadmap for products.

PS: is rejecting my mails.

A few of the comments use “Agile” as a reason for removing the dates from a roadmap? As a seasoned product manager – who remembers many non-agile projects – the dates may have been available in non agile approached but they were meaningless.

Following a lean product management style, I prefer the roadmap to communicate the upcoming problems we will explore to deliver value (I guess this could be called themes, but I prefer problems). This really does cement the document as a strategic tool communicating to stakeholders how we will add the desired value.

Thanks for the article Janna.

[…] Create and curate a roadmap Have a roadmap. A roadmap is a high level plan of how to deliver with limited resources. Use it as a guide, but change it as you learn from your customers. Use it as a focal point for the work that you’re doing. If you’re working on it, is it on the roadmap? If not, should it be on the roadmap? If not, should you really be working on it? Here’s a quick discussion that offers some tips on making a roadmap. […]

Disappointed – all this is is links to other peoples books, Garbage, uninsightful waste of my time

Brian Lawley’s book “Expert Product Management” also contains some useful product roadmap tips IMO. I particularly like his discussion of theme-based roadmaps, which are great for new products and major updates.

You’re comment about a roadmap being used to keep stakeholders informed and convey a product vision is spot on. I disagree though with this current trend about removing the dates. There are many companies who either use your product as part of a broader portfolio of services they sell (think OEMs selling mobile phones) to IT departments integrating your HW/SW solution into their existing network. Without the ability to assign dates your product will be available and ready, they cannot properly evaluate against their internal needs and timelines, much less the competition. Some level of granularity is needed else you leave sales forces hamstring and marketing department unable to fully support.

As product managers, we constantly deal with trade-offs. How we structure our roadmap to effectively keep internal stakeholders motivated without crushing them, but still allowing our customers time to effectively plan is one we all need to address seriously.

In an agile environment, I’ve found that it is unrealistic to put hard dates around anything outside of the current quarter. The way I prefer to represent these timelines is by breaking down the product features by month inside of the current or closest upcoming quarter, then providing more generic quarter-specific timeframes everything else. In the automotive space, the constant question is “when is it going to be done” and “phase 3” isn’t a satisfactory answer. Our customers will drop our product and move to the competition.

Due to the nature of agile product development, fluxuations to priority and/or new requests can create significant headache if firm dates are given beyond a few of months. I have found that it is possible to communicate that all Q3 type estimates are subject to change based on re-prioritization. This has worked well for my products and teams.

If you’re waterfall, however, you have to live and die (in my experience, mostly die) by the dates 🙂

Join the community

Sign up for free to share your thoughts

About the author