Digital by Default

Take the high road…map


Updated 22/03/2018

GDS have just added some guidance about producing product roadmaps to the Service Manual. It is really good in my opinion — makes it clear why they are important and lays out 12 solid principles for creating them:

  1. Your roadmap takes you towards a vision, in iterations
  2. A roadmap shows what you’re trying to achieve
  3. Each service or product should have a roadmap
  4. Roadmaps are developed iteratively and regularly
  5. A roadmap should be open
  6. It needs to be easy to understand
  7. Product iterations have clear objectives
  8. Missions and phases have fixed time periods
  9. Roadmaps are clear about priority
  10. Roadmaps capture intent and allow for change
  11. They explain the ‘who’ and the ‘how’
  12. They’re reusable

There is more detail over on the Service Manual and it is worth a read.

http://www.jamiearnold.com/blog/2017/1/25/plans-vs-roadmaps

Over the last few years I learned a lot about about roadmapping from folk at GDS. My initial efforts were very much inspired by the work Neil was doing with roadmaps for GOV.UK, then I was lucky enough to spend some time with Tom Loosemore and Jamie Arnold to work up the roadmap for the ONS website project working through the seven questions Jamie more writes about here.

  1. What are we trying to prove or learn?
  2. Who are the users?
  3. What are we operating?
  4. What are we saying?
  5. What are our assumptions?
  6. What are the dependencies?
  7. What capabilities do we need?

This year the GOV.UK team have shared how their thinking has evolved and how they create their roadmaps now.

I’ve read a lot of other stuff about roadmaps over the years and I really like how some organisations operate them but it is these lessons I come back to time and again and now these new principles will get added to that list.

Update:

The recent Futurelearn series about their approach to roadmaps is brilliant:

Matt Jukes

,
%d bloggers like this: