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?

   What standards and codes must we meet, for service, accessibility, equality, technology?

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?

   What biases and gaps in understanding might we have? What unintended consequences might there be?

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? Are they current or potential users?

   What different groups, job roles, circumstances, environments, access needs and support needs might be important? Who might currently be worst served and most likely to experience barriers?

   How will we engage and involve the different people we need to work with?

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?

   What digital and offline channels and support routes might there be? Which channels might different groups need and use?

   How will we roll out the service to all the people who might need to use it?

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?

   Are they colleagues from our organisation or other public sector bodies? What community, civil society, professional and advocacy groups might be important?

   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? What other work might be an enabler or blocker for us?

   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? Why and for who?

   How will we share information? How will we make our communications accessible and inclusive?

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.

Be careful not to always prioritise the largest groups and most common needs. Consider prioritising people who are currently worst served and who experience the most barriers.

And be careful not to leave work on accessibility and inclusion until Later. You can and should be working on these from your first sprint.

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 its value.

Last updated: 20 March 2024 (history)