The loosely held product roadmap
In a recent article by Ryan Singer, Options, Not Roadmaps, he explains why he doesn’t use roadmaps - he uses options instead.
The use of a roadmap implies a set of features that will be developed in order. A decision is made at a point in time about the features to develop, how long they will take and the order they will be done.
At the beginning when the roadmap is made there is incomplete information. There is little knowledge of what will be involved or how the product/market will develop. So assumptions have to be made when not only defining the tasks but also the priorities. It does not take into account the fact there is uncertainty in how features will develop and their priorities may change. Tasks could take longer or the market could change and these will impact the roadmap.
The roadmap is presented to all the stakeholders and often set in stone. Once this happens it can be difficult to change.
A wider audience can make it more difficult to change as there is an expectation and possibly a series of dependencies. This is the reverse of the scenario where people are overcoming an addiction or taking on a new habit. In these cases they are encouraged to include a wider audience as a level of accountability. This wider accountability of the roadmap restricts the flexibility to adjust the tasks and the order they will happen.
He highlights that when implementing the roadmap there can also be a level of guilt in terms of having to do stuff that has been placed on it and putting off more important work. This will depend on the flexibility of how the roadmap is followed.
He proposes the idea of options as features that may or may not be implemented but the decision is made one cycle at a time. This leads to a level of flexibility in that the most important option can be selected when there is the most relevant information. This implies that you can always pick up the most important/relevant task each time.
I think the ability to pick options over a roadmap is dependent on the product being developed and the stage it is at. If the product is relatively mature and the options are short and easily defined then there is more scope for following this approach. If the features are larger and have dependencies outside those developing the features then the flexibility is reduced.
I think there is an opportunity to get the best of both worlds by defining roadmaps but holding them loosely and making sure all the stakeholders understand that it gets regularly reviewed and is expected to change. Regular reviews and an expectation of change can benefit all involved as the stakeholders know that if things change then the features they are dependent on have the opportunity to move up the roadmap and be delivered earlier.
The company I work for has just defined a roadmap for the next twelve months. This will give us some direction and focus - something we have been lacking until now. However I completely expect it to change and there is an expectation amongst all involved that when we look back in a years time we will see a significantly different path to the roadmap we have in place now.
Links