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.

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.

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:

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.

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: ask@mindtheproduct.com

About Janna Bastow

Janna Bastow comes from a user-centric design background and has extensive experience building social web experiences. She founded ProductCamp London in 2010 in an effort to meet and learn from other product managers.
As a product manager always looking for better tools, she co-founded ProdPad, product management software that helps you manage your roadmap and your product backlog.
Update: We’re developing an e-course to help you set up and introduce a flexible theme-based roadmap, at your organization. We’ll drop it in your inbox when it’s ready – sign up here.

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.

aaronhancock

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 🙂

Roman Pichler

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.

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.

Vasiliy Ivanov

That’s a good description of a roadmap technology vs project management

Rodrigo Nicolás Giraudo

HiJanna,

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.