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:

• Themes
• Initiatives
• Epics
• User Stories
• Tasks

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. 

Themes

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:

• Increase customer engagement through our platform
• Reduce the time to market for new customers
• Reduce operational cost of our products
• Improve acquisition funnel
• Increase customer retention and reduce subscription cancelation

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:

• Add to basket
• Add to favourites list
• Remove from basket
• Increase/decrease amount
• Pay with card
• Pay with Apple Pay

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:

• The development teams – this is important because you are telling them what is being built, in what order and what is coming next.
• Stakeholders – these are your important stakeholders who need to know what you are building, many of which will have hard dependancies on you. For example marketing who need to push the features or sales who need to sell the feature. A good solid product backlog helps you to align.
• Customers – this is a tricky one, and depends on how granular and transparent you go with your customers. They need to be informed on an initiative level, but then its also good to show your customers exactly what you are building and the benefits for them.

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:

• User Story: Develop a new UI interface for login
  • Design UI
  • Build Database
  • Integrate with authentication service
  • Write unit tests
  • Create automated tests
  • Document solution
  • Deploy

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.

Summary

This full architecture diagram shows an example of a potential strategic theme, all the way down to a task and how they link together.

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. 

Social Media

Follow me on social media:

• Facebook
• Instagram
• Medium
• Link
• Pinterest