Why Feature-Driven Product Roadmaps Fail in the Digital World
You are asking a big software company for a specific feature, and they tell you they have it on the roadmap for next year. What is your reaction? Honestly, most times, your first reaction is to think that this means you will never receive the feature, and you will start to build a workaround. At least, from my experience, that usually holds true, but why is that the case? A short introduction to the pitfalls of roadmapping.
Over the years, I have worked for several companies from different industry domains with various digital products. In this context, one thing, in particular, caught my eye: It seems that companies operating in the digital world are increasingly struggling to create reliable product roadmaps. This opens the question of the reasons for the failure of product roadmapping in volatile environments and how companies can switch to a new approach. I, therefore, decided to address this problem in my dissertation and developed various tools with Dominic Lang and Jürgen Münch to tackle it.
First of all, before making any conclusions or suggestions, we studied which product roadmapping approach software-intensive companies are currently using. To find this out, we conducted an interview study with several German companies and an analysis of the grey literature. The results show that the most common approach is a traditional format with a fixed time-based chart containing detailed products or features over a long time horizon. This roadmap format is usually referred to as feature-driven product roadmaps. The purpose of such roadmaps is to inform stakeholders at which point in time a product is ready for market launch. Below, you will find an example of such a feature-driven product roadmap.
Feature-driven product roadmaps aim to inform stakeholders at which point in time a product is ready for market launch. However, in a dynamic market environment with associated uncertainties, it is almost impossible to predict which products, features, or services will satisfy customers’ needs, especially in the mid and long term. Therefore, feature-driven product roadmaps work well in market environments that are predictable, stable, and reliable. Consequently, several problems arise when using feature-driven product roadmaps in a dynamic and uncertain market environment. I will discuss these problems in detail below.
Common Problems with Product Roadmaps
Feature-Driven Mindset: As mentioned, product roadmaps often consist of features, including exact delivery dates, on a timeline over a long-time horizon, e.g., more than one year in advance. However, such detailed feature planning upfront does not work in a dynamic and uncertain market environment. Some of the reasons for this are the emergence of new technologies, rapidly changing customer behavior, and less predictability of markets and demands. Therefore, features estimated beyond the next release tend to change as new risks or dependencies are uncovered. Therefore, feature-driven product roadmaps are usually often subject to frequent adjustments. These adjustments are associated with a high effort since all the features that have been worked out in detail, including their associated responsibilities, must be rescheduled. Moreover, frequent ad-hoc adjustments decrease the reliability of the roadmap, and nobody considers the roadmap as a trusted planning tool. Another problem with feature-driven product roadmaps is that when customers or stakeholders see a feature to be delivered on a specific date in the product roadmap, they will interpret this as commitment, and expectations are raised. However, the uncertainty that comes with developing products in a dynamic market environment makes it very likely that features will not be delivered as planned and communicated. This applies particularly to features planned for the mid and long-term in the product roadmap and leads to the circumstance that customers or stakeholders perceive the non-delivery as a broken promise and are disappointed and dissatisfied. Last but not least, feature-driven roadmaps consider features, but they do not include the value to be delivered to the customer. This leads to the problem that the features planned might not contribute to the solution of customer problems and are therefore not bought or used by customers.
Too many details in the product roadmap: Another problem is the inclusion of too many details in the product roadmap. This means, for example, very detailed descriptions of user stories, requirements, or resources. The main reason for including too many details in the product roadmap is that product managers feel obliged to include the wishes of every stakeholder in the product roadmap. However, including too many details blurs recognition of the strategy to achieve a company’s product vision. This causes the product roadmap to be understood by all stakeholders, leading to misunderstanding and a decrease in the execution of the product strategy. In addition, if the underlying reason for conducting the planned product development in the roadmap is buried under details, it will be difficult to generate enthusiasm and excitement among the employees.
Individual opinions decide which items will be included in the product roadmap: In many companies’ management or experts (e.g., product managers, product owners, etc.) decide which items to place on the product roadmap. The problem with this approach is that only individual opinions determine the product roadmap’s content, but the customers’ perspectives are not included. This approach can lead to the development of products based on false assumptions and use cases. In the worst case, this can lead to the team members feeling unappreciated and losing their commitment to the company.
Not reviewing and updating the roadmap: Furthermore, several authors point out that creating the product roadmap is seen as a one-time activity rather than a continuous process. This means that companies often create and work on their product roadmap at the beginning of the year and use it as a fixed document with no further changes. However, the problem is that priorities, resources, budget, and external factors such as competitors or major customers can change at any time, affecting the content of the product roadmap. Therefore, it is crucial to continuously review and update the product roadmap at a short time interval (e.g., every week or as a cadence of stakeholder meetings takes place). Otherwise, the company forgoes the opportunity to incorporate findings into the product development process after the product roadmap is created.
Lack of an enterprise-wide known product vision: Many companies do not have a product vision or have a product vision but never use it. The danger of not having or communicating a product vision is that the teams involved in product development are unclear about the overall goal of developing the planned products in the product roadmap. First, this situation makes it difficult for the teams to identify and prioritize measures contributing to product success. Consequently, the teams will be unable to identify which measure contributes most to achieving the product vision and will struggle to prioritize various measures.
Identification and implementation of customer feedback channels: Another problem is that companies often struggle to identify and implement data collection channels for customer feedback. One reason for this is that product managers often stay in their offices and do not leave the building to talk to (potential) customers. Another reason is that in the race to meet deadlines, product teams do not have enough time and resources to devote to identifying customer feedback channels. The risk of not involving customer feedback in the product roadmapping process is that the development of the product roadmap will be based on assumptions without validation. As a result, products that do not bring about the intended change in customer behavior may be included in the product roadmap and developed. Consequently, these products will not succeed on the market.
Unrealistic Expectations: Another pitfall is to make unrealistic and arbitrary expectations on the roadmap. Setting unrealistic expectations can originate from various sources, for example, from management to the operational level but also from product management to software development. Such behavior will generally damage the relationship between the expectation setter and recipient. A typical example of the setting of unrealistic expectations is the specification of non-realistic release dates.
Lack of criteria for the conduction of the product roadmap prioritization process: Moreover, product managers often prioritize their roadmap items based on individual opinions. This includes views of the management or various members of the product team as well as customer requests. However, this includes the pitfall that subjective opinions are often influenced by personal bias and often present only a single point of view. Therefore, there is a low probability that these opinions reflect the most important current customer problems and are, consequently, inappropriate for application in the prioritization process of the product roadmap.
Creation of a single product roadmap for all stakeholders: A common mistake is to create a single product roadmap. The problem with this approach is that a product roadmap is an artifact that needs to be reviewed by many stakeholders, such as the CEO, CPO, marketing, sales engineering, and customers. This means that the information that is focused on and emphasized should be tailored to the stakeholder to whom the product roadmap is presented. Therefore, creating a single roadmap will not be sufficient for informing and collecting feedback from these stakeholders.
Let’s talk about solutions to these problems
Do these problems sound familiar to you? Over the next few weeks, I will present our holistic approach that enables you to transform your product roadmap to the requirements of a dynamic and uncertain market environment. Let´s stay in touch — Follow me and leave a comment.
What´s coming next?
In the next blog, I will present a tool that enables you to assess your current product roadmapping capabilities. The results of this assessment help you to identify improvement potentials and pave the way to switch to an outcome-driven product roadmapping approach.
References
Stefan Trieflinger, Jürgen Münch and Dominic Lang. “Why Traditional product roadmaps fail in dynamic markets: global insights.” International Conference on Product-Focused Software Process Improvement. Cham: Springer International Publishing, 2022.
Stefan Trieflinger, Jürgen Münch and Dominic Lang. “What’s Hot in Product Roadmapping? Key Practices and Success Factors.” Product-Focused Software Process Improvement: 20th International Conference, PROFES 2019, Barcelona, Spain, November 27–29, 2019, Proceedings 20. Springer International Publishing, 2019.
Stefan Trieflinger, Jürgen Münch and Dominic Lang.“Why Feature-Based Roadmaps Fail in Rapidly Changing Markets: A Qualitative Survey.” Software-intensive business: start-ups, ecosystems and platforms: proceedings of the International Workshop on Software-intensive Business: Start-ups, Ecosystems and Platforms (SiBW 2018): Espoo, Finland, December 3, 2018.-(CEUR workshop proceedings; 2305). RWTH Aachen, 2018.
