Do we really need a product roadmap? Why? How do we go about creating a product roadmap? What are a few of the best practices? This article sheds light on these 'planning questions' which probably every product team has come across. Especially agile teams. Let's quickly review first what is a product roadmap and then review top three concerns and their solutions when it comes to building it.
Product roadmap is typically a visual plan for depicting the vision, plan and direction for the short term to long term features, from product development standpoint. It also works as a guideline for costs estimation and budgeting. Its target audience is comprised of a variety of stakeholders including but not limited to the senior leadership team, customers, partners, domain SMEs, sales and marketing, engineering teams. It is created and maintained for shared understanding as well as ongoing feedback from various stakeholders. It can be arranged in many ways such as by features or by releases or by products/in a platform.
Now let's look at some common concerns while building the same.
Concern #1: It seems to be a waste of time to spend time on building a long term roadmap as we really do not have clarity on the features. Time is money!
The above mentioned concern is very much a genuine one. Even though we know in theory we must combine long term view with near term, it is hard to exactly incorporate the same in real life. You may hear, "We are a market driven product (or even a service)". "A lot of things are fluctuating". "We as an organizational way of working, are Agile". "We follow agile approach and practices. We are not just agile but super agile !" And by the way 'super-agile' is not my own coined term, I have heard this in one of my most exciting projects.
The answer is despite all these concerns, there is a need to take our sight off the near-term road, to long term road, say 1 year down the line. Having an overall roadmap will help the management and product teams know which are the broader features/epics to be implemented and are of priority. If you are building say a multi product platform, it will involve many such key features that are a must-haves (for each product in it). Creating a roadmap will give a guideline of where are headed towards.
Concern #2: The engineering team or say, the engineering leads in particular, are not fully convinced of their participation in creating the roadmap.
This is also a genuine concern, probably a broader one. Despite all the awareness and training over agile practices, the engineering or delivery teams may not be fully convinced of their participation in creating and maintaining the roadmap. 'This is probably only a product teams' work. This might even be the founder's concern, especially when it comes to small start-ups. '
Despite all these concerns or say resistances, the fact is some estimates are better than nothing. Traceability is crucial. Not just at the beginning of creating a roadmap or a plan, but also throughout the process/product development. It is often needed to know estimates (be it rough estimates or say expert estimates) for various key features from each product in a multi-product platform. Each will have MVP of its own. For each 'near term' feature map and a long term product feature map is necessary. Long term or the 'later' features need not have details. Even a 'leaf node' for a feature in a large tree is valuable. It has some estimation value, some potential to make an impact. Make or break a product or its deadline. One can always use the most effective and apt estimation technique for forecasting the time and dependencies among these features.
Concern #3: All of this makes sense, still how to go about creating and maintaining a product roadmap quickly and still efficiently. We don't like big long documents and it is difficult to parse through those. It takes time too.
Now this concern is more of a 'how-to' concern. Indeed the days of long haul documents are gone. I have worked on 600 page requirements specifications documents for enterprise clients, I now work on shorter light weight documents too, and am now more inclined to create visuals whenever possible. One of the finest techniques I have found to be very very helpful and fun is to create a mind map. Create product roadmap as a mind map or rather as any visual technique your team may want to adopt to. Picture says a thousand words.
You can also create it through visuals and also maintain it as part of the product team on an ongoing basis. Involve engineering teams for their estimation or to hear out the technical or implementation constraints/risks. Add those to the visuals. Add references among the features to make a note of known dependencies. Needless to say, make it a practice to update this roadmap on an ongoing basis at a set time interval. It is not as cumbersome as it appears to be, in fact it is more of a work of art as we gain some practice over it. It is much of solving a jigsaw puzzle and putting the pieces together to make a big picture.
ON AN ENDING NOTE
To summarize, we have looked into a few concerns or resistances that typically come up during creating of a product roadmap and one of the effective ways to create and maintain the same. Thoughts?
Author: Swati Pitre, Senior Business Analyst
Swati Pitre, CPRE®, CBAP®, is Sr. Business Analyst, Consultant and Trainer with 25+ years of industry experience across various domains and geographies. Her specialties include Process Improvement, BPM, Predictive Analytics, Product Development, Quality, and Governance. She also undertakes various training courses such as CPRE®/CBAP®/CCBA®/ECBA® Prep Courses, Comprehensive BA Job oriented Course, BPMN, Agile BA Course, and several other customized courses. She is also an enthusiastic Toastmaster/Public Speaker and has completed the Effective Coaching Pathway at Toastmasters International.