It is repeatedly demanded and often causes stress, pressure and disappointment in companies. And yet nobody wants to dispense with it.
The reasons are obvious: A roadmap provides structure and transparency, forces the product team and the company to plan, prioritize and coordinate with the stakeholders, shows the intention and direction of product development and can get stakeholders and users excited.
So why is there so often a discrepancy between intention and outcome?
Over and over again there are different demands and views on what a roadmap should achieve, and it is difficult to get them in line with each other.
It is normally the product manager / owner who creates the roadmap and thus defines the orientation and next steps of the product. Especially in an agile environment, the product is usually not defined in detail, but the priorities change at short notice and customer feedback is responded to. This can and should significantly influence the further development of the product. In addition, there are always technical barriers due to old technical debts or the use of unknown technologies. This makes it a challenge to create a plan with which the stakeholders can be aligned and not too much is promised.
Stakeholders have a legitimate interest in a roadmap, because they also want to plan for themselves or at least be up to date in order to influence the orientation and prioritization if necessary. They themselves have their own agenda and goals that do not necessarily correspond to the product manager's roadmap and can therefore, if they are not appropriately informed, block them instead of supporting them. In some cases, one of the stakeholders is so influential that the roadmap is more dictated by it than aligned with it.
Furthermore, stakeholders and users often would like to know often which feature can be expected at which time.
If the wishes or demands of the stakeholders and users would be completely met, then the product manager would just list the order of features and provide them with a date. Most of the communicated dates would then probably be missed, features would suddenly be changed or completely deleted and the direction of the product would change every few weeks. Users and stakeholders would be disappointed and lose confidence in the product team, while the product team cannot work independently and customer-centered and is always under enormous pressure.
C. Todd Lombardo, author of the O'Reilly book "Product Roadmaps Relaunched", presents a structure that I believe can be a solution in an agile environment. Because the focus is not on features and exact time periods, but on the outcomes that contribute to the vision and corporate goals and their prioritization.
The structure is as follows: