When You Should NOT Use a Product Roadmap
The product roadmap is a popular product management tool that communicates how a product is likely to evolve. But despite its popularity, it’s not always applicable. In this article, I share three scenarios in which using a roadmap is not advisable. I explain why not using a roadmap is the right course of action, what you can do instead to plan ahead, and which steps you can take to get closer to developing a realistic, actionable roadmap.
🎧 You can listen to the audio version of this article on my podcast.
You Can’t See Further than the Next Three Months
A product roadmap should be a realistic forecast that states the specific value a product is likely to offer in the next 12 months.[1] Creating such a forecast is not always feasible, especially when you work on a new, innovative product.
If you can’t see further than the next three months, then do not use a product roadmap. Otherwise, your plan is likely to be wrong, which would lead to disappointed stakeholders and development teams.[2] In the worst case, they’ll lose trust in your ability to guide them.
Instead of building a roadmap, set a single, outcome-based goal for the next three months. The goal should state the positive impact you want to create for the users/customers and the business. An example for a healthy-eating product might be “help the users understand their eating habits and acquire an initial user base.” Use the goal to determine which features have to be implemented to create the desired outcome, for example, offering a healthy-eating dashboard and seamless integration with leading smartwatches. A practical way to do this is to focus the product backlog on the goal you’ve chosen.
Once you have achieved the goal, you will hopefully better understand how you can progress your product and be able to create a realistic roadmap.[3] If that’s not the case, check that you have a validated product strategy, on which you can base the roadmap.
You Lack a Validated Product Strategy
A common cause of teams struggling to create a realistic product roadmap is a lack of a validated product strategy. Before I explain what I mean by validated, let me briefly describe what a product strategy is.
A product strategy describes the approach you’ve chosen to achieve product success. It states the target group — the users and customers, their needs, the desired business goals, and the capabilities that will set the product apart from competing offerings.[4] A handy tool to capture the strategy is my Product Vision Board, which you can download for free together with a helpful checklist from my website.
A validated strategy is free of significant risks and assumptions. It is backed up by empirical evidence: You have relevant data to show that you have made the right strategic decisions and selected the right target group, needs, business goals, and standout features. Executing the strategy is therefore likely to result in a successful product.
A great way to validate a product strategy is to follow an iterative, four-step process. As I explain this approach in more detail in the article Product Strategy Discovery, I’ll just provide an overview here.
Start by selecting the biggest risk contained in the strategy — the uncertainty that must be addressed now so that you don’t make the wrong decisions and take the product down the wrong path. Second, determine how you can best address the risk you’ve chosen, for instance, by observing target users or building throwaway prototypes. Third, carry out the necessary work and collect the relevant data. Fourth, evaluate the results and use the newly gained insights to decide how to correct and refine the strategy. Follow this process until you’ve addressed all major risks.
With a validated strategy in place, you are in a great position to build a realistic, actionable product roadmap. There are two reasons for this: First, having carried out the necessary strategy discovery work, you’ve acquired the relevant knowledge to make effective roadmapping decisions. Second, the strategy forms the basis for building an effective product roadmap. The needs and business goals stated in the strategy help you select the right roadmap goals. You may even be able to derive the outcomes on the roadmap directly from the product strategy by breaking the needs and business goals into more specific subgoals, as Figure 1 shows.[5]
Conversely, if you don’t have a validated strategy, you lack the basis for developing a realistic, actionable product roadmap. If that’s the case, stop and carry out the necessary strategy discovery work. Then continue building the roadmap.
Stakeholders Dictate the Roadmap Content or View It as an Unchangeable Commitment
In my coaching work, I sometimes meet stakeholders who insist on getting specific features onto the product roadmap and who expect that their features will be delivered as stated in the plan.
Usually, there are two issues at play in this situation: First, the product manager/product owner lacks the necessary empowerment and finds it hard to say no to the stakeholders. Second, the stakeholders are used to a traditional planning approach. They see the product roadmap as a feature-based, fixed plan instead of an outcome-based one that is regularly reviewed and adapted.
My initial advice is to try and fix these causes: Work on your empowerment by growing your lateral leadership capacity and lobbying for more support from senior management, as I explain in the article Understanding Empowerment in Product Management. Additionally, use an outcome-based, adaptive roadmap like my GO Product Roadmap instead of a traditional feature-based plan.
But if this fails, then I recommend not using a product roadmap. Otherwise, you risk ending up with a Frankenstein product — a loose collection of features that might please the stakeholders but don’t create much value for the users and the business as a whole. What’s more, if the roadmap is seen as an unchangeable commitment, implementing it may result in a “death march” where the development teams regularly work overtime and end up being exhausted. Consequently, productivity drops, people’s health suffers, and software quality is compromised — which will make it harder to enhance the product in the future.
Instead of using a roadmap, set a three-month goal as recommended earlier, preferably together with the stakeholders. A collaborative approach offers three benefits. First, it increases the chances that the stakeholders will support the goal. Second, it helps you build trust, which increases your ability to influence and guide them. Third, it sets you on the path to adopting outcome-based roadmaps, as I explain in the article How to Get Started with Outcome-Based Product Roadmaps.
Learn More
To learn more about developing realistic product roadmaps, read or listen to my book Strategize and attend my Product Strategy and Roadmap training course. Contact me if you would like me to teach the course to your team.
Notes
[1] The time frame stated applies to digital products. For hardware-based ones, you may require a larger period, say, 18 or 24 months.
[2] While a product roadmap is likely to change, it should be stable enough for the following one to three months. If the plan changes, say, every two weeks, the rate of change is too high. The roadmap is no longer a useful, sufficiently reliable plan.
[3] Additionally, you’ve taken the first step to using an outcome-based, goal-oriented product roadmap, as I explain in more detail in the article How to Get Started with Outcome-Based Product Roadmaps.
[4] The stand-out features are especially important for a revenue-generating product, as they help you correctly position it.
[5] I discuss the relationship between the product strategy and roadmap in more detail in the article Roman’s Product Strategy Model.
