A category of articles I enjoy reading, are the ones describing the differences between “product roadmaps” and “product plans”/”release plans”/”backlog”. Even if they are entities we deal with regularly in software development, the range of definitions and explanations around them is irregularly big.
Last one that caught my eye was by Saeed Khan, a seasoned Product Manager, titled Product Roadmaps vs. Product Plans. It’s a very well written article explaining how the two concepts differ and how they relate to one another. It helped me crystalise some thoughts about Product Plans that I wanted to share here.
Users are more interested in the plan than in the roadmap
Product roadmaps are strategy documents aiming to align product organizations. For example, the public ProdPad roadmap is great for communicating intent and priority. Nevertheless, my experience is that users of a product are more interested to know if certain functionality is coming and by when. This is something that we can show in our product plan, since changes are we have defined at least some features we plan to deliver in the near future. Having a well maintained, easily understandable, concrete plan can provide the transparency the users need to calibrate their expectations about our product.
Making it easy to keep up with the plan
The hard truth is that our users don’t exist only to consume our newest features as soon as we release them. They probably have better things to do than waiting for our product plan to refresh with the newest updates. Enabling them to subscribe to items they are interested in or even to an entire release, keeps them informed and allows them try out the changes on their one pace. I find the GitHub public roadmap a good example for such opt-in notifications. We could even take this a step further and add the necessary release notes in the notification updates to give the users all the information they might need to get started.
Changes in the plan – handle with care
Sticking to a publicly announced plan that no longer serves the roadmap, is probably a bad idea. What we need to take care though, is how we communicate these changes. Why did they happen and what are the alternatives that will be pursued instead. People will generally give us the benefit of the doubt when we are honest and they get the feeling that we work for them, rather than disregard them and leave them in the dark. Long story short, not adding any updates on features that take longer than expected to implement or marking them as “irrelevant” with no further explanation is not a good look.
Bug fixes in the plan?- why not?
There are some bugs that are easy to fix but there are others that might take longer or even require a complete rework to get rid of. Communicating the intent to address a reported problem can serve us in at least two ways. First, to explain a delay in releasing new functionality and second, to build trust with our users communicating that we take their feedback into serious consideration. Not saying that bugs which are not in the Product Plan should be considered ignored, but for the ones that require bigger changes giving a transparency on the fix estimate can be a good idea.
In my experience, coming up with a meaningful product plan comes from having a focused, well-crafted roadmap. Once that plan is in place, it’s up to us to turn it into a communication tool to keep our users informed and gain their trust in our efforts to serve them.
More Questions Than Answers 