As a product manager, I’m sure you’ve had to create a roadmap or two to convey future plans or, at minimum, as a sales tool so the sales people can talk somewhat convincingly about a purely hypothetical future. 🙂
Product roadmaps are meant to be tools that are used to provide a high level view of product direction over a number of release cycles. They are used for both internal and external communication, and should present a reasonable or likely prediction of the future of a product.
Aspirations vs. achievability?
But in reality, roadmaps are more often aspirational rather than achievable. What other documents do you produce that regularly require massive disclaimers and Safe Harbour clauses on the very first slide?
Roadmaps too often represent the dreams or hopes of the PM (or their manager), created without needed analysis of effort and resources. It’s very easy to create a roadmap that lays out a great story, with all the good stuff people want, being delivered 9-18 months out. Seems reasonable doesn’t it. There’s a lot of stuff that can be done in a year and a half, if we start thinking and planning for it now. Correct?
Funny how those plans quickly go awry. The reality is that most product roadmaps seem to have been created over coffee in the company cafeteria. They typically show aggressive development plans and significant deliverables over a short period of time. All of this sounds great and enables the PM to make impressive presentations to wide audiences.
And therein lies the problem. While the individual has to hold some responsibility, the majority of the problem lies with PowerPoint, the preferred medium for describing roadmaps. Yes, you heard it here:
This medium corrupts the message!
People want to see the roadmap on a single slide. Now how much information can one actually put on a single slide and make it look “great” and “worth the wait”? If each release is about 6 months, then you’re likely to have about 2 years worth of roadmap projections displayed on that one slide. It’s all great, until someone tries to define what Dev has to do to build and deliver to the roadmap. At that point, the roadmap might as well be tissue paper, as it has little substance.
Now, we all know that well analysed development plans for a single release often significantly underestimate the amount of work and time needed to complete. We all know it, because we’ve all experienced it first hand in at least one company where we worked. And if that is the case, then how would it be possible that a 2 year roadmap built on high level bullets with little detailed effort and scoping analysis could actually bear any semblance to reality?
At one company where I worked, the PM team was well aware of this problem, and if a capability was “on the roadmap” (nudge nudge, wink wink), it meant it had an almost 0% chance of being released in the next 24 months.
Sales people want product roadmaps to be set in stone once defined. This helps them make firm commitments to customers who need some pending functionality. On the other hand, sales people also want PMs and Dev to react quickly when a “big deal” is on the table and closing it requires “a few enhancements” to the product.
In the end, the roadmap is simply one of several documents that can be used to communicate future plans to potential customers. For consumer software, this is rarely an issue. But for B2B or Enterprise Software, the best thing to do is define a clear and regular method of communicating the roadmap and any changes in it to key members of the sales and marketing teams, to ensure they can position and communicate the future plans to their audiences as confidently as possible.
Saeed
On Product Management 
I think that more useful that roadmaps is defining the strategic direction that you would like to take. Do we want to develop social networking activity? Must we have more integration between products? etc
Then with each release cycle you determine which or four ideas will provide the most value and help you achieve your strategy. This will also allow you to better move with change in the market and better understand what your development constraints are.
You can sell the story to customers, they can see where you’re going, and you have “some” flexibility to include in your development cycle functionality that is important to customers or prospects (the latter of course may bring in revenue…)
Richard,
Thanks. The roadmap is bound by the strategic direction, but is a more granular vision of the future than the strategic direction provides. In fast moving or growing markets, it’s the roadmap (i.e. the planned functionality) that is really what people want to see. It answers (some times in the negative) questions about when and whether platform support or specific needed functionality will be available in the product.
The big issue with roadmaps is that salespeople want them to be static; in effect, promises of exactly what will be delivered by when. I make the analogy that the roadmap is to the product manager, what the sales funnel is to the sales rep. It’s what we know today and what we expect for the future, but many things can change it.
The best remedy is regular clear communication of changes to ensure alignment.
@Saeed –
I was in the middle of typing my comment, when your comment above perfectly filled in the blanks of what I was going to discuss.
Road maps are just that, a high level view of a high level estimation of execution. 5 minutes after the meeting is over, it should be thrown away and continually refined into a less hazy view of the project. No team has ever entered a project without the fog of war…
I agree that a roadmap is simply one of several documents that can be used to communicate future plans to potential customers. The key word is ‘communicate.’ The medium is less important than what is communicated. In my experience most customers know it’s not set in stone. However, I have made it my habit to be clear in every interaction with customers. I also make sure the sales team (and other customer-facing teams) know to get PM involved if the customer needs to see the roadmap. Regular communication to the sales and marketing team — as you state — will is critical to clear communication.
Roadmaps are really just strategic decisions “put to time”. It’s a great error and waste of energy to draw pretty and aspirational pictures that are divorced from the real decision-making process that prioritizes investments in technologies, capabilities and product features. In my Decision Driven(r) Strategy web service, I’ve focused on the decisions (the thinking that creates value) and just one-click publish the roadmap as the time-view of the competing alternatives across multiple decisions.
You’re absolutely right that the medium corrupts the message. If you’re going to roadmap, do it in a toolset that integrates multiple decisions and their evolution over time. Ditch PowerPoint as the repository of your strategy.
Great conversation. Check out Roadmapping Approach which I think addresses many of the issues raised here.
We also have tools, templates, webinars, etc. on the topic. http://tinyurl.com/d33ff4
Saeed – great post. As we all know a Roadmap is a wonderful and dangerous thing in the wrong hands. As one aspect of the arsenal of artifacts that product management can use, I agree that the roadmap is one communications vehicle for internal and external use.
It would be great to follow up on how Roadmap abuse has impacted product delivery and what types of “magical” roadmaps PMs have been asked to create for executives, customers and sales.
Pingback: Roadmap Discussions » Strategic Product Manager
This is the reason I like onproductmanagement.net. Insghtful post.