man wearing black and white stripe shirt looking at white printer papers on the wall

As product managers (and product owners), one of our core responsibilities is to create, manage and own the product roadmap. Not only what we are planning to achieve in the next few sprints but also to be able to show what is a mid and long term vision for the product (or part of product) that we are responsible for. We don’t do this because our managers ask us to do so. We do it because the product is often in the centre of the business impacting many stakeholders. For example, the marketing team needs to prepare marketing campaigns to support new feature launches, customer support needs to plan for more support tickets when a big feature and redesign is planned and many others. 

In this post, I’ll give you a framework that helps you create a longer term roadmap so that the dependencies mentioned above are addressed as well as the product managers aren’t forced to make unreasonable commitments.

Most of us work in some kind of agile framework and I’ve experienced it that some understand agile as freestyle with no plans and no commitments. Especially the ones who don’t work directly with other stakeholders and don’t realize their dependency to planning. With that I’m not saying that every feature and launch needs to be planned and committed a year ahead but rather that there needs to be a balance that works for everyone. Every team and company is different and there is not a one-size-fits-all solution that specifically defines the time for which the commitments need to be made. For example, to launch a new feature in many different languages and market specific campaigns globally requires much more preparation and coordination for the marketing team than launching it only in one language and one generic campaign. And the product roadmaps need to reflect it.

How the roadmapping framework works

Here is my framework that helps you create a longer term roadmap and keep all stakeholders informed. 

  1. Understand the vision or long term strategy with which the product is being built
  2. Understand who your users and customers are. 
  3. Understand who your stakeholders are.
  4. Understand the stakeholder activities that are impacted by your roadmap.
  5. Learn about requirements coming from the users and customers.
  6. Convert the requirements into features or epics and prioritize them (if possible, together with the users and customers).
  7. Create the first draft of the roadmap from the prioritized features.
  8. Invite the stakeholders to review the first draft of your roadmap and add their activities into it. 
    1. In this step, learn about their time constraints (such as that a marketing team needs 1 month to prepare a certain campaign).
  9. Create the minimum necessary timeline for the features and stakeholder activities that address the dependencies.
    1. In this step, work with the team on realistic estimates as well as confidence in those estimates.

As you expect, this framework is a recurring process that you don’t do only once. For me it worked to do it approximately every 6 months as that was when the requirements or priorities used to change. You can start with a similar approach and be ready to be flexible and do it sooner depending on the situation, business and user requirements, changes to the business model, market and similar.

Let me know in the comments what’s your experience with creating roadmaps.

Photo by Startup Stock Photos on Pexels.com