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