Building Product Roadmaps: Common Pitfalls and How to Avoid Them

By: Aneesh Datta

Agility is essential in order to innovate in today’s digital world. It enables organizations to find ways of creating new sources of value that meet the evolving needs of customers. If done right, the product roadmap can be the link that articulates how the organization plans to deliver value. In contrast, a poorly constructed roadmap can lead to a series of unintended consequences that we’ll explore in this post. But before we do, let’s define what a product roadmap is.

What is a Product Roadmap?

In simple terms, a product roadmap communicates how the organization plans to achieve the product vision. Although there is no right or wrong way to build a roadmap, they tend to fall into one of two formats: outcome-centric is organized by outcomes or goals while feature-centric is organized by product features. The illustration and example below highlights the differences and how product roadmaps fit into the product planning process.

Pitfall #1: The roadmap does not match the context

In recent years, a considerable amount of literature has been published on roadmaps. I suspect this is because many product teams choose a format that does not match the context: the maturity of the product and the market dynamics. Let’s explore how these factors should inform the roadmap format decision.

A feature-centric roadmap is recommended if a product is considered mature and the organization is competing in a stable market. The uncertainty that comes with building products in a dynamic environment makes planning difficult. Features estimate beyond the next release tend to change as new risks or dependencies are uncovered. This leads to frequent roadmap updates that can erode trust in the product team. Conversely, if the product is not mature or the organization is competing in a dynamic market, an outcome-centric roadmap is recommended because themes and details are less likely to change.

Best Practice: Management sets the business objectives and empowers the product team to determine the capabilities/themes and features. This increases engagement by demonstrating confidence

Pitfall #2: Product Strategy has not been clearly defined

Marty Cagan defines product strategy as, “the sequence of products or releases the team plan to deliver on the path to realizing the product vision.”

In the race to meet deadlines, product teams commonly fail to commit enough time and resources to validate their product strategy. This can lead to building products that fail to create the intended change in customer behaviour, ultimately hamstringing the team’s ability to meet business objectives

At Rangle, a variation of Product Vision Canvas is used extensively to understand the product strategy and build a shared understanding. Once complete, we validate our assumptions by interacting with customers and observing how they engage with the product. After that, we assess feasibility by collaborating with engineers to understand the technical constraints.

Best Practice: Mitigating risk is essential to successfully executing the product strategy. Every product team should be able to clearly articulate the four product risks before attempting to write code:

i) value risk — will customers buy it

ii) usability risks — whether users can figure out how to use it

iii) feasibility risk — does the team have the skills to build it.

iv) business viability risk — does the solution work for the business

Pitfall #3: Roadmaps are linear but digital development is iterative

“We accept that we don’t know which specific features we’re going to build, and we give the teams the freedom to figure it out.” — Elli Rego, Product Manager @ Wodify

One of the joys of building digital products is the ability to iterate: launching a feature, measuring how customers react, and improving on it. For a number of product teams, making time to improve existing features while keeping the delivery train moving forward can be a challenge. The pressure to move to the next feature makes it difficult to improve elements of the existing product such as fixing tech debt, refactoring, or design enhancements due to time constraints.

As a best practice, a product team member, usually a Scrum Master or Product Owner, will periodically track the burn down chart (Scrum) or cumulative workflow diagram (Kanban) to determine if the delivery is on schedule. If the team is behind, the team must decide whether to reduce scope, defer the launch date, or add resources. The product team should also analyze customer feedback and data/analytics to inform product assumptions. This analysis can provide evidence that contradicts previous assumptions. The two inputs mentioned above should be used to update the product roadmap as required.

Best Practice: Incorporate roadmap reviews into an existing meeting or agile ritual that includes the required stakeholders. For example, if the product team demos work every two weeks, plan to review the roadmap every second demo, or month.

Conclusion

Product teams should be empowered to drive the product roadmap as long as they are held accountable for achieving the business objectives. A well-crafted product roadmap supported by a well-researched product strategy significantly increases the odds for product success. Hopefully, this post will help you steer clear of the common pitfalls as your organization works towards building products that delight customers.