Prototype This is a prototype. It is not an official product or service. You can email us any feedback.

  1. DDaT Playbook
  2. Roadmaps

Home Office Playbook

Why use a roadmap?

Having a plan that keeps everyone focused on the desired outcomes for users is important. It ensures that all the different teams, departments and stakeholders stay aligned across a whole product lifecycle.

A roadmap is a way to plan, implement and communicate how a product is developed, delivered and maintained. It’s designed to change over time, in response to fresh input from frequent user testing and changing circumstances.

How roadmaps look, what they should show and how they should be managed varies. But there are some principles that apply whether you use post-its on a wall, Excel, Trello or a specific tool designed for the purpose.

Roadmap principles

  1. They are a communication tool, so should be simple and easy to understand. Use plain English and minimise clutter. You don’t need to include all the information here – it’s about sharing a vision of where you’re going and showing where you are now and what needs to happen to get there.
  2. Roadmaps are not a project plan, with strict dates and deliverables.
  3. For things that are coming up next, you might want to add more detail around who’s doing what and when to make sure the team members and other stakeholders you need are available.
  4. They should provide value to specific teams – from senior stakeholders to contractors working on one part of a product. It’s fine to have multiple versions of a roadmap designed for different audiences so they have the information that’s useful for them.
  5. They must be kept up-to-date, showing when they were last updated and by whom. Roadmapping is a process, not a destination. They should be adjusted as you go along.
  6. Roadmaps should be open and shared widely.

What do roadmaps include?

  • What you’re working on at the moment, and possibly what you’ve completed most recently.
  • What your next priorities are.
  • Any large ‘things’ to be aware of (e.g. the date a piece of legislation goes live).
  • You may also want to make reference to what isn’t on your horizon (what’s out of scope or not being dealt with yet).

How to make a roadmap

Creating a roadmap is a collaborative process. Though the product manager (if there is one) is responsible for making them happen, they don’t do it on their own.

Work out what needs to be done to achieve your product vision

This means stating what you’re aiming to achieve with the product. In other words, you’re focussing on goals rather than how they are achieved.

If it’s a new project there may be scope to bring in user-research to understand the problem better prior to starting.

If you’re mid delivery you may be working on assumptions, but if you’re able to factor in user-testing at some point and can adjust the approach accordingly, the product will always benefit.

You may also want to seek input from your stakeholders. If they’re not used to working in a product-centric way, they may tell you what features they want, rather than what the problem is.

Work with them to understand the problem they’re trying to solve – as a team you may find a better solution.

Organise the work by themes and outcomes

It may make sense to split your roadmap into multiple “swimlanes” that run in parallel over the same period of time. Each of these would be based around a high-level theme. If you’ve written a product vision and value proposition you’ll use these to inform them.

For pieces of work or themes that are coming up next you may have more detail on how the goal will be achieved. This would typically be the implementation of a particular feature, but it could be an enabler (paying down tech debt for example), or a decision point. There’s no need to get into that level of detail for areas that are further out on your roadmap.

The outcomes should have metrics associated with them to enable feedback and improvement.

Prioritise

Prioritise what needs to be done. This requires input from everyone on the team who will work to build it – to map dependencies and size the different pieces of work.

It often makes sense to do the smaller pieces first to confirm that you’re on the right course and deliver value sooner.

Put your prioritised goals onto the roadmap in the order you’ll do them. You can include the most recent work to set the context, and projects that are already underway. We recommend that you use Q1, Q2 etc, or “Now, next, future” rather than precise dates. Include any other factors that could impact things (major holidays when things slow down, events, or changes in policy etc.).

Develop the roadmap over time

It’s best not to go too far into the future with a roadmap because – things change! Six to twelve months is generally the furthest out you can go with any certainty.

Communicate the roadmap to the team and to stakeholders frequently. It’s a living document that you should review regularly.

Case study

Digitising passport applications

When the product team at HMPO first started work on enabling people to apply for passports online the amount of applications they handled was 0.1%.

Four years later, over 70% of passports are now processed online. 

This was achieved by a team who had a vision of simplifying and speeding up the process of getting a passport for people.

No more queuing at the post office or going to the doctor to get a photo countersigned.

Throughout the product lifecycle, they’ve used roadmaps to keep this vision in mind, plan the work to be done and share their progress and successes.

Start with smaller, simpler products to prove value early

Passports have “application types” which all have different requirements for the user.

An adult renewal is very different to getting a first-time passport for a child. They started with the simplest type of application for users – adult renewals.

This proved the value of digitising applications and enabled them to tackle more complex types.

Adapt to changing circumstances

A roadmap was drawn out to cover several years. As they worked they discovered things that led them to reprioritise.

For example, they thought they’d work on lost/stolen passports next but realised that because the journey was different (there’s no old passport to send back) it made more sense to move that to the end. Instead they worked on relatively simple feature changes first, which enabled them to onboard overseas applications earlier.

Stay focused on outcomes – and language!

The big leap forward came with adult first-time applications, which required a digital equivalent of the countersignature on the reverse of the photo.

Digital identity confirmation threw up many challenges, but once nailed, it was an enabler for a whole host of other application types.

User testing highlighted the importance of every detail in the process, including language.

They were still using the word “countersignature” for this step and realised it was confusing for users. After clicking through the online form and submitting they would ask “so when do I actually sign the back of the photo?”

This neatly demonstrates the importance of staying focused on delivering the outcome (i.e. confirming someone’s identity) rather than building a feature that replicates an existing process.

How roadmaps played a part in the process

There have been many roadmaps over the first 4 years of work and they’re a testament to how the team matured and built on what they learned as they went.

The team spent the first couple of years building on the adult renewal application journey.

They learned from feedback, iterating features and technology that eventually enabled them to rapidly deliver much more complex features in the latter part of the development.

They worked hard to establish a solid foundation on which to easily iterate and deliver further value.

Key facts

  • Roadmaps existed as post-it notes on the wall, various Excel spreadsheets and most recently in [Roadmunk]. 
  • They always used dates on their roadmaps because they had a fixed deadline relating to a legacy contract which had significant cost implications if it was missed.
  • They measured digital uptake and customer satisfaction amongst other things, as the work enabled HMPO to achieve wider goals of becoming a digital-first business. 

Summary

It is now possible for all application types to apply online.

The success of the service is regularly recognised in the 90%+ positive user feedback it receives. It’s won 3 prestigious national industry awards across the private and public sector in 2019. However, as with all services, there is always room to improve, which is why the team continues to maintain and build on the products it’s delivered.

Realising that end to end service ownership by empowered teams drives greater outcomes has been a turning point for the organisation.

A senior stakeholder summed this up well when they said “Once we stop iterating it becomes legacy.”