Product Roadmaps: Drop The Dates
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:
- Certainty in the immediate term.
- Progressively lower degree of certainty into the future
- Phrasing to encourage discovery around problems and features imagined for later development.
- Inclusion of proper language to be used with prospects and clients around the features.
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?