Developing a Product Roadmap

Now that we've explored the basics of what a roadmap is, let's dive deeper into how to actually develop a product roadmap. Before we get into the step-by-step process, it’s essential to understand how roadmaps are typically created in organizations and how they should ideally be developed.

Traditional Roadmap Development

In many companies, the creation of roadmaps tends to follow a conventional approach, even if they claim otherwise. The leadership decides what they want to build, the Product Manager (PM) explains the features to the team, the designers create the design for these features, and finally, the engineers implement them. This is a common practice, though it's not always the most effective.

This process tends to be top-down, with little input from the broader product team, resulting in limited collaboration and engagement. The roadmap ends up becoming a list of predetermined features that teams are expected to execute without much exploration or experimentation.

Ideal Roadmap Development Process

So, how should roadmaps be developed?

• Leadership should explore opportunities and communicate how these align with the company’s strategy, OKRs, and broader initiatives. Their role is to provide the strategic direction.

• The product team should ideate solutions to address those opportunities, conducting experiments, performing discovery, and testing ideas. They should focus on finding the best solutions to achieve the company's objectives.

Ideally, there should be a collaborative space where both leadership and the product team come together to discuss the scope of the work, testing strategies, quality expectations, available resources, and deadlines. Depending on the timeframe and resources available, trade-offs may need to be made—such as prioritizing speed over quality or vice versa.

This collaboration ensures that the roadmap isn't just a top-down directive but rather a shared vision, leading to more commitment and satisfaction from the product team. This includes developers, UX designers, business analysts, and other relevant roles. This type of collaboration leads to a win-win situation for everyone involved, resulting in a well-constructed roadmap where all parties are aligned from the start.

Key Components of a Product Roadmap

A well-developed roadmap contains five primary components:

1. Product Vision: This component articulates how the product will benefit the customer. It answers the question: how will the product help customers achieve their goals?

2. Business Objectives: These define the broader goals of the product. What does the product aim to accomplish for the business? These objectives should be clearly aligned with the roadmap.

3. Timeline: The timeline could be broken down by quarters (now, next, later) or months, depending on how the team wants to structure it. This helps to give a clear sense of the roadmap's pacing, though it’s important to consider whether or not to include exact dates.

4. Hypotheses and Themes: These represent the opportunities to be explored. Some teams refer to them as epics—large initiatives that need to be tested or validated.

5. Annotations: While it may seem odd to consider annotations a primary component, they play a crucial role in communication. Annotations provide necessary context or details that help stakeholders better understand the decisions behind the roadmap.

Example Roadmaps

Let’s look at a couple of real-world examples of public roadmaps.

• UK Government Roadmap: This roadmap is divided by months and organized by themes (or epics/initiatives). For example, one theme could be demand for content training, with specific actions or goals detailed for each quarter. This roadmap is a great communication tool, and it’s updated frequently to keep stakeholders informed.

• GitHub Roadmap: GitHub’s public roadmap is more focused on technical feature delivery. While it’s highly functional for the developer audience, it is less oriented toward results or initiatives. It works well for its intended audience (developers) but may not be as effective in other contexts where a focus on results is more important.

• Microsoft Roadmap: This roadmap shows what’s in development, what’s been implemented, and what has been launched. It provides a clear view of the past, present, and future, making it an excellent resource for benchmarking.

These examples highlight the importance of tailoring your roadmap to your audience. A roadmap is a communication tool, and its structure should depend on who is reading it—whether it's a development team, executive leadership, or a broader public audience.

Organizing the Roadmap Around Themes

One useful way to think about roadmap development is to organize it around themes. A theme is a broad objective that encompasses several epics or user stories.

For example:

• Theme: Increase conversion rate in the shopping cart.
  • Epic 1: Implement mobile support.
  • Epic 2: Add new payment options (credit card, etc.).
  • Epic 3: Improve user experience (UX).
  • Epic 4: Build a new admin console.

Another example:

• Theme: Ensure customers complete their first purchase faster.
  • Epic 1: Add mobile support.
  • Epic 2: Optimize the API for performance.

Notice how the themes are outcome-oriented rather than just focused on functionalities. This helps teams stay focused on achieving specific results rather than just delivering features.

Secondary Components of a Roadmap

In addition to the primary components, there are secondary components that provide further detail:

1. Product KPIs: These metrics measure the success of the roadmap in achieving business objectives.

2. Features and Solutions: These describe the specific functionalities or changes that will be delivered to achieve the themes.

3. Development Stage: This indicates the current status of the feature or initiative—whether it’s still in beta, being actively developed, or is blocked by external factors.

4. Confidence Level: One of the most valuable components, the confidence level helps set expectations. For example, if the confidence level is medium, stakeholders are prepared for potential delays, helping manage expectations effectively.

5. Additional Information: Depending on the audience, additional information such as project dependencies or technical details can be included. For example, a technical team might want to know which squads or teams will be impacted by a particular feature. For other stakeholders, like sales or marketing teams, these details may not be relevant.

Sharing and Customizing the Roadmap

A roadmap should be easily accessible and shared across the organization. It serves multiple purposes:

• Aligning everyone in the company around the same goals and objectives.
• Providing a reference point for feedback and iteration.
• Offering inspiration and guidance to the product team.

It’s also important to customize the roadmap based on the audience. For example, a sales team might need a simpler, high-level version focused on timelines and results, while the engineering team may require more detailed technical information.

Conclusion

When developing a roadmap, remember that it is not a static document but a dynamic communication tool. It helps teams stay aligned, provides clarity on the strategic direction of the product, and keeps stakeholders informed. By carefully considering both the primary and secondary components, and tailoring the roadmap to your audience, you can create a roadmap that effectively drives product development while adapting to the evolving needs of the business.