Ask A Product Manager: Effective Product Roadmaps

70 Flares 70 Flares ×

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

, , ,

  • Steve Johnson

    Good tips! And thanks for the link!

  • Jeremy Justice

    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.

    • http://www.prodpad.com/ Janna Bastow

      Ooh, thanks for the tip Roman!

  • Pingback: From Preparing for the Unobtrusive to Committing to the Guide | The Product Guy

  • nathanlatka1

    Fantastic article Janna – thanks for this!

  • Pingback: Too Many Features Will Kill You via @Contactzilla

  • Pingback: Product Manager Day 102: Prioritise the goals, not the features | wasabigeek

  • Pingback: Product Manager Day 119: Backlog into Roadmap? | wasabi geek

  • Sarns

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

70 Flares Twitter 0 Facebook 0 LinkedIn 38 Google+ 32 70 Flares ×