Z Tech Blog

Using Product Roadmaps

How to effectively use Product Roadmaps within an Agile Framework

What is a Product Roadmap?

A product roadmap is a high-level plan describing how a product will come into being and how it will grow. It enables a Product Owner to express their vision of what the product should look like and a timeline of how that vision will be realised.

A roadmap enables you to show where you want to take your product, why it’s worthwhile investing in it and how it enables innovation. I prefer using a goal-oriented roadmap that is based on aims/goals/targets rather than solely dominated by many features. However, depending on the organisation, a feature dominated roadmap may work equally well.

The benefit of a goal-oriented roadmap is that it shifts the discussions from being about features to being about shared business goals that IT will enable. This also mitigates the risk of the business developing the view of roadmap features as commitments and development teams as people who only commit for the next few weeks.

The following is an example roadmap I’ve created for a real-time-strategy mobile gaming app.

Date1st Quarter2nd Quarter3rd Quarter
NameVersion 1Version 1.1Version 2
TargetAcquisition: Create a free app with limited in-app purchasesActiviation: Focus on in-app purchasesRetention
  • Basic game functionality

  • Invite up to 5 friends for multiplayer games

  • Integration with Facebook and Twitter
  • Create new items to purchase

  • Enhance/update existing items

  • Additional game functionality that can be carried out by the new items
  • New characters

  • New game terrains

  • Improved visual design
  • Performance Metrics
  • Number of Downloads

  • Target is to be within the top 10 downloads for this type of game within the first month
  • Number of in-app purchases

  • Number of downloads of the game app
  • Number of daily active users does not fall by more than 10%

  • Session length
  • A description of the fields is as follows


    An identifier for the release.


    The date by which the release will be ready and the metrics will start being used. The important thing to note for this section is that there are two dates: the first is for when the release is ready. The second, optional one, is for when the release has been released into the market, and when metrics data will start being gathered for us to review if the release has started meeting it’s targets. This second date is to accommodate any lag between the release date of a product and the date by when enough time has elapsed for us to safely start using metrics like download numbers and in-app purchases.

    Another third optional date can also be added if needed – the end date of metrics gathering. This would be a date by which, for business purposes, enough metrics data would have been gathered and analysis of the results can begin.

    Product Target

    What is the product trying to achieve with this release i.e. what is the purpose of this release and why are we going to allocate resources to it? For e.g. produce a new app that gains new customers, or create a feature that improves customer retention, or create a new workflow that reduces technical debt.


    A description of the high-level capabilities and deliverables. The roadmap is meant to describe product vision and strategy and should not deep dive into detailed product requirements because that is the purpose of a product backlog.

    I also find that it’s best to limit the features per release between 2-5 as more than 5 usually means you’re describing a detailed requirements list that is better suited to reside in the product backlog.

    Goals vs. Features

    I’d like to pause here and address what I think is an important difference between features and goals. Sometimes when I’ve been leading Product Management teams, I’ve had a Product Manager show me a roadmap they’ve created for sign-off where they have described a target for the first release as the Minimum Viable Product (MVP). While at face value, this might seem acceptable, or even desirable, I believe that something like that, an MVP in this case, is not a target, it is a means by which a goal is achieved, and thus is better placed within the features section.

    This is where an understanding of the business and it’s goals is important. For example, what is the company trying to achieve with this release – the first build of the product; just realising an MVP? A company releasing an MVP is actually trying to gain a better understanding of the market and see if their product resonates with early adopters. Thus, the product target is to gain a better understanding of the market and gain some early adopters. The description of what the MVP would be or do would be part of the features section.

    Key Performance Metrics

    The success criteria for the goals – a description of the measurement that tells us if we’re meeting our goals. These metrics need to be specific and measurable. For e.g. Which type of new users should the product be acquiring – from within the same market segment, a different market segment or a completely new market? How many new users do we want to target acquiring in this release? How will we measure new users – downloads, daily log-ins, in-app purchases?

    Benefits of using a Product Roadmap

    These are the benefits I have come across in my career when using product roadmaps:

    • Provides a continuity of purpose and communicates how you see the product develop over the coming months.
    • Facilitates stakeholder collaboration and helps the individuals understand how they can contribute to make the product a success.
    • Helps with prioritisation; allows you to state if and when a benefit will be provided, or a feature implemented.
    • Focuses the backlog on the next major release.
    • Helps obtain a budget by stating the benefits the product is likely to create.
    • Supports programme management and makes it easier to coordinate related products.

    When is a Programme Ready to Use a Product Roadmap?

    When managing a programme, it is tempting to start using and syndicating a product roadmap as early as possible. However, I think the optimum time for a roadmap to be created and used is when there are enough ideas and a consensus on those ideas for the programme to look beyond the next major release. Until this point is reached, we are still working on a vision and strategy for the product, and it would be premature to start using a roadmap as a basis for refining a product backlog and approaching governance boards for budgetary approval.

    How do Product Roadmaps and Product Backlogs Work together?

    The roadmap is used for strategic product planning. The backlog is used for product development by engineering teams and focuses on the details like Scrum Epics and user stories that have to be implemented to achieve the vision stated in the roadmap.

    For example, where the preference for the business is to have a quarterly release cycle, I would aim to create a roadmap that captures the next four major releases, with the product backlog taking care of the specific requirements within each release, and refined during each sprint.

    The below is a table highlighting the unique aspects of the roadmap and backlog.

    ArtefactPurposeContentsTime PeriodUpdates
    Product RoadmapStrategic planningMajor releases with goals and high level featuresApprox. 12 monthsAt least once per quarter
    Product BacklogProduct DevelopmentEpics, user stories and requirements, testing criteriaApprox. 3 monthsAt least once per sprint.

    Ownership of the Product Roadmap

    The owner of the roadmap is the Product Owner as the roadmap captures decisions about the product’s future. Strictly speaking, in an Agile process, the product owner manages the roadmap and the team members, stakeholders etc. contribute.

    While there might be a product ownership team that manages the product in it’s entirety due to it’s size, having one person in charge of and leading that team and having that person also own the roadmap and  backlog,  is beneficial as it unites the strategic and the tactical product planning aspects, and establishes clear authority and responsibility.

    Z Tech is a technologist, senior programme director, business change lead and Agile methodology specialist. He is a former solutions architect, software engineer, infrastructure engineer and cyber security manager. He writes here in his spare time about technology, tech driven business change, how best to adopt Agile practices and cyber security.

    Posted in Agile Processes and Frameworks, Blogs, Improving Agile Processes, Improving Collaboration, Product Management and Ownership, Programme and Project Management and tagged .

    Leave a Reply

    Your email address will not be published. Required fields are marked *