Managers want to make sure that everybody knows what the top priority is.
I can totally share this need as it is crucial to know what is currently important. The first reflex is often to create a roadmap, which contains the most important projects of the future in a particular order. But a product roadmap does not only address the goal to know what is important now, but also what will be important after the first item and even what will be important in a couple of months.
Additionally, to knowing what will be important in the future you also plan how to solve the problems of the future with your current knowledge. This suggest that you do not only have an idea what will be important in a couple of weeks but also how to tackle the problems of the future as classical roadmaps do not address the upcoming challenges but solutions instead.
The problem of planning solutions ahead is that you cannot be sure that these solutions really match the problem. Hence with finishing the roadmap item you can totally celebrate releasing it, but you have no idea which problem is solved now. Without knowing which problem has been solved you cannot be sure that you have created any value. I prefer knowing the problem to solve instead of having a solution.
Instead of using a roadmap full of assumptions of solutions, the better idea would be to have a roadmap full of problems you want to solve in the future. This way you can make sure everybody can focus on solving the most urgent problem.
In his must-read book “Inspired” Marty Cagan says that such an outcome-based roadmap is “is all about solving problems, not implementing features” [1].
An outcome-based roadmap does not state the next feature to implement but the next problem to solve. This way you do not only create real value, but you also have a possibility to measure your progress. Instead of measuring the delivery and accept upcoming work to get the feature to its full potential, you can be sure to deliver value from the very start.
Hence instead of planning to have a newly styled onboarding page you should rather plan to achieve an increase of new customers, more customer satisfaction in the onboarding or easier onboarding for people with disabilities. That gives you and your team the chance to achieve the goal in the most propriate way and the most suitable technology available. Furthermore, you can easy check if the implementation you have chosen did have any impact on your goal. Instead of celebrating the release of a feature you can celebrate the increase of new customers. Which goal looks more valuable to you?
In the phase of transition, it is tough to move from a classical project roadmap to an outcome-based roadmap in just one big step. But if you are looking for a low hanging fruit to the approach you can easily write down the purpose for any planned roadmap item. You can then use the known planning approach of a classical roadmap with additional goals to achieve and move slowly to an outcome-based roadmap.
One of the key benefits of an outcome-based roadmap is that it helps to align the product development efforts with the overall business goals and strategies. By focusing on the desired outcomes, teams can make sure that they are working on the most important and impactful areas of the product. It can also help to ensure that resources are being used effectively and efficiently to achieve the desired outcomes.
Additionally, it gives everybody on the company to fully understand why their work has an impact to the overall goal.
[1] Marty Cagan, INSPIRED: How to Create Tech Products Customers Love