Why everybody loves to bitch about roadmaps
This post was originally published on my newsletter which delivers the best content to build better products to you. If you’d like to get these in your inbox sign up here.
Recently, I shared an article called ‘Why roadmaps are a waste of time’ and while I was certain that this catchy title would make for lots of interest, I wasn’t prepared. Apparently, most of the people within my bubble seem to resonate with the pain of creating time-based roadmaps a lot.
This impression was amplified when I mocked the job description for a product owner role which included ‘creating and managing roadmaps’ 3-times.
Tons of people jumped on this and agreed with my interpretation of this position primarily being a “stakeholder pleaser” instead of focussing on user value.
So, why does everybody love to complain about roadmaps? I think it’s due to the weird situation roadmaps are caught in between:
Time-based roadmaps originated from upper management wanting to know when something will be done. With little to none wiggle-room compared to the reality of maintaining existing stuff and the other complications building software brings with it.
On the other hand, there’s also a bottom-up demand for roadmaps. “We want to know what’s on the roadmap for the next year” is a common phrase you can expect from team members more than once. I found this question to be raised more frequently when you failed to embrace a framework like OKR which can help you translate a vision and strategy into tangible tasks.
After all, the main motivation for demanding roadmaps is the perceived security and seemingly improved certainty for most people. By neatly laying-out what’s ‘exactly’ the plan to build on one by one over the course of the next twelve months, we like to believe that this is how it’s going to play out.
So, time-based roadmaps are effectively covering up the messy day to day business of building digital products and are therefore so desirable for a lot of stakeholders and team members.
One way out of this trap? Embrace the uncertainty instead of covering it up!
Here are two approaches I can personally recommend for escaping the Gantt chart trap: Theme-based roadmaps and 6-week planning cycles.
The concept of theme-based roadmaps has been refined and popularized by the team at ProdPad and its CEO Janna Bastow in particular.
Personally, I like to add a rough quarterly time box to the mix for providing a clear focus.
6-week planning cycles is a concept which is currently used by prominent examples like basecamp, Buffer or Postmark.
The simplicity and reduced planning around the Six Week Cycle concept is a good fit for organizations of any size, as long as you’re ok with embracing the unknown.
My highlight of this concept is the time box to restrict overengineering and getting lost in pixel dust. Working with any alignment document (mission briefing, intermission, etc.) is a neat addition for setting and checking the outcome of an upcoming cycle.
If you’re suffering from time-based roadmaps as well, I hope you find a way out of this madness by embracing one or both of these alternative approaches.
What has your experience been embracing uncertainty in product development over waterfall-ish Gantt charts?
