Roadmaps – a brief intro

If product management is a puzzle than the roadmap is its key. They are set in place to give stakeholders visibility and clarity regarding the short to medium term for what will be built as well as the general direction of the company. A product without a roadmap can only be successful by chance while one with a proper clear roadmap will give customers and prospects the sense of security that the product they chose is progressing in the right direction and provides clarity to internal stakeholders.

Although a roadmap timeline can vary from three months to a few years I’ve seen that twelve months works best. This way you can align your roadmap to the company yearly goals, you are not overstretching and risk over promising and you provide enough visibility compared to a six or 3 months timeline. Also if you try to predict for more than twelve months you risk not accounting for all industry or market changes. As product owners we need to keep the roadmaps up to date in order to reflect the current state of the portfolio. Updates should be done in line with market evolution, industry trends, customer demand(actual and forecast) as well as company goals and development team progress.

The most difficult decision regarding a roadmap is what format the data should be presented in and I believe this decision should be made with your current personas in mind. Are your personas detail oriented than you should go for a Gantt type or if they are more creative a priority bucket style will work better. No matter what structure you select you will always have benefits as well as challenges. The most common structures are:

• Gantt chart
• Timeline (usually for milestones)
• Time buckets (e.g. 1-3 months / 3-6 months / 6-12 months)
• Priority buckets (Must / Should / Could)
• Simple ordered list based on priority

If we decide on using time intervals to structure the data we need to make sure we chose intervals that provide enough clarity to stakeholders but also provide enough flexibility to account for unknowns. Time intervals can vary from the exact date (e.g. 26th of March 2190) to a specific month (e.g. Release feature A in March) or even to a quarter. The more fuzzy a time interval is the more flexibility we have and the less trust a stakeholder will have with the roadmap. If the decision is not to use time interval than we can use MuSCoW to structure the roadmap. I’ve seen from experience that this works best, especially in start up environments where the teams are very dynamic and priorities change easily.

The second decision we need to make when building a roadmap is the level of granularity for each of the cards. I’ve seen product owners that create roadmap cards for each new minor design change and other product owners that create a single card that covers all design improvements done over three months. My opinion is that truth sits in the middle. We should never forget that roadmaps are strategic tools and so the cards should reflect more than stories in the backlog but they should still be done in a reasonable amount of time in order for stakeholders to see progression.

The last item we need to consider is how much detail we want to show on each card. The goal here is to make sure that users understand what a card is about but it should also provide product owners with flexibility for cards with flexible specifications. We should always keep in mind that the scope of a card that is scheduled to go into development in ten months time will change.

Once the roadmap is complete, no matter on what structure we decided, we need to make sure we keep it updated and make it available to stakeholders in order for them to provide feedback on upcoming cards. Always remember that roadmaps not just show what the development team is working on but also how well a company understands the industry, market as well as the needs of its customers.

This post has been published on www.productschool.com communities.

By : Cosmin Elefterescu