I call this article a roadmaps and roadblocks entry. Reason being, a roadmap means advancement to some and to others it can become a roadblock. It depends what side of the coin you are on and if the meaning of a roadmap is consistent. I would like to take a look at couple of points of views.
I thoroughly agree with Wiess & Robertson (2007) in the following quote, “A road map is a concise, commonly graphical, depiction of a planned migration toward a future state.” As a product director, a roadmap is a flexible chart that shows groups or categories of features that pertain to goals or areas of focus for a product and/or service. To us, a roadmap looks similar to the below taken from productplan.com (2017):
Looking at the above sample, you can see that there are four or five main focuses or strategic initiatives as an overarching strategy. In line with those initiatives are tentative release dates by quarter and grouped features, functionality, and/or release versions. Overall, our product team is undoubtedly comfortable with presenting a roadmap like the one above and allowing sales and marketing to create talking points. Now, the only challenge is transitioning to this type of document since our organization’s view of a roadmap is skewed.
Let us take a look at the below, retrieved from JerboXP:
This is the type of roadmap that we currently distribute to our sales and marketing team. I know, recipe for failure. I am pretty sure some of you Pragmatic people are cringing at the sight of this. For almost a decade, we have conditioned our SAM team to believe this is what a roadmap should look like, but do you know what this is? This is a RELEASE PLAN. This is a plan that should be used only by the product team and by our development team. Of course there are several reasons why this is not the smartest idea. Let me name a few below:
- A roadmap should be flexible to the public eye
- Providing dates to sales; well, that should be an obvious nail in the coffin
- A release plan provokes contractual commitments
- Direction should be fluid
- Goals and initiatives stay the same but the method in which they are met may change constantly, hence the required flexibility
All these reasons are obstacles we are trying to overcome with our current methods. We have started introducing actual roadmaps as presented in major objectives, but of course we have been met with much resistance and wanting to revert to old ways. I am hopeful that we will find a middle ground and provide worthwhile material to help our teams be successful. If anyone has any suggestions to make the transition easier please leave some in the comments below!
ProductPlan.com (2017). Roadmap Best Practices. Retrieved from https://www.productplan.com/help/roadmap-best-practices/
Weiss, D., Robertson, B (2007, February 26) Use Road Maps to Chart a Course to the Future-State Architecture. (ID Number: G00146266). Gartner Database.