Product Roadmaps: Deterministic vs. Probabilistic
I have had a long love/hate relationship with product roadmaps. I have lost count of the number of times I have been beaten about the head with one of my roadmaps by someone who took it as the gospel in a presentation three months earlier even though it had changed and communicated numerous times. I do think roadmaps can offer value when used appropriately. By appropriately I mean the author communicates and the audience understands that roadmaps are:
- Fluid and subject to change
- Directionally accurate, but non-precise
- A communication tool about the current state of things vs. a set of commitments
With that said I think the authors of roadmaps bring some of the headaches on to themselves by not being clear as to how the tool should be interpreted with acknowledgement of that interpretation from the audience. Worse, the authors may not understand how to interpret the roadmap themselves. I think one of the biggest problems is that they build their roadmaps in a deterministic way rather than a probabilistic way.
By deterministic I mean there is one possible outcome for each item on the roadmap when in reality there are many possible outcomes for each of the items. Deterministic roadmaps present a very misleading picture. The audience looks at them and unless told otherwise assumes that the start and end dates are somewhere between a guarantee and a reasonable ball park idea. Below is an example of a very simple deterministic roadmap.
There are 6 epics with each epic having a dependency(could be implicit or explicit) on the previous epic. The total duration of the initiative is 150 days give or take. Very straight forward right? Now let’s look at the same initiative using a probabilistic roadmap.
The work is the same, but now we are taking the probability of the duration into account when determining when an epic will start and finish. The first thing to notice is that with each epic the range in which the epic will start and finish gets wider(blue line) with each epic because the variation is additive. If each of these epics is being done by the same team that may not be such a problem, but if there are other teams responsible for delivering some of these epics that is a bigger problem.
If you are trying to align priorities between teams based on when certain dependencies will be delivered then you need to ensure that the team provides enough slack to account for the range of possibilities for delivery of the epic on which they are dependent. If you were planning based on the first roadmap you would likely be setting yourself up for problems. This also presents a challenge for the stakeholders to might be making plans based on the roadmap.
The second thing to notice is the probabilities associated with completing each epic. The further down the roadmap you go the lower the probability of the epic being completed within the date range. The probability of a set of events all occurring is the the product of their individual probabilities. By the time you get to the last epic the probability is between 18% and 53%. I doubt many people would be telling their stakeholders that the odds of getting everything done by the given dates is at best the flip of a coin.
The probabilistic roadmap is not something I am necessarily suggesting you present to stakeholders. If you were to walk into a C-level meeting with something like this you might just get thrown out of the room :). I understand that roadmaps need to be relatively simple so they are easy for everyone to understand. What I am suggesting is that as someone responsible for planning and delivering products that you understand the gory details under the hood and then factor that into your simplified roadmap and how you go about communicating it.
Feedback either pro or con is always welcome!
