July 12, 2020

Why your product roadmap should not be a Gantt chart.

My introduction to roadmapping at my first product management job was a painful one.

My introduction to roadmapping at my first product management job was a painful one. I came into AIESEC's global office as a new product manager with little experience and thus took "how it was done" at face value, not questioning it. Every six months, there was a major organization-wide conference, where all new product developments would be introduced and downscaled to the organization's national offices. Buy-in and education to country managers would happen at this touchpoint. It was common knowledge that if you didn't release your new features there, it would be very hard to downscale and implement them.

Thus, the product team would take all the things they wanted to achieve and planned backward from the conference date to the current moment and would cramp everything into a Gantt chart based on estimates provided by the engineering team. The result was devastating.

Of course, we never were able to stick to our estimates. Every week we found ourselves rearranging the Gantt chart, finding ways to still fit all our projects, constantly renegotiating their scopes. We were generating an immense amount of planning waste. Dropping projects was off the table, as we had already committed to all these projects to our stakeholders. Whenever an unexpected problem arose, we tried to fix it with the minimum amount of work possible as not to derail our timeline any further. This led to us accruing tons of technical debt that we would never have the opportunity to pay back. As we were cutting back on the scopes of our projects all the time to still deliver them by the conference, we ended up with Frankenstein products that hardly worked as expected and obviously fell short of expectations when it comes to delivering results.

I knew there had to be a better way to do it, but I never imagined it to require a framework that was simpler.

When I started my current job as a product manager at Fave, I was expecting sophisticated product processes, using software tools specifically designed for product management... but I was mistaken.

All you need is a Google Sheet with a simple table format that follows the RICE priority matrix to build your roadmap. It stands for Reach, Impact, Confidence & Effort. Throw in a couple of additional fields that you need to make your life easier as a product manager and you're all set. You will notice this looks pretty much like a product backlog, and it is. Your roadmap shouldn't be different from your backlog. Unifying these into one document also ensures that the roadmap you communicate externally is always as up to date as your backlog.

  • Automatic prioritization: Whatever you have to do next is on top of your roadmap, no questions asked.
  • No time element: While a Gantt chart forces you to give a start date and duration of your product initiatives, this layout can be a repository of things you might be doing in the future or even communicate ideas you specifically won't be doing.
  • Connected to Jira for realtime status.
  • Easy to share and collaborate, as Google Sheets allow anyone you want to have access to and to comment on.

Whenever I read about roadmaps online or in product management books, the respective authors never forget to share about the most important attributes of a roadmap. What they fail to provide, however, is a proven template that you can simply copy and get started with.

So let's go into some of the fields you're going to want to have and how you'll use them to build your own template ūüí™.

Status: Not only is it important to show what the current status of an initiative is, but also to translate it to layman's terms. Your stakeholder might not know what 'Staging', 'QA', etc.. means. Thus it's important to choose statuses that are easy to understand. Additionally, it's important to have some non-Jira statuses such as "Decision needed" or "In Planning" or even "Not doing". The last one is very nice. It gives you the ability to put input you get from others in the roadmap, to give them the feeling of being heard, while still communicating effectively that it does not fit in your current plans. 

Business Impact: you will notice that this one is printed in big letters. As your roadmap should be easy to read and your stakeholders should know what to focus on, this steals all the attention. Why are we building this? The most important question you need to answer for your stakeholders to get their buy-in and align them on your product vision. It's useful to properly craft this message as this will also be the message you would want Marketing, Sales, and Operations to pick up and reiterate. Don't go into much detail. You don't want to make your roadmap unreadable by having one item take up the whole screen. Few sentences should suffice. Everything else, you can put into a PRD and link the doc in an additional column.

Product area, type & initiative: These columns allow you to easily categorize your product backlog items across multiple platforms, products, or initiatives and thus make your roadmap more scalable.

ETA: It's good to stay vague, as it's the estimated time. You don't want people freaking out when something is not delivered on a specific date they were expecting it. It's enough to put something like "Q3 2020".

Impact metric: I like to have a clear impact with actual measurable outcomes (not just a 1-10 score) that allows me to easily compare the impact of different items. This is not always applicable to all your initiatives.

Cost: If you work with external developers where each development effort is associated with real costs, this becomes more important, but can also help you justify doing or not doing something when putting the actual cost into perspective (i.e. should we do an initiative that brings us $1000 but costs $10.000 in developer salaries).

Effort Score: I like to use T-Shirt sizes (S, M, L) as estimating effort does not have to be rocket science. It's also good to get the input from the engineers here, but over time you will be able to make judgment calls for yourself. Also, don't forget to include the effort it takes you as a product manager in planning or other departments in implementing. After all, you're not only prioritizing for the engineering team but for the whole company. Note in the screenshot below that I also give values if the effort is Too High, which usually means it should be broken down into separate deliverables. If I don't know how much effort it is, I can select Unclear. It is important to keep the formatting including the numbers in front (i.e. 3. Medium), giving lower numbers the higher the effort. We'll use this to calculate the Prioritization Score.

Reach Score: I don't personally use this metric, but it's a good score to have if you want to prioritize by how many people will be affected. I like to include this in the impact score. If you use it, make sure to also include numbers (i.e. 3. High), giving higher numbers for higher reach. This will allow you to include the score in the calculation of the Prioritization Score.

Not all fields I present to you here will be useful to you. Just pick and choose what fits to your working style and organization.

Impact Score: These are also measured in T-Shirt sizes. When scoring, you can include anything from how many people are reached to how much money you will make, or even non-quantifiable benefits. Again, we include numbers (i.e. 3. High), giving higher numbers for higher reach to include it in the Prioritization Score.

Confidence: In this column, you will fill how confident you are about this item having the impact you assessed. By filling percentages, such as 0%, 25%, 50%, 75%, and 100%, you are able to account for any ambiguity. This also serves as a call to action to do your homework and increase the confidence score.

Priority vs Prioritization score: In the end, you will have a priority score for each item based on your effort, reach, impact, and confidence scores. It's always good to let simple math do the prioritization for you, but sometimes some common sense is needed to give additional flexibility to your priority. Use the additional Priority column to fill your final priorities starting from 1 and sort by this column to always visualize what is your top priority. You're probably interested in how the Prioritization Score is being calculated.

Let's break down the formula.


As you can see in the screenshot, to calculate the Prioritization Score in J2, the formula utilizes the values in M2 (Effort Score), L2 (Impact Score) and K2 (Confidence). If we scrap all the extra formulas, in its essence, we are simply calculating J2=M2*L2*K2. The extra stuff simply makes sure Google Sheets is able to take what we put into the fields as input.

Starting with the first part of the formula SPLIT(L2,".",true,true): We cannot simply factor the content of J2 into the calculation, as it is a mixture of number and text. Of course, we could choose to simply write "3" instead of "3. High". However, this would make this roadmap less digestible for your stakeholders. We could've also simply written "High", but this will make it harder for us to perform calculations. Hence, we chose "3. High". All SPLIT(L2,".",true,true) does is to split "3. High" by the period (.) character and takes the first part, which results in 3. The second part of the formula SPLIT(M2,".",true,true) does exactly the same. For the third part if(K2="",1,K2), we are simply checking if K2 is filled (as you might not always feel confident to fill a Confidence Score). If it's not filled, we assume 1 or 100%. This already gives us all the pieces of J2=M2*L2*K2. The final part is wrapping it in the IFERROR function, which simply checks if there is any error in the formula (which would occur if any of the fields are not properly filled) and either returns the final score or nothing.

There are only two fields left to finish the roadmap template.

The field for Ticket/PRD allows you to reference any further documents. This is where you can put all your research, user flows, prototypes, etc... Once you have a Jira ticket, you can link it here and it will automatically pull the status in column O. This is mainly for you to keep an overview and easily track what's the status of your latest developments. All in one place. Neat, right?

In order to make column O work, we need to take use of the Jira plugin. Google Sheets allows you to integrate with various tools, including Jira. For this, you select Add-ons from the navigation bar and click on Get add-ons.

In the pop-up, you search for jira and select the first result (Jira Cloud for Sheets). Press install and you will receive a new add-on inside your Google Sheet. Select it from Add-ons and press Open... which opens a navigation bar on the right hand-side.

You'll want to select Get issues from Jira. Import type should stay as JQL and JQL query can also stay the same. Go into Fields, press Edit and select the fields you need. The main ones you will need are Key and Status, but feel free to select any others. Finally, in Schedule you can press Edit and change it according to your liking (i.e. Daily). Then you press Refresh Issues and it will create a new tab for you.

Tab automatically created by Jira Cloud for Sheets

The last step is for you to create the formula to pull the status from the Jira import tab into the Product Roadmap tap. The formula in O2 is:

=iferror(vlookup(split(N2,"https://test.atlassian.net/browse/"),'Jira import'!B:F,3,false),"")

There are some elements that you should already be familiar with. iferror checks if there is any error in our formula (i.e. if the respective ticket cannot be found). split will take the value in N2 (i.e. the link to the Jira ticket) and will split it in a way that only the ticket ID will be left.

Note: you need to change the formula to split by the link to your respective Jira Cloud account. I.e. if your Jira were to be hosted at https://test.atlassian.net, the function would read split(N2,"https://google.atlassian.net/browse/").

Lastly, the VLOOKUP function will check for the value (in this case the ticket ID) and see if it can find it anywhere in the range of B:F in the Jira import tab. If it finds it, it will take the value from the 3rd cell of the row it found the value.

Note: In my case, Key is in column B and Status is the third cell from column B. In your case, Key might be in column A (hence your range would have to change) and Status might be in the 2nd cell of the row it found the value.

With this, you have finished our roadmap. A simple, easy to read tool that you will always, almost automatically, keep up to date and that your stakeholders will appreciate. I've put all my learnings from my three years of product experience in this roadmap. If you have any feedback or suggestions for improvement, I am very happy to hear it!

If you like the way my template looks or just want to save time and get started right away, you can get it here.

other posts