What’s a product roadmap? After a quick search on the web I found what I believe is a good definition.
“A product roadmap is a tool that provides a strategic guidance to team members, business partners and customers. Just as a map of a city helps you reach your destination, product roadmaps provide organizations with a plan to shape and define their product’s vision.” Source OneDesk
A Product roadmap is not bad in itself, but abusing it’s meaning and usage can create massive amount of waste and sometimes kill the product it is meant to describe. I am going to list 2 concrete examples of how abusing a product roadmap can kill a product.
Example 1: Static product roadmaps
If you think about a real roadmap, you think about something that changes with low frequency, in fact we don’t build new roads every day. Comparing today’s roadmap of Rome with one that is 10 years old we probably would find some inconsistencies due to some new roads, extra buildings, etc. Using the 10 year old map today might be difficult but very likely we would still be able to get around. On the other hand if we use a 2000 years old roadmap of Rome today, we would be definitely in trouble. Besides being able to go to the Roman Forums that still exist today, we would have very little use for it and we would get lost for sure.
Product roadmaps work more or less the same way, with the difference that the frequency of change in features (rather than roads and buildings) is much higher. In my experience I can compare what changed in the roadmap of Rome in 2000 years to what can change on a product roadmap in one single year. If we are aware of this, then we understand that creating a static product roadmap and sticking to it is a waste of time. Why create something that we know very soon won’t reflect reality and use it as a map for our day to day real world decisions? Would you use Rome imperial map for your next trip to the Eternal City? I bet you wouldn’t, but yet most of us accept that we need to use a product roadmap for our day to day prioritisation decisions.
The waste with static product roadmaps is twofold. Not only we waste time creating a roadmap, but in some cases we waste huge amount of time and money in defining the various steps of the roadmap in advance. I’m sure you heard things like “Phase 1 is still in progress, but we must start writing the requirements and specifications for phase 3 of project XYZ!” This is what I like to call meta waste, i.e. wasteful activity built on wasteful artifact.
Dumb Unaware product roadmaps
Roadmaps sometimes become less effective when we are trying to go somewhere, we choose the shortest route and we find out that minutes ago an accident caused bumper to bumper traffic. If we knew that traffic was so bad on that route, we would have picked the longer route with no traffic, but we didn’t know. Now we have more information than when we started the trip and can make the decision of reversing and choosing the longest but fastest route. Simple, right?
Believe it or not, I have seen product roadmaps misused to the point that reality is ignored and no matter how bad the traffic, the product direction doesn’t change. In one occasion, I worked on a product, designed to make lending money to customers easier, that started at the height of the housing boom. When in 2008 the economic crisis hit Ireland hard, we had 2 more years product roadmap wastefully laid out and meta wastefully designed in detail in front of us. Management decided that evaluating the new economic outlook and redrawing a new product strategy was not the way to go and stuck to the reassuring product roadmap. I let you guess the consequences on the product and on the company.
The above is an extreme example, but less dramatic examples happen continuously generating incredible amounts of meta wasteful work. Product roadmaps are based on people’s assumptions at a certain time. When we don’t use customers feedback to validate or disprove our assumptions we are running blindfolded carrying a pair of sharp scissors. Sooner or later we are going to have a problem, maybe fall off a cliff and when (assuming we are lucky and still alive) we take the blindfolds off we are surprised by how we got where we are.
How can we avoid this?
1. Shorten your roadmap
As mentioned above, product roadmaps are not bad per se, the problems lie in their usage. If you have to work and live with a product roadmap, I suggest you avoid as much as possible to spend time working, refining, grooming the items that are scheduled far in the future. Ideally you are able to plan Just In Time, but if Just In Time doesn’t work for you, try to reduce the future work as much as possible. As a rule of thumb, I would never do any work for something scheduled to happen 2 or more months from now. Eliminate all the meetings that get called on products and features outside the next 2 months. If people complain point them to this blog post to explain your reasons. The great thing is that the world won’t implode, you won’t get fired, your company won’t fail and actually you will not notice any difference, with the added benefit that you have avoided wasteful work for yourself and your team. Try 2 months to start, if you are already doing 2 months try to shorten down to 1 month. I like to work with a maximum of 2 weeks work in the future, the world never imploded for me either.
2. Quantify Waste and compare to missed opportunities
If you are dealing with management that want to follow the product roadmap no matter what and force people to work months in advance you can try by explaining the reasons in this post first, if they don’t budge try the following: when working on something that according to the product roadmap will happen 3 or more months in the future, log all the time you and your team spend on it. When the item gets cancelled or de-prioritised into oblivion, send your boss all the artefacts that your team have created (diagrams, specs, requirements, wikis, code, etc) plus the report of the time your team has spent on that item. Using a feature you are currently releasing, map how earlier it could have been delivered if your efforts were focused on it instead than on the deceased item. Example: “If we didn’t have to work on feature X that we eventually will never do, we could have released feature Y last week instead of next week and we could be realising the profits of it already”.
3. Always be aware
Your ability to adapt and react will depend on you being available to work on changing needs, customer feedback, competitors moves and economic changing conditions.
Constantly validate assumptions by using customers feedback, practice deliberate discovery to reduce guessing. Listen to Eric Ries “Build Measure Learn”. Deviate from the product roadmap before falling off the cliff.
When you become good at this you will be able to use customer feedback, moving targets, changing conditions and requirements as your real time always up to date roadmap to successful products.
P.S. Please don’t confuse a product roadmap with a vision. A vision is necessary, a vision is a point of arrival, not a roadmap.
Product roadmap waste index:
Epidemic: 80% – Product roadmaps are quite widespread and most of the organization I have witnessed display some level of roadmap abuse. People find comfort in having a roadmap to follow, this make the product roadmap very popular.
Damaging: 95% – Creating product roadmaps is a wasteful activity but it doesn’t take in itself a lot of time. The problem starts when large amount of work are done on parts of the roadmap far in the future. Chances are that either that work is never used because the company changes priority or in the worst case scenario, the work is completed regardless of the changing conditions.
Resistant: 65% – Product roadmaps are considered by some schools of thought as best practice hence difficult to dismantle from that point of view. On the other hand, explaining how they can be damaging is a simple task and if an organization is willing to learn, it will lose the roadmaps quite easily.
Lean Software development – An Agile Toolkit (Mary and Tom Poppendieck)
The lean Startup (Eric Ries)