The product roadmap is an important debate in the software industry. Brad Dunn (2018) said, "Your road maps are snapshots in time in this world. Where you were and what you were thinking at the time. Therefore, creating it is a waste of time as it usually does not match to what was built.” Now, these questions arise, why does the product roadmap not work? And why do we need it at all?
You should know that a Scrum team is not the only one dealing with the product roadmap. There are different audiences for the roadmap, and the definition of the roadmap may vary across the various groups of audiences you work with. For example, the definition of a roadmap for the salesperson might be a guarantee of exactly when it will be delivered.
But, for the engineers, there might be a plan to clarify development priorities, identify the ability to perform work in the time frame and determine the allocation of future resources. Different audiences' expectations of the roadmap cause friction, which eventually results in its failure.
Additionally, the use of Feature-Date Driven Product Roadmap (FDPR) is widespread in non-agile IT firms. The different audiences of the roadmap have different features in mind and are pushing for it. Hence, it is believed that FDPR brings a level of certainty to them, but ultimately it leads to failure with negative consequences.
Let's take an in-depth look at FDPR to understand why it fails. As shown in Figure A, FDPR maps the time vs. things to do. In fact, it contains a set of features with due dates, just all based on following false assumptions:
Figure A: feature-date driven roadmap
The development team is aware of the time required for each feature. As a result, it is expected that the complex and unknown features break down upfront and be given a precise time estimate.
Assuming nothing can interfere with your plan (i.e. There are no new changes in the market, no new competitors, no new ideas from customers, and no need for iteration), thus the fixed roadmap is closed.
Each feature works as soon as it is launched.
The features must definitely exist.
This kind of roadmap ends up with a deceptive timeline, made-up release date, a stressful environment to build software, instilling unrealistic expectations, frustrating customers, losing market opportunities, and increasing the probability of building the wrong things.
Moreover, it creates a vicious cycle that can be hard to get out of. Since no one wants to miss a deadline, large buffers are given, and scope expands to fill the time in that buffer, resulting in what is called Parkinson's Law.
Consequently, there is no room for any discovery, rework, building in quality, or refactoring. The wrong things get built, and the problems are not solved; quality suffers and ultimately leads to blame culture.
Now, what benefits should be gained from the product roadmap?
R.Pichler (2022) defined the product roadmap as a strategic, high-level plan to communicate how a product is likely to evolve. J.Bastow (2022) said, “A road map is a tool that helps you to learn and iterate, at the product strategy level. It is a prototype for the product strategy”.
I like both definitions, but to me, a roadmap is a living guidance rather than a plan set in stone. It should communicate the "why" behind what you're building. In addition, it needs to tie back to the business strategy for the company and convey the strategic direction for your product.
As depicted in Figure B, the roadmap is a bridge that connects business and tactical strategies. It degrades the level of abstraction and makes you close to the tactics.
Figure B: the level of detail and timing of implementation for a roadmap
G.Adzic (2014) likened the roadmap plan to the map of roads, which must have the following attributes:
a) Variation, b) Survivability, and c) Selection.
Variation means the plan should seek new ideas and try new things rather than doing everything in a plan. It should offer different options to choose from.
Survivability means doing it on a scale where failure is survivable. In other words, if something turns out to be a bad idea or blocker, it is replaced by another option.
Selection means seeking out feedback to understand whether we are getting closer to the destination or not and learning from mistakes.
Anybody can create roadmaps, but creating effective, lightweight roadmaps requires agile governance and a willingness to allow teams to own their work. The effective product roadmap should:
Describe an ambitious, specific, and transparent vision and strategy.
Provide the continuity of purpose.
Focus on specific, measurable, and attainable goals.
Help with prioritization of goals.
Facilitate the budget acquisition.
Communicate progress and status of product development.
Direct and unburdens the product backlog.
Now, the following inquiries must be addressed in order to have an effective roadmap:
What ought to be in an effective product roadmap?
How should the roadmap be communicated?
Question A. What ought to be in an effective product roadmap?
We require the product strategy as input to comprehend the business objectives, customer needs, and market before establishing the product roadmap. J.Münch (2020) used the most popular names to categorize and analyze the existing roadmaps in order to identify the key elements. Other roadmaps, excluding FDPR, are divided into three categories:
a) Goal-oriented, b) Outcome-driven, and c) Theme-based.
These categories put the emphasis on achieving goals, which causes the conversation to change from debating features to agreeing on goals. The outcome-driven and theme-based roadmaps provide an additional level of aggregation, as seen in Figure C. The details and context of the roadmap may vary, but it may include the following key elements:
Product Vision: The vision states the overarching goal, the ultimate reason for creating the product and the positive change the product will bring about. A strong product vision captures who your customers are, and how you will go to market with your offering.
Theme: Theme is a global outcome to be achieved, also traceable to the strategic business objectives. This outcome may span over several months or years to complete.
Time Horizon: It is good to review the state of the roadmap over time. You can use different levels of time horizon specificity as a guideline rather than an actual timeline. This guide will help you to focus on the scope in front of you while keeping an eye on future problems. Here is different levels of time horizon specificity:
High: January, February, March, April …
Medium: Q1 2022, Q2 2022, H2 2022, H12023,H2 2023
Low: Now, Next , Later
Figure C: different goal-oriented roadmap templates
Goal: Goals are measurable, time-bound objectives with clearly defined success metrics. They show the critical milestones that must be accomplished to make the product vision a reality. Moreover, goals should be less detailed and clear. However, they have different levels of abstraction; these levels are high, medium, low. Here is an example of a goal with three different levels of abstraction:
High: Real-time biometric monitoring via micro sensor-embedded shirt.
Medium: Real-time health monitoring via biometrics for improved data accuracy.
Low: Ability to monitor health status.
Impact: It is the change in customer behavior that affects the business success.
Metric: Product metrics are measurable data points that a business tracks and analyzes to measure the success of its product.
Output: The outputs are initiatives or anything that the team delivers.
In order to meet your needs, you can supplement the roadmap with additional information. For example:
Categorized items: It is good to group items into appropriate categories to better communicate with the audiences. This classification can be done based on benefits, problems or needs, different market segment, persona, aspect of product, product, technology, etc.
Release: The product releases or major milestones can be aligned with your strategy.
At the end, the big story of your product should be broken into chapters for easier reading. The Swimlanes in the roadmap break it down, so you can see better what can be pivoted on themes.
Question B. How should the roadmap be communicated?
The product owner is responsible for the roadmap, but even the best-prepared roadmap is useless if it is not understood by other audiences (key stakeholders, the development team, etc.).
The audience's perspective on the roadmap enables them to learn ideas, and understand concerns. Moreover, the product owner ensures consensus regarding the goals, which eventually results in roadmap support. Therefore, an effective roadmap should be created collaboratively.
The important challenge is how to create a roadmap that reveals business opportunities, defines options and compares different solutions while engaging all audiences.
As shown in Figure D, Impact maps (Gojko, 2014), Opportunity solution tree (Torres, 2022), and GIST Framework (Goals, Ideas, Steps and Tasks) (Gilad, 2022) are the methods that can be used to overcome the aforementioned challenge.
These methods use a tree-like structure to connect each goal to multiple ideas. They show how the deliverable scope relates to the business goals and the underlying assumptions.
Figure D: different tree structure techniques
Final Thoughts
Creating a roadmap is challenging when there are frequent and unexpected changes. As a result, before creating the roadmap, the audience requests' turmoil needs to be under control. It is impossible to have an effective roadmap without identifying the vision and strategy, without understanding why and for whom the roadmap is being built, and without being in alignment with the stakeholders.
The product manager should determine the “right” things to build. As a result, it's crucial to incorporate product discovery activities into the roadmapping process to guarantee that the final products satisfy the needs of the target customers. Moreover, the roadmap process is iterative, and communication must be a part of each phase.
It's not as if you create your roadmap, share it with others, and then execute your plans all at once. You must collaborate with the different audiences to establish a roadmap.
A goal-oriented product roadmap is essential when working in an agile context because it helps you move the conversation from arguing features to settling on values and goals.
Additionally, this approach should enable you to track the growth of your product through goals.
So, start by dividing the product strategy's business goals into smaller, more manageable objectives.
Those objectives should be arranged in a logical manner to make a tale. Every goal should be detailed and measurable when adopting a goal-oriented roadmap so you can determine whether you've achieved it or not.
Moreover, in order to appease influential stakeholders, do not simply succumb to the urge to add objectives or features to the product roadmap. Keep your road map straightforward and easy to follow. Never display epics or user stories on your product roadmap.
Furthermore, prioritizing the items that go on your product roadmap is vital. At the end, depending on how mature your product is and how dynamic the market is, evaluate and revise your product roadmap frequently from a month to every three months.
Bibliography
Bastow, J. (2022, 08 10). What is a product roadmap? Retrieved from https://twitter.com/simplybastow/status/1168531748751388679?lang=en
Dunn, B. (2018, 5 22). Why roadmaps are a waste of time. Retrieved from https://productcoalition.com/why-roadmaps-are-a-waste-of-time-edb2dab61457
Gilad, I. (2022). Why you should stop using product roadmaps and try the GIST Framework. Retrieved from https://itamargilad.com/gist-framework/
Gojko, A. (2014, 10 15). Fifty Quick Ideas to Improve Your User Stories.
Jürgen Münch,Stefan Trieflinger, Bastian Roling, Patrick Eißler. (2020). Product Roadmap Formats for an Uncertain Future: A Gray Literature Review. researchgate , 8.
Pichler, R. (2022, 04 28). 10 TIPS FOR CREATING AN AGILE PRODUCT ROADMAP. Retrieved from https://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/
Torres, T. (2022). Opportunity Solution Trees: Visualize Your Thinking. Retrieved from https://www.producttalk.org/opportunity-solution-tree/
Behzad Nazarbakhsh
Read also
Build great roadmaps
