A few years ago the UK government’s publicly available online information was spread out across hundreds of individual and disconnected websites. So the Government Digital Service (GDS), a department within UK’s Cabinet Office, set out to consolidate this information and make accessing it easier for the nation’s citizens and interested readers around the world.
The result was GOV.UK, a single point of online access to UK government information. This online hub, which receives 12 million visitors every week, describes itself as “the best place to find government services and information… simpler, clearer, faster” and has given itself the ongoing goal of “making government work for users.”
I spoke recently with Neil Williams, a founding member of GOV.UK’s product team and now head of the 140-employee GOV.UK team within GDS. We discussed Neil’s groundbreaking 2016 decision to help make the platform even more transparent and accountable by releasing a publicly available product roadmap.
Neil’s product management approach is fascinating and offers, I believe, some valuable insights for product managers in both the public and private sectors.
Jim Semick: You didn’t start out with a product roadmap for the GOV.UK platform. What was the catalyst that caused you to create one to map out and share your strategic vision for the website?
Neil Williams: For a long time during the development of the GOV.UK website, we didn’t believe we needed a roadmap because we were really just in ‘skirmish’ mode. We wanted to build something new that could replace all the existing government sites. Plus, in the early stages we were a small group. 14 people working very closely together on an alpha product.
I think what moved me to see the need for a roadmap was actually twofold. First, there was the increasing size and complexity of this thing we were creating. GOV.UK became much bigger and more complex. Our team eventually grew by 10x, from that initial 14 to a team of 140 that I manage today. And our stakeholders became more numerous with more than 330 government organizations publishing to the web via our platform.
As we grew more mature, and as groups began to work on different initiatives for the platform in parallel, we definitely needed a roadmap to document, track and share all of our plans and objectives and make sure we were all pulling in the same direction.
At the same time, it’s important to understand that a central part of the culture at GDS is transparency. You can see it on the posters in our offices and the stickers on our laptops: ‘Make things open, it makes things better.’ So the second reason we moved to a roadmap is that it just made sense to create an ongoing, open source of information where our colleagues and (later) the general public could come and see what we were working on at GOV.UK.
JS: That’s a great lead-in to my second question. Why you chose to make your GOV.UK product roadmap available to the public. Indeed, today anyone can view the roadmap at your Inside GOV.UK blog. This is a relatively uncommon move for product managers. What did you see as the benefit of a public roadmap?
Neil Williams: For most of my professional life now I’ve been a member of the civil service, and honesty is enshrined in our values. That matters a great deal to me and an ongoing theme in my career has been to help create more openness and transparency within government.
For example, many years ago I launched the first-ever blog by a UK Cabinet Minister and soon after became one of a handful of civil servants who started blogging about their work in the late 2000s. I’ve gone on to spend a lot of my career pushing departments within the UK government to be more open and engaging with the public, using the culture and tools of the internet.
Within GDS, I was pushing against an open door. We were set up as a new bit of the civil service with the express intent of being a strong center of digital culture and expertise – so all employees at the Government Digital Service blog about our work and anyone can check in with what we’re building and planning by visiting our public blogs, be that the main GDS blog or the blog from a given team – like Inside GOV.UK.
As GDS’s most mature product, GOV.UK was the first to start roadmapping across multiple teams and was first to go public with our roadmap – but the precedent of openness was already there (we code in the open, many of our backlogs are open, and like I said we blog by default).
And – most importantly – publicly posting our roadmap is perfectly aligned with the GDS mission, which is to make government work more efficiently for our citizens. You have to keep in mind that we are a public agency, funded by taxpayers rather than revenue from customers. Unlike products in the private sector, we aren’t driven by sales figures, active users, conversions or profit-and-loss.
Our users are the taxpayers who fund us, which makes them our most important stakeholders. Making government services better to meet their needs is our entire reason for existing. So as far as I’m concerned, we have to make this information readily available to the public – it’s a moral issue, as I see it, for us to be as transparent as possible to the users the website is there to serve about what we’re working on, and listen to their feedback.
JS: Okay, so that’s a great explanation of how a public roadmap benefits GOV.UK’s end users and other interested parties. Does making the roadmap public also provide benefits for you and your own team?
Neil Williams: Absolutely. It keeps us on our toes to have public oversight of what we’re doing.
Saying publicly what we think we’re going to do means we’re held to account, and if we get delayed for any reason we have to be ready to explain why. That’s good discipline, it keeps us honest.
It also keeps us focused. Everyone is watching — or at least can watch — and so any delay or change of plan is visible.
A second and related benefit I see in making our roadmap public is that we receive user feedback on it. The simple act of posting the roadmap online generates constructive challenge and valuable ideas from our government colleagues, and sometimes the public.
It also has the effect of heightening interest in GOV.UK and what’s coming next for the platform – including for prospective employees, who we obviously want to be excited about the work coming up here so they choose to come and join our team.
And, most simply, publishing the roadmap is far and away the most efficient way for us to keep all of our government colleagues around the country up-to-date on the progress of our platform. We have more than 3,000 admin users across the 330 organizations that make up the central UK government, and they are very widely distributed, which makes it difficult and costly to reach all of our stakeholders with every update.
Maintaining a public roadmap online, then, is just a more efficient way of communicating the ongoing plans and objectives of GOV.UK with everyone in the government.
JS: And finally, may I ask you about your experience using ProductPlan to create your GOV.UK roadmap? Why did you choose our roadmap software and how has it worked for you?
Neil Williams: My first approach to building the GOV.UK roadmap was to use a static design tool and then output a PDF to share with my team and stakeholders. I published this roadmap monthly.
This was okay as far as it went. But it was laborious, and too static – each monthly issue was outdated within a few days after publishing because details were always changing. So we needed something more interactive and collaborative, easier to update and share.
Then I moved to an online collaboration tool, which served our needs perfectly while we were still completing the initial build and working on a small number of concurrent goals. But we outgrew that at the start of this financial year (April) when we started to need to show multiple streams of work, which teams were working on which things,interdependencies and so on.
The tool we were using was great for Kanban boards but wasn’t designed specifically for product roadmap creation, so it didn’t have the ability to allow me to show, for example, the same roadmap at the different levels of detail depending on the audience — such as the feature-level stuff, the group-level objectives, and the more strategic-level vision.
ProductPlan allowed me to tell the GOV.UK story, setting out the narrative of what we’re doing next, with the right level of details for different audiences. And it made it easy to get it all set up very quickly compared to some of the other tools I tried.
Plus of course it has an option to share the roadmap via a hosted URL, which was top of the selection criteria for me! It’s working out well for us so far – and I’d encourage product teams everywhere to try going public with their roadmaps, what’s the worst that can happen?