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:
The themes outline the solution approach, which is an opportunity to achieve a corresponding customer need or goal. It is important to make sure that not the feature is listed, but the actual goal that is to be achieved with it. For short-term periods you can consider listing the features additionally, but it should not complicate the roadmap or make it appear confusing.
E.g. stronger monitoring of the WebApp for proactive error management or display of individual information on possible similarities between customers.
The disclaimer protects all parties from false promises and expectations. If it is clear that the roadmap is only a direction that can and probably will change, then everyone has the chance to adjust to it.
All in all, this structure makes it possible to be transparent without getting lost in details and making promises that cannot be kept. The renunciation of announcing features, but instead goals, is essential here. Because it is quite likely to change, re-prioritize or delete a feature in the product work, while the goals are changed less often.
However, implementing such a roadmap will not be easy. There must be confidence among key stakeholders that this roadmap is not a cover-up attempt and that the product team will still deliver outcomes in the time periods mentioned.
Within a longer test period, the product manager can learn over time how best to fill and formulate the components, test this approach and see if it actually leads to less frustration in the end.
The product vision is the goal or the desired customer benefit that is to be achieved with this product. It should be present as a landmark in every roadmap and is not negotiable in the course of the roadmap.
E.g. “We want to provide with our agent platform the perfect service experience for our customers worldwide.”
The mapping to objectives makes it very clear which business goals the product or the prioritized themes contribute to, i.e. why the selected themes are on the roadmap. The number of objectives naturally depends on the size of the product and the team. If the company already works with OKRs, then it makes sense to use exactly the same objectives in the roadmap.
E.g. “ensure product quality” or “ensure a better matching between sellers and buyers”
Periods such as weeks, quarters or simply "now", "next" and "later" provide orientation while keeping flexibility. It shows what is focused on in the short term and what is basically planned but still has to wait.
It is also possible to combine rather specific short-term target dates with periods that subsequently become longer.