3 Common Product Roadmapping Mistakes

The product roadmap is a great tool to describe the likely growth of a product. But there are three common mistakes I see people make: View the roadmap as a guarantee; show epics and user stories on the roadmap; and speculate about the likely development of the product. This post discusses the three product roadmapping mistakes to help you avoid and rectify them.

Guarantee

A product roadmap is not a guarantee but a high-level plan that describes the likely growth of your product based on what you currently know. It’s good to have confidence in your roadmap and it is great to be committed to your product. But your product roadmap is not fixed; it will change particularly if your product is immature or if your market is dynamic.

Clearly tell your stakeholders that the roadmap is not a hard-and-fast plan. Choose the right roadmap format and the right level of detail. Review and update the roadmap regularly and invite the key stakeholders to collaborative product roadmapping workshops. Take look at my post Getting Stakeholder Engagement Right find out how you can effectively identify and involve the stakeholders.

You can find out more about choosing the right roadmap format and level of detail in my post Goals vs. Features: How to Choose the Right Product Roadmap Format.

Epics and User Stories

Don’t put epics and user stories on the product roadmap. While it’s helpful to consider how the product is likely to evolve, you should focus on its key capabilities and leave out the details.

A detailed roadmap has several drawbacks: It makes it hard to understand how you want to progress your product; it makes it more difficult to achieve agreement with the stakeholders; it is more prone to change; it carries the risk of turning the roadmap into a tactical tool that competes with the product backlog; and it restricts the freedom of the development team to make a commitment and pull the right amount of work into the sprint.

Capture the epics and the user stories in the product backlog, not on the product roadmap. Use the roadmap to describe the big picture and the backlog to describe the details, as I discuss in my post The Product Roadmap and the Product Backlog.

Speculation and Wishful Thinking

Don’t create a roadmap if you don’t have a valid product strategy available or if you cannot look beyond the first public release. The former implies that you have nailed the market segment, the value proposition, the key product features, and the desired business benefits.

The latter means that you can realistically anticipate the longer-term growth of your product. If you are working on a brand-new product, for instance, and are about to launch your first minimum viable product (MVP) then you may not be in a position to create a product roadmap for the next 12 months without resorting to speculation. You may be better off waiting until you have analysed the users’ response to the MVP.

Delay the creation of your product roadmap until you have a valid product strategy in place and you understand how to implement the strategy. Otherwise you are likely to end up with a speculative and unreliable roadmap that is useless. This may cause the stakeholders to lose trust in the product roadmap and in your planning abilities.