What makes a good roadmap? More is always better! More milestones, more details, more predictions. That was my naive approach to creating roadmaps for a while. I didn’t realise how counterproductive most of that was. A tweet from Janna Bastow last year inspired me to question my simplistic concepts.
Why we need better roadmaps
Today’s roadmaps largely come in the form of timelines. They are a sequence of milestones or features which happen one after the other. A variant of this are Gantt charts which promise to illustrate dependencies better. Here is a simplified visual example of this:
Roadmaps are supposed to give a strategic overview of goals over time. However, in reality they often can’t deliver what they promise.
Conventional roadmaps make too many assumptions
Traditional timeline roadmaps are so widespread that we rarely question the validity of this format. But there are numerous issues with them which mostly stem from making too many assumptions.
Ego and politics
Who are you creating your roadmaps for? Often they are used to signal to people above and below in the hierarchy that things are under control because we have a plan. How many plans have you made last year which did play out exactly the way you thought?
You might think planning development well ahead is being thorough. You want people to know you’re capable and in control. But in reality it is naive – if not arrogant – to believe that you already have all the information to decide which feature is best built in a few months. These decisions don’t even have to be made right now.
Let’s play that through an example: Imagine you’re an aspiring product manager at Netflix. Your next big bet to increase user’s session time is to serve them great recommendations. You plop that smart recommendation engine on your roadmap. You’re convinced the users will also want to refine the recommendations. So the next feature to go on your roadmap are customisable recommendations.
Now if your first take of the recommendation engine doesn’t meet expectations you have to own it and communicate a delay of the customisable recommendations. You suddenly have to sell an important learning as a failure and officially announce a delay. You have nothing to gain by representing your development efforts like that.
Hiding uncertainty
The future holds a lot of uncertainty for all of us. Or did your roadmap leave room for a pandemic? Of course there are less impactful, more common disruptions to your product. They can range from new competitors popping up to regulations changing.
Do not hide such uncertainty behind overspecified roadmaps. Instead be transparent about it. Only then will you be able to quickly adapt to new opportunities when they arise.
Let’s think back to the recommendation engine. Your plan was to work on customisable recommendations next. But then Covid happened. Instead of having a predefined algorithm throw out recommendations and users customising them you now want curated content to be pushed to users by the Netflix content team. How else would people quickly discover your latest pandemic (or tiger) documentaries otherwise? Your customisable recommendations have now been replaced by curated recommendations. Tada, you’re the fool again with your assumptions deeply baked into your roadmap.
Spreading misinformation
The more detail you add the more misinformation you’re spreading. Being able to pinpoint a release data which is months (or quarters) away is unrealistic. Estimates themselves are a problem. Your roadmap is essentially outdated and wrong before the ink is dry.
Back to our Netflix example. As an industry leading company you want to be as transparent as possible. Your social media team goes on to tell people who hate on your recommendations that they’ll soon be able to filter out those crappy Peppa pig recommendations they’re getting because their toddler got a hold of their tablet once. How will you tell those already frustrated customers that they’ll have to wait a bit longer because you now deem it more important to push some other feature which will net you more money in the long run? You’ve not only fooled yourself but the people who trusted your roadmap as well.
Output over outcome
Typical roadmaps are glorified To-do lists. They focus on what you will do and how terribly busy your team is. But you should care less about the output and much more about the impact your changes are having.
What if what you deliver is done by all means but the impact has not been achieved? Do you leave the feature dead in the water or do you reiterate until it’s right? The first take of a feature rarely just works. You have to take a step back, check assumptions and adapt the feature accordingly. If you’re missing this step you’re running an ineffective feature factory.
Timeline roadmaps are outdated
The time for timeline roadmaps has come. Conventional timeline roadmaps make too many assumptions. They hide uncertainty and focus on output rather than outcomes. This leaves your product development vulnerable to changing circumstances. You can avoid these mistakes with a lean roadmap. My follow-up article on how to craft a lean roadmap goes into detail on this topic.