Product Management

Drop the Dates From Your Product Roadmap

Roadmap idea (1)

Can a Product Roadmap De-Emphasize Dates?

In a recent post, I wrote about Selling roadmap items.  To communicate “what’s coming” with Sales, Product uses an internal roadmap–and if not carefully formatted, this document may convey more certainty than is accurate.  One of the strategies I suggested is to publish a product roadmap without dates.

A tactic I’ve seen some agile shops apply is to omit all dates from roadmaps.  Instead of a roadmap, they show a prioritized high level feature backlog, which includes more detail for immediate features and less detail for more distant future features.  Some may even include dates on the top item or two which may be at a detailed level of planning.  This eases the conversations around items beyond the short term (about which there are the fewest “unknowns”).

This week, Simon Cast of ProductTank and MindTheProduct wrote about this suggestion at length, in a post titled Roadmapping Without Dates.  In this post, Simon describes why his product roadmap software, called ProdPad, omits all dates from product roadmaps.  The rationale is pretty solid and echoes the theme of the suggestion I’d posted.

Simon explains that too much granularity in the roadmap makes a document more of a project plan than a product roadmap:

The granularity turned out to make it very hard to manage. Not because of complicated UX but because, suddenly, you are managing a single idea on a day to day basis, shifting them around changing their “delivery length”. It was very Gantt-like and more about project management than product management.

He describes in a nutshell the primary problem with including dates in a roadmap, especially dates that are far out in the future:

As Martin pointed out, the point at which a specific date is added to a roadmap is the point at which everyone but the product manager believes the item in question will be delivered. Too often,it doesn’t matter how you caveat the date, it becomes gospel. Suddenly, you are judged on whether you meet the entirely fictitious dates. The judgement, unfairly, doesn’t take into account changing priorities, the cyclical nature of product management, or the fact that it is non-linear.

A better Roadmap Format

Simon shared an image of the roadmap used in ProdPad, and I like it a lot.  It resonates with a problem I’ve been wrestling with: I believe that a roadmap format which shows no difference in likelyhood of early items vs. late items is often responsible for mistrust and miscommunication between product development and sales & marketing.  Agile organizations deliver value by being able to shift priorities as more learning takes place.  Why not embrace the flexibility?

I’ve also been working on a roadmap concept, a sketch of which I’ve included below.  I have been churning over several objectives which I tried to address in this concept:

  1. Certainty in the immediate term.
  2. Progressively lower degree of certainty into the future
  3. Phrasing to encourage discovery around problems and features imagined for later development.
  4. Inclusion of proper language to be used with prospects and clients around the features.

The following sketch was developed with those objectives, and with input from a product roadmap I spotted during a tour of Daxko’s Atlanta offices and with a few words from Will Sansbury:

Roadmap idea (1)

Some thoughts about my sketch:

  • First, you’ll see that this is depicted as more of a backlog than a roadmap.  It’s easy to shift the dividers between segments up or down quite easily, which is especially useful when managing a portfolio of products and having to shift capacity across product roadmaps.
  • The fact that the order is descending by priority is important.  This means that as people scan down the list, if you’ve done a good job of ordering the most important things first, many of the “most important things” will resonate highly.  If items aren’t getting traction with prospects, perhaps they should be de-prioritized.
  • The answer to prospects’ questions of “When?” for items down the line should be met with discussion.  How important is it to the prospect?  This might be a great conversation for the product manager.  Perhaps it’s more important than understood.  Perhaps it’s an item that can be raised in priority should a deal be feasible.  This should be a trigger point for a conversation, NOT a question that should be dreaded or dodged.
  • Items planned for the current quarter (Q) are planned, measured and sized.  This suggests confidence that what’s planned can actually be achieved.  Since priorities in the short term should NOT drastically change, language around these features can reflect certainty.
  • Items in the following quarter (Q+1) are thought through to a good level of detail, but they aren’t measured or sized.  Language around these items should reflect likelyhood, with the caveat that priorities may change.
  • Finally, items beyond next quarter (Q+2 and beyond) are written with less clarity, and also not sized or measured. Here the language suggests these are under consideration, and prompts the internal consumer to probe into that area with the prospect or client.  Items beyond next quarter often ARE guesses which will become more confident with more input, so it makes sense to provoke that input earlier rather than later.

What do you think?  Can this kind of tool help to get product and sales working on the same page?  What would you add or remove?

Join over 110 others who are receiving articles on B2B SaaS product management & marketing, once or twice per month!
We hate spam. Your email address will not be sold or shared with anyone else.
Powered by Optin Forms


  1. I like your descriptor of “are these important to you”? That’s something I’ve learned to do at every opportunity. It’s kind of like when you look at the clothes you wore in old pictures, and you say “did I really wear that?” Regularly showing the features to stakeholders and clients reminds them of what they might have insisted upon as SUPER IMPORTANT at one point, but has since become a low priority – or in some cases, you missed the implementation window and it’s just a moot point. Without that regular feedback and validation, you might be building things no one is going to use (though hopefully you’ve already taken a stand and determined for yourself whether the feature should be included).

  2. Virtually every roadmap I’ve presented was ambiguous about dates. Unless it’s absolutely confirmed in an active development plan, I never put dates, and even then it’s at best a month. e.g. Feb 2013.

    Usually the “dates” involve quarters (e.g. Q2 2013) or halves of years (e.g. 2H 2013) or for things that are really far out just the year — e..g 2015.

    And of course there is always the mandatory “weasel” slide at the front of the deck stating that everything in the ppt is just a plan and not a commitment and can change at any time etc etc.

    If I’m presenting to Sales and they want commitment, I first explain that my roadmap is like their funnel forecast. It’s my best assessment of the future but can’t make a commitment because things will change. And at that point I will update the roadmap. Most reps get it, but a few object and want certainty.

    At that point, I look at those few and tell them that I will give them certainty in the roadmap as soon as they give me certainty in their sales funnel for the same time period. e.g. 12 months or more out. At that point the objections disappear.

    I recommend this strategy to every PM who has this problem.

Leave a Reply

Theme by Anders Norén

%d bloggers like this: