188体育

A roadmap is a plan that shows how a product or service is likely to develop over time.

Roadmaps need to be easy to understand, and simple to adjust when priorities change - as often happens with agile ways of working.

Why roadmaps are important

A roadmap makes it clear what you鈥檙e trying to achieve and the steps you鈥檒l take towards that end goal. This applies whether you鈥檙e working on a whole service or a product that supports a service.

As well as making it clear what you鈥檙e doing, a roadmap also explains what you鈥檙e not doing.

A roadmap helps the wider team understand how what they鈥檙e working on now relates to future work and priorities.

Anyone involved in providing a budget or governance for your work needs to see a roadmap so they understand when and how your team is likely to deliver value to users.

Having an open roadmap also makes it clear to other delivery teams what you鈥檙e working on, so everyone can see where things might overlap and you can avoid duplicating work. When things are open, it鈥檚 easier to find and share useful code, patterns and supporting materials across products.

Users of your product or service may want to find out what your plans are for developing it, as might people who deliver public services or hold government to account.

Roadmap principles

1. Your roadmap takes you towards a vision, in iterations

Your product or service should have a long-term vision that explains what it鈥檚 ultimately trying to achieve for users. Your roadmap should be broken down into the stages, or product iterations, that will get you there. At GDS each product iteration is known as a 鈥榤ission鈥�.

2. A roadmap shows what you鈥檙e trying to achieve

Products and services should be judged by the value they deliver to users. Examples of value are making things quicker, making things simpler and saving people effort.

Roadmaps are a tool to express what the value of a product will be. They show the stages in which that value will be understood and released to users.

3. Each service or product should have a roadmap

A product can have its own roadmap or it can be part of a wider roadmap that gives a collective view of products related to a service.

It鈥檚 best to keep your roadmap online using a spreadsheet or other software, to minimise the risk of losing any information.

If the needs of your users or team mean you need more than one version of your roadmap, like one on a wall and one online, use one as your master version but make sure each version is always up to date with the latest information.

4. Roadmaps are developed iteratively and regularly

Creating and iterating a roadmap is something you do collaboratively, usually led by your product manager. , and you must also use things you鈥檝e learnt from performance analysis and user research to inform the decisions you make. At GDS roadmaps are iterated on at least a quarterly basis.

5. A roadmap should be open

It should be available for other civil servants to view and should where possible be in the public domain. The main exceptions are when there鈥檚 a very good security reason not to make a roadmap available, or if there are political sensitivities around sharing plans.

6. It needs to be easy to understand

A roadmap should use simple visuals to make it easy and quick to understand. It should also be in plain English and free of jargon so it鈥檚 accessible and usable for the range of people who will use it. It can contain links to places where users can find more information, like a backlog or blog.

7. Product iterations have clear objectives

Each product iteration in your roadmap should have an objective that gets you closer to achieving your long-term vision. There should be a clear goal each time (often a problem to be solved) and an explanation of how you鈥檒l measure progress.

Roadmaps are not the same as , which are used by teams to manage the delivery of features and tasks in smaller, time-boxed periods.

8. Missions and phases have fixed time periods

Missions are mapped over time - this might be done in quarters. These segments of time need to be consistent.

When the roadmap includes phases (like discovery or beta) these should be timeboxed.

9. Roadmaps are clear about priority

A good roadmap shows what鈥檚 been done and what鈥檚 coming next in order of priority. The way you prioritise needs to be consistent and transparent.

10. Roadmaps capture intent and allow for change

Roadmaps allow you to plan for change. They capture intent, not solutions.

The further into the future a mission will take place, the more uncertain it is. The closer it gets, the more you learn and the more confident you become about whether it鈥檚 the right thing to work on.

Things can be added to or dropped from roadmaps.

11. They explain the 鈥榳ho鈥� and the 鈥榟ow鈥�

A roadmap should have an explanation of who it鈥檚 for and how to read it.

It should also include information about who maintains the roadmap, how often it鈥檚 updated and how to contribute to developing it.

12. They鈥檙e reusable

When you use software to create a roadmap, the content should be exportable so it can be transferred if needed.

Examples and case studies

Discuss and contribute

• - the original Medium post this guide is based on
• Discuss on the Product People mailing list or UK government Slack