A Simple Tool to Create Product Roadmaps

Problem

My past experience is filled with working for small organizations. My current company is actually the largest organization that I have worked for. I thought that by joining a larger company I would be exposed to a multitude of resources and a much more sophisticated product development process. I assumed that they would have some amazing way of composing and presenting product roadmaps.

Actions taken

The reality is that most teams, mine included, use Google spreadsheets to create and internally present roadmaps. This is because it is simple, flexible to use, and people on the product team can easily make updates. In fact, it's safe to say that this tool has yet to be defeated. Though, I have heard of a handful of other tools that fellow product managers are using. While I can't speak personally for them, I have caught some buzz surrounding them from a product manager networking group I belong to. These include ProdPad, Aha!, and ProductPlan. In addition, I know that project management tools such as Airtable and Asana offer features and product roadmap templates to assist in building your roadmap. But for me, using Google spreadsheets to create roadmaps is simple and straightforward. Across the top, I have a timeline running. Then, down the side, I put the major themes. Usually, everybody has three major themes that they are working on so those are listed down the left side. I also include rows that go from left to right. These are displayed in different color blocks and represent different phases such as the discovery phase, the research phase, the design phase, engineering, QA, and release. I find that the value in creating a roadmap comes from doing the initial exercise of breaking things down. Once you lay everything out on a timeline you may suddenly realize that you have overcommitted yourself. That if you were to try and get all the things done that you wanted to, you would have to work on 10 different things at once, and that just isn't possible. So it's great to work on this primary arrangement. However, I am a bit skeptical about routinely updating them. I don't see many people keeping them up-to-date as time progresses until the next planning cycle comes around and you start all over. The intention is there, but in my current role, we are constantly reprioritizing so we set those high-level objectives for the six months, give them their timeframe, and spend less time worrying about recreating the roadmap.

Lessons learned

• I think the necessity and function of your roadmap depend on the expectations of your team. At different companies that I have worked for some teams fixate on having an updated document. An artifact that must always be accurate. However, that's not always the case. At my current company, we set very high-level goals and objectives for a six-month timeframe and then don't spend a lot of time adjusting the roadmap when changes are made. I don't think there's a right or wrong way to approach this. It just really depends on what you need for your team internally.
• If you are communicating your roadmap to the board, use a different level of communication than Google spreadsheets. In most cases, I have seen board presentations being done with slide decks. That way everything is kept at a very high level without putting actual dates on the map (use time frames instead). The presentation should involve elements of the roadmap but be focused primarily on addressing the problems that you are solving for the customers. Stick to presenting at that higher level.
• I believe there are challenges that come with adding a new tool to your deck. Not only do you have to pay for it, set it up, and remember to use it, but you also have to get everyone else in the company on board to use it too. So although I have tried to adopt new product road mapping tools, they usually fail and I end up going back to good old Google spreadsheets.