By Ben Stein
I was recently asked what software I use for roadmapping. ProductPlan? Monday.com? Wrike? Trello? Confluence? Roadmunk? The answer is none of these. I use Google Docs and Sheets, because they’re simple and can accommodate all my asks. Roadmapping is a bottomless pool that product planners can get sucked into if they’re not careful. While it’s a key component to product planning, it always needs to serve its two primary functions:
In my experience, if your roadmap is functioning beyond these two points, it’s a source of busywork rather than the key document in your project that it should be. The inherent issue is that all of the roadmapping tools have too much functionality. By letting you drag around colorful bars for hours, or add infinite detail to each and every piece of your product, these tools boast large feature sets while pushing product managers to stray down the rabbit hole. In a weird way, these tools prey on a product manager’s tendency towards organization by enabling them to over-organize.
Keeping on Track
So, what’s a roadmap’s purpose? Like I mentioned above, it’s foremost an important tool in a project manager’s belt to keep the project on track. It’s no secret that you won’t be able to calculate the time to your destination without a map. A roadmap let’s you plot your course. Depending on the product, a roadmap may cover a week, a month, a year, or even longer. It could outline broad strokes of functionality, or it can be detailed down to the feature. If you’re already organizing tickets properly in a tool like JIRA, getting too detailed in your roadmap will turn into busywork.
When deadlines are being hit, it’s probably okay to keep your roadmap high-level, outlining only big features, epics, or goalposts. If not, then perhaps it’s time to break down the reasons why. Maybe the roadmap made some bad assumptions, or maybe some other priorities came up that derailed the map emtirely. This leads us to the second purpose of a roadmap: to keep everyone on the same page.
Keeping Synced
In a typical company, lots of employees and divisions touch any given product. When sales asks me when they’ll be able to sell a certain ad placement, I like to say (politely), here’s a link to the roadmap. When engineers want to know how a certain feature ties into the future of the product, a properly-crafted roadmap will be able to answer their question. From executives on down, a roadmap should enable any employee or stakeholder to understand the why and how of the product’s future.
Beyond these two functions, the roadmap becomes a less effective tool. If engineers are going to the roadmap to understand their points for the sprint, then you probably have an issue with your ticketing process. If your roadmap is a good meter of work that should be done on a given day, then you’ve probably spent too much time adding detail. Roadmaps need to be flexible, because they absolutely will change, probably constantly. They’re molded from clay, not written in stone.
You should spend the most amount of time on a roadmap in the beginning, when you’re using the tool to align the product to the company’s/stakeholders’ vision. After that, if you’re spending more than an hour or two per week updating the roadmap, you’re adding too much detail.
