Developing a roadmap
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’re trying to achieve and the steps you’ll take towards that end goal. This applies whether you’re working on a whole service or a product that supports a service.
As well as making it clear what you’re doing, a roadmap also explains what you’re not doing.
A roadmap helps the wider team understand how what they’re 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’re working on, so everyone can see where things might overlap and you can avoid duplicating work. When things are open, it’s 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’s 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 ‘mission’.
2. A roadmap shows what you’re 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’s 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. The delivery team and stakeholders should all be involved, and you must also use things you’ve 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’s 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’s 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’ll measure progress.
Roadmaps are not the same as backlogs, 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’s been done and what’s 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’s the right thing to work on.
Things can be added to or dropped from roadmaps.
11. They explain the ‘who’ and the ‘how’
A roadmap should have an explanation of who it’s for and how to read it.
It should also include information about who maintains the roadmap, how often it’s updated and how to contribute to developing it.
12. They’re 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
- How we are using roadmaps in government
- The 2017 to 2018 GOV.UK roadmap
- How we made the GOV.UK roadmap
- Make the most of your roadmap
Discuss and contribute
- Read and comment on ‘Roadmap elements’ - the original Medium post this guide is based on
- Discuss on the Product People mailing list or UK government Slack
- Last update:
-
Guidance first published