Running a roadmapping workshop

For an alpha or beta, or for a significant update to a live service, we run an initial roadmapping workshop during inception.

The aim of the workshop is to get everyone on the same page about the goals, activities, risks and dependencies of the project.

Our roadmapping workshops are developed from the Seven questions to build a roadmap described by Jamie Arnold.

For a discovery, we run a discovery kick-off workshop.

Why we have a roadmap

A roadmap is a strategy tool. It sets out the direction for a product or service and outlines how we’ll achieve our objectives.

Roadmaps should:

  • Set clear, agreed goals
  • Be related to outcomes, rather than specific outputs and dates or releases
  • Be adaptable and respond to change
  • Cover the complete service we are providing, not just the digital parts we are building

We create roadmaps in workshops where we aim to:

  • Understand and make sure we have agreement on the goals of the project
  • Figure out what we need to have to be successful (capabilities), and how that relates to the goals and desired outcomes
  • Identify risks and dependencies
  • Understand the stakeholder landscape
  • Set priorities, particularly for the things we need to do first

Before the workshop you need to have clear high level goals for the work, and the commitment of key stakeholders to attend. If you don’t have those, focus on understanding and resolving those issues first

After the workshop, the roadmap becomes a living part of the project documentation. But we recognise that the conversations that come from building the roadmap are just as, if not more, important than the document itself.

Questions for roadmapping

About the project

  1. What are our goals and outcomes?

    What are the overall goals for the project and service? What intermediate outcomes do we want to achieve? How might we measure them?

  2. What are we assuming?

    What ideas and beliefs are our goals and outcomes based on? How confident are we that they are true? That they won’t change?

  3. What are we trying to learn or prove?

    What do we need to know to make good decisions? What might the organisation already know? What risky assumptions should we be testing? What will we need to prove to validate our work?

About the service

  1. Who are the users?

    Are they members of the public, professionals or staff? What different groups, circumstances and behaviours might be important? Are they current or potential users?

  2. What are we operating?

    What digital and physical components will the service be made up of? What people will be involved in operating the service? How will we roll out the service?

  3. What capabilities do we need?

    What capabilities will we need to build and operate the service? What do we already have? What is new? What is well understood and what is novel?

About the context

  1. Who are our stakeholders?

    What is their relationship to the work? What expectations and concerns might they have? How closely might they be involved? How might they help?

  2. What are our dependencies?

    What other work or organisations will the project and service depend on? Who is depending on us? How will we manage those dependencies?

  3. What do we need to communicate?

    What meetings, governance and other processes do we need to feed into? What communications might we expect to create? For who? How will we share them?

Using Now, Next and Later to prioritise

By default, we prioritise the roadmap into:

  • Now, the first outcomes we’ll work towards and all the things we’ll need to do for those
  • Next, the outcomes we’ll work on once we’ve completed the first things
  • Later, everything else

To help ground the discussion, you can give a timeframe to the Now and Next. This might be quarters for a bigger piece of work, or single sprints for a smaller project.

We recommend prioritising as you ask each question, rather than waiting until the end. This will involve some iteration as the answers to later questions influence previous thoughts about priorities.

You might not have time to prioritise everything. But the conversations about priority should help set the direction and scope of your first sprint.

Planning the workshop

From our experience, roadmapping workshops take from 2 hours to a full day. Follow good workshop practice to help everyone contribute, make the best use of their valuable time and produce a good result.

If a service is particularly large and complicated, it’s better to build a high level roadmap that you can refine later, rather than trying to run a longer and larger workshop.

The product owner and delivery or transformation lead normally lead the workshop. And you should aim to have a broad set of participants to represent the views of both the delivery team and the wider client organisation.

From the client organisation aim to include people from service and product management, policy, operations, and technology, along with specific subject matter experts.

From the team you might also include a designer, researcher, developer and technical architect.

Building the roadmap

Before the workshop:

  • Create a grid with a row for each question, and columns for Now, Next and Later. This can be on a wall, or in an online tool like Miro.

During the workshop:

  • Start with the goals. Work to make them clear, then break them down into more specific outcomes with potential measures Work through the rest of the questions, one by one
  • For each question, ask participants to write items on paper or digital sticky notes
  • Ask participants to talk about their items, to clarify and improve any unclear items, and to make sure you include everyone’s thoughts
  • Group or stack similar items
  • Discuss priorities as you go. Place the items in the Now, Next and Later columns

Using the roadmap

Turn the outputs from the workshop into a roadmap document. It can live on a wall, in a tool like Miro, or both. We usually arrange the content of the roadmap into swimlanes. These can be:

  • The roadmapping questions
  • Common themes or workstreams within the project
  • Specific goals or outcomes

Use the roadmap to start conversations with stakeholders about activities and priorities, and to gain consensus across teams and organisations.

Someone must own and maintain the roadmap. Most often this will be a Product Manager or Product Owner in the client organisation, although we will own the roadmap if we have to. The owner works with the team and stakeholders to regularly review and update the roadmap. Without clear ownership the roadmap will quickly drop out of use and lose it’s value.