10 Product Roadmapping Mistakes to Avoid
The product roadmap is a great product management tool. But it can cause significant issues when it is not used appropriately. This article discusses ten product roadmapping mistakes you should avoid to fully leverage your roadmap.
🎧 You can listen to the audio version of this article here: https://www.romanpichler.com/podcast/product-roadmapping-mistakes-to-avoid/
1 The Product Roadmap is a Feature-based Plan
Traditional product roadmaps are usually output-focussed plans that map a list of features, like registration, search, and reporting, onto a timeline. Such a roadmap essentially states when a piece of functionality will be delivered. This can be reassuring for customers and stakeholders. But it has the following three drawbacks:
- A feature-based roadmap can give rise to and strengthen a feature-factory mindset where adding features is more important than creating value and making a positive impact on people’s lives and the business.
- Focussing on features risks turning the roadmap into a tactical plan that overlaps with the product backlog, especially when fine-grained features are used. This makes the roadmap harder to understand, and it increases the effort to keep it up to date.
- A feature-based product roadmap is easily mistaken for a commitment rather than a high-level plan that is likely to change. This will not only lead to disappointed stakeholders. It will also limit your ability to experiment and learn, to run sprints and discover the best way to address the user and customer needs and create value for the business.
You can avoid these drawbacks by using a different roadmap type: a goal-oriented or outcome-based product roadmap. As its name suggests, this roadmap focuses on product goals and outcomes, such as acquiring customers, increasing engagement, and future-proofing the product by removing technical debt. Selected coarse-grained features might still be used, but they are now dependent on the goals: Every feature must serve a goal and be required to create a specific outcome.
A handy tool to create a goal-oriented roadmap is my GO product roadmap, which you can download for free by clicking on the image below.
2 Roadmap Goals are Features in Disguise
While goal-oriented roadmaps can be very beneficial, they are not always applied effectively. A common mistake I see product people make is to use product goals that are features in disguise. Say that I am about to create a product roadmap for a healthy-eating product. Would the two statements “measure calorie intake” and “determine blood sugar level” then qualify as product goals? I don’t think so. In my mind, they describe product capabilities or features, and they characterise the solution. They do not state why it is worthwhile to progress the product.
Therefore, be careful not to mix up goals and features. Ensure that your product goals always capture the desired outcome the product should create and not the output. A good test to understand if a product goal describes an outcome is to ask the why question. For example, I could ask myself why it would be helpful to measure calorie intake. The answer would then reveal the true goal, such as “help the users improve their eating habits.”
3 Stakeholders Determine the Roadmap Content
Do your stakeholders ask you to add specific features to the product roadmap? If that’s the case, you are not alone. It’s not uncommon that product roadmaps are driven by stakeholder requests and that individual stakeholders want to have “their” features included.
While it is important to actively listen to the stakeholders, you should not allow them to dictate the roadmap content. Your job is not to please the stakeholders, but to achieve product success. If you say yes to every request, you are in danger of creating a Frankenstein product — a product that is a collection of unrelated features, offers a weak value proposition, and gives rise to a poor user experience.
Decline stakeholder requests if they aren’t aligned with the product strategy. If they are then look for a product goal that the feature supports. If there is none, then either adjust the plan by amending an existing goal or introducing a new one, or reject the feature request. This, of course, assumes that you are adequately empowered and that you have the final say on strategic product decisions.
4 The Person in Charge of the Product Creates the Roadmap on Their Own
Another common roadmapping mistake I witness is the opposite of the one just described: the person in charge of the product creates the roadmap on their own without any input from the stakeholders and development teams.
This approach is problematic for the following three reasons:
- It does not leverage the creativity and knowledge of the stakeholders and development teams. This is likely to result in a product roadmap that is suboptimal or wrong.
- It risks creating a plan that is not clear to the stakeholders and development team members, that lacks a shared understanding, and that causes misalignment.
- People are less likely to support a product roadmap if they haven’t had the opportunity to contribute to it. In the worst case, the stakeholders and development teams pay lip service to the plan, go off in different directions, and follow their own goals.
You should therefore adopt a collaborative approach where you involve the key stakeholders and development team members in creating, reviewing, and updating the product roadmap, preferably in the form of collaborative workshops. Strive to come up with a plan that helps maximise the value your product creates and at the same time, attracts as much support as possible, as I discuss in more detail in my article Making Effective Product Decisions.
5 The Roadmap is Not Systematically Connected to the Strategy and Backlog
While the product roadmap is a plan in its own right, it is a mistake to create and manage it in isolation. This would result in a roadmap that is not aligned with the product’s value proposition and business goals and in a product backlog that is not linked to the roadmap. This, in turn, can lead to inconsistent and wrong product decisions: Strategic decisions don’t direct tactical ones, and insights from the development work don’t help progress the roadmap.
My product strategy model shown below positions the product roadmap between the strategy and the backlog: The roadmap states how the strategy will be implemented in the coming months, and it directs the product backlog. The former is achieved by translating the needs and business goals stated in the product strategy into product goals. The latter is enabled by using the next product goal to focus the product backlog.
Read On …
To read the rest of this article and access the remaining tips, please head over to my website: https://www.romanpichler.com/blog/product-roadmapping-mistakes-to-avoid/
Learn More
You can learn more about successfully working with product roadmaps by attending my product strategy and roadmap training course and by reading my book Strategize.
Source: https://www.romanpichler.com/blog/product-roadmapping-mistakes-to-avoid/
