Introduction to Roadmap Architecture

Roadmap Architecture & Structure

As a Product Manager it is important that you have a roadmap in place. Equally important is that you design your roadmap architecture and structure.

This becomes increasingly important as your company, teams and products scale. The larger your company and product grows, the more difficult it can be to align them. It is important to always ensure that your product roadmap is aligned with the business objectives as well as helping to align with your peers and teams (an I don’t just mean product teams).

It is advantageous to get a good framework or structure in place from the beginning; but we live far from an ideal world most of the time. A good architecture or framework allows you to link items from the top at a high level to the lower and more granular level, the main benefit being the alignment across all teams and levels in the organisation.

To start with, I think its important to look at the main layers of a roadmap structure:

If we think of their hierarchy, and how they link together, it looks like this:

Each layer in this structure has a specific objective, and should be used in conjunction with a specific audience.

Theme Objectives

Themes, or often referred to as ‘Strategic Themes‘ are at the highest level, and are set at an organisational level.

These come from the organisational strategy, and should the used to link what the business wants to achieve with what the product teams are building.

Some examples of strategic themes might be:

As you can see, these are high level directives which indicate to the product teams where they need to focus.

Theme Audience

The audience for a theme is your top level and senior management. Stakeholders that are not in the day to day granular details and needs information at a high level to make strategic and business decisions.

As it will be this level of management usually setting the strategic themes, they would want to be updated on this level too. Reporting would show the product teams progress in building and maintaining products towards achieving these strategic themes.

Another thing to consider is how you communicate progress on themes. With an audience at this level it will usually be in the form of numbers, and how those numbers are impacting the business.

Initiatives

Initiative Objectives

The next level down is your initiatives.

These are essentially the items on your roadmap. The key projects/deliverables you are planning to deliver in order to reach your organisational objectives.

There are many different types of roadmap; if you take the standard Gantt Chart as an example, initiatives are essentially what would appear on there.

Initiatives are the “projects” that the product team will work on to deliver. Initiatives is a wide term, and can encapsulate different things depending on the company or how particular product teams operate. They can range from features, to objectives, to outcomes or results.

Initiative Audience

With this level being your “roadmap”, it has quite a wide audience. including executives, all key stakeholders and also your customers.

This is probably the layer that will get the most attention, seeing as its the one where you are showing what you are building — and thats what most people are interested in.

It is important that your initiatives link to your strategic themes, and as a Product Manager it can help you to justify what goes in, and most importantly what goes out. If an initiative cannot link to a strategic theme, then you really need to question why you are considering it for your roadmap.

Updates on initiatives need to be consistent too, often initiatives can span months.

Epics

Epic Objectives

The Epic level is your Product Backlog.

Whilst strategic themes are usually driven by executives and C-levels, and the Product Manager contributes to Initiatives (these are usually cross domain, cross functional and require the input of multiple stakeholders). The Product Backlog is owned by the Product Manager.

Epics are broken down deliverables from your initiatives. I would best describe these as “features”.

Imagine you have an initiative that is to deliver a new checkout page for an e-commerce site. Some of your epics might be:

Your epics show what you intend to deliver (including its value) to achieve the overall initiative.

Epics Audience

The product backlog is a tool for the Product Manager.

At this level you start to cut our your executive and senior management who do not want to go into this level of detail.

I think at this level, your main audience is:

User Stories

User Story Objective

Your user stories are essentially the requirements. In order to deliver an epic (or a feature), breaking it down into a smaller deliverable helps to better understand and plan. This is an informal explanation of the requirements, written from the perspective from the end user.

The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer.

User Story Audience

User stories are at a delivery team level. These are what are delivered by the team in the sprints.

This really depends on the organisation, but usually the audience of user stories remains in the team and with direct stakeholders.

Tasks

Task Objective

Tasks, or sometimes referred to as ‘sub-tasks’ are the most granular level. This is essentially a task list to deliver a user story. This is only used by the team, and possible the Product Manager depending on how they are used.

Tasks are often the result of backlog refinement, when breaking down Epics and User Stories, which when the story is tackled in the sprint, allows the team to remember what was discussed and what needs to be done. This also helps to allow anyone in the team to take the task.

An example of this might be:

Task Audience

This is only for the team and the people doing the work, no one outside of this really needs to see or understand the tasks. They are there for the team to help them to deliver the stories in the sprint, and can also act as a definition of done, so that the user story cannot be closed until all the tasks are.

It is very beneficial to think about your delivery and roadmap structure and architecture. This helps you to ensure end to end delivery and complete alignment from top to bottom. Having this in place is also motivating for teams, as they can see, even from the smallest task they are working towards a greater good.

This article was orignally posted at: https://www.theproducthub.io/2021/05/01/introduction-to-roadmap-architecture/

About the Author

Ashley-Christian Hardy
theproducthub.io

Product Leader. Over 10 years in product development; with experience in product management, UX & UI, product design, product & delivery methodologies and product leadership. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research, putting an emphasis on a customer centric design and approach.

Website: www.theproducthub.io

Twitter: www.twitter.com/achardypm

Facebook: https://www.facebook.com/theproducthubio

LinkedIn: mt.linkedin.com/in/achardypm

Medium: medium.com/@achardypm

Instagram: https://www.instagram.com/theproducthub.io/

Pinterest: pinterest.com/achardypm

SlideShare: slideshare.net/ashlychrstn

Product leader. A strong advocate in innovation, experimentation and building great products with the use of qualitative and quantitative research.