Host Intro (Gene Kim)

Okay, our first talk this morning on day three of the conference is from Julia Harrison, Head of Product for Government as a Platform at UK Government Digital Service, which she joined in April 2019.

I loved her talk last year at this conference, where she talked about leading product teams, and we had a chance to catch up earlier this year. I learned what she's been working on since then. She told me about how the capabilities that her group created have helped other government agencies ensure the safety and health of UK citizens, including some of the most vulnerable, during the global pandemic.

I asked her if she'd be willing to tell her story this year, and I'm so delighted that she said yes. This is a fantastic talk about product management, about leadership, understanding the customers who are often developers, and how we can better use modern planning methods like OKRs. Here's Julia.

Julia Harrison

My name's Julia Harrison. I work at the Government Digital Service, or GDS as we call ourselves, which is part of the Cabinet Office. For those of you not familiar, I'll explain some of those things in a moment. But first, I want you to cast your minds back.

You might not remember the specific date, but you'll remember that week. It was just before the UK went into our first lockdown. At GDS, we'd all just started working from home full-time, and we had no idea how long that might last.

This was the text message my manager and several other senior leaders in GDS received: "Please can you join a call?" And when he joined, he got this warm welcome: "I'm so glad you volunteered." At that point, he didn't know he had, but by the end of the call, he was signed up to leading a program to build a digital service for launch on the Monday, three days away.

A cohort of the people most vulnerable to COVID-19 would be told to stay at home, not to leave their homes, not even for shopping. Many of them would have neighbors and relatives who could drop off food and other supplies safely. But for those who didn't, we needed to find a way for them to register to get help and for us to securely pass on their details to the organizations who could help them.

Over the next hours, he and others figured out what skills were needed to quickly set up a new service, recruited a few key people from around GDS, and they in turn recruited more people. As word got around, a team came together to work over the weekend. At the same time, people from at least five different government departments were also coming together to solve their piece of the same puzzle. If you look up the GDS podcast, there's an episode from February this year about how that all happened. So I'm going to skip to the feel-good bit.

By the evening of Wednesday, March 25, just five and a bit days after that first text message, food boxes were being prepared to be delivered the next day. Seeing the photos of the first food boxes was an emotional moment for everyone involved. In the first wave of the pandemic, 4.7 million food boxes were delivered to over half a million people. We enabled over a million others to get priority access to supermarket delivery slots, and local authorities were able to target critical social care services to those who most needed them.

I'm not going to pretend that you can build something in four days without some serious compromises. One thing we absolutely would not budge on was the privacy and security of people's personal data. That was a priority right from the start, as was making it easy for people to register. But there were other things where we just had to do the quickest thing and come back to it later. By the summer, the vulnerable people service we were running was very different to what we had on the day it first went live.

So as I said, I'm a Head of Product for the Government as a Platform program at GDS. If you notice my Twitter handle, my background is corporate IT. I started out in desktop support, then Windows support and engineering, and I got into IT service management, service improvement projects, and via a happy accident, ended up in product. I've been in product for about eight years.

The Cabinet Office was formed in 1916 and is, to quote our website, "the corporate headquarters for government, supporting the Prime Minister in ensuring the effective running of government." I've been at GDS two years, and I'll tell you a bit about GDS's history in a moment. I've been with GaaP since May 2020. That's another way of saying I can't take credit for most of the things I'm going to be talking about today.

So what is Government as a Platform? Government as a Platform, or GaaP as we call it, provides a range of shared services solving common problems across government: problems like how to provide usable and accessible ways for users to interact with services, how to send communications to users, how to receive payments from users, and how to host services. All of which enable government to quickly and safely deliver good services, providing great value for money. Our platforms are used in thousands of digital services across the public sector in the UK. Because what we do is mostly open source, what we've created has been reused as the basis for similar services around the world.

Since March 2020, GaaP has been critical to the government's response to COVID-19. Because of GaaP, service owners across government could move at incredible speed, creating new services in just a few days.

Our design system enables usable, accessible, consistent services to be built fast. As well as providing the design patterns for the Vulnerable People Service front end, we enabled the creation of more than 50 services in 12 departments, saving government an estimated 10.4 million in just the first few months of the pandemic.

GOV.UK Pay makes it easy for service teams to take card payments from their users and is used by over 200 public sector organizations, ranging in size from the NHS and the Passport Office to museums in Northern Ireland and the Orkney Islands Council. When back office staff around the country couldn't physically come to an office to process checks, GOV.UK Pay gave them a way to take electronic payments which they could set up in a single day, even with no digital team.

GOV.UK Notify makes it easy for services to send emails, SMS messages, and physical letters to their users, and is used by everything from huge government departments with mature digital capabilities to GP surgeries and primary schools who can send messages by uploading a spreadsheet. During the pandemic, it enabled text messages from the NHS to extremely vulnerable people advising them to stay at home, business continuity messaging for public sector staff, travel alerts from the Foreign, Commonwealth and Development Office with a 700% increase on their usual volume, and a peak of 11.7 million messages a day. The platform sent its billionth message in May 2020. Since then, we've sent well over 100 million text messages telling people their COVID test results and tens of millions of emails, texts, and letters related to scheduling vaccination appointments.

This is where I get to be like a proud parent. When I was able to get my appointment for my first vaccination in April, of course I had to check the email headers and see for myself it had come through our platform.

GOV.UK Platform as a Service provides an on-demand platform enabling new services to get started quickly, hosting services for more than 50 public bodies, including Navy News, the Civil Aviation Authority service to register a drone or light aircraft, and the Department for Education's teaching vacancies job finder. GOV.UK PaaS also hosts our own notifications platform and was able to support the massive increase in traffic on Notify thanks to its ability to scale rapidly.

So how was all this possible? I'm going to take you back in time again, this time back to November 2010. Around that time, there were nearly 2,000 public sector organizations, each with their own individual website with different styles and layouts. It was difficult to navigate. It was confusing. Users found it frustrating. Users shouldn't need to know how government is structured to find what they need.

On November 23, 2010, Martha Lane Fox, a digital entrepreneur and the government's digital champion, published the result of the strategic review the Cabinet Office had asked her to carry out of Directgov, which at that time was the government's main online platform. Instead of just reviewing Directgov, she wrote a report much wider in scope about how government could better interact with the public and deliver more efficient public services online. In her report, titled "Revolution, Not Evolution," Martha laid out a vision that gave us the mandate to set up the Government Digital Service in 2011.

The first GDS project was the GOV.UK Alpha. Fourteen people spent 10 weeks meeting about 100 user needs. It was more about making a point than making a product, and the point was that we can build government websites in a different way, and they can work. We can be agile. We can start with user needs and meet them. We don't have to procure things through huge years-long contracts. By 2012, GOV.UK was able to replace Directgov.

Then in January 2013, we launched the Exemplar Program. This was where we worked with government departments to build 25 great digital services using truly agile methods, meeting policy objectives, not building the thing, prototyping, experimenting, iterating, creating long-lived product teams with sustained funding. In March 2013, we launched the Service Standard, which laid out how departments can build and sustain good quality digital services.

The current version of the Service Standard came into effect in July 2019. Each of these is supported by guidance in our service manual, but I'll just take you through the key themes we cover with these 14 points. Meeting users' needs is about user research, user-centered service design, simplicity, and accessibility. Providing a good service means a multidisciplinary, agile, data-informed product team able to iterate and improve a product, and of course we care about privacy. We also have guidance to help teams make good technology choices. In particular, we have a commitment to open source.

In June 2013, we started service assessments. A service team could have their service assessed by a panel of their peers from elsewhere in government using the Service Standard. What we learned from building services and assessing those built by others was that there are a set of common needs: things being built again and again.

We identified a list of these common user tasks, and we put in an ambitious bid for multi-year funding because we knew that if we could build something once to meet each of these needs, we could avoid duplication of build and maintenance costs and save money all over government. In 2015, the GaaP program began to do just that. Not only did we save money, because we were able to put whole teams on solving these problems, we could become expert in things like taking payments from users while the people working on the service to book a driving test could focus on what it takes to help people book a driving test.

So what were the secret ingredients? Why were we able to do all these things? It wasn't Post-it Notes or bunting, although you might have thought that if you ever visited our office.

Being funded to build something in one department for the benefit of others was key. There are other models, but creating incentives for sharing is hard. In the early days of a product, it was much easier to persuade people to start using it if we didn't also have to persuade them to start paying for it.

One of the nice things about solving common problems is that they're common. People recognize them. They can see you're doing something that will help them, and the sooner you can solve enough of the problem to save them work, the sooner you're helping. By having real users use your product for real work early, you start getting data to help you improve.

It's fine not to be everything to everyone. This goes a bit against the grain for us at GDS because when we build things for the public to use, one of the points of the Service Standard is to make sure everyone can use the service. But building something for other service teams is a bit different. If they have a specific need, unless it's shared by a lot of other teams, it might not make sense for us to add that. They might need to build it themselves or procure it somewhere else, and that's fine. That means we can keep our products relatively simple, avoid feature bloat and the support burden that comes with it, and continue to run and iterate our products with quite small teams.

We have a truly agile organization. We support experimenting, not being put under pressure to pretend we know all the answers at the start, and not fixing on a solution too early and building the thing. That means we can focus on outcomes, solving real problems, and delivering real benefits.

Our user-centered design approach means a big focus on understanding real user needs through user research, prototyping, and again, experimentation. There is a selfish reason for us to prioritize good design as well. If our users can self-serve most of the time, it means we can run our services with relatively small teams. So it is really important we create things that are easy to use. We take data about how users interact with our services to inform our decisions on what to improve.

Because we fund long-lived product teams, we're able to keep iterating and developing our products to keep up with evolving user needs or add even greater value. There is no handover to ops, and we don't have to get approval and funding to add a feature if we can do it with the team we have. We're able to build deep expertise in what we do and get to really know our users, unlike a project team, which is typically disbanded when the project finishes and everyone goes off to do something new. In an emergency, if we have things that can safely be paused, we can free up people to deal with the emergency.

Coming back to March 2020: because these platforms already existed, our teams could focus on helping their users, the teams scrambling to solve these urgent problems in a pandemic. Because we already encouraged our teams to act with a degree of autonomy, they could reprioritize their work. They could decide to stop doing some things. It was very obvious that anything not related to saving lives or supporting critical services could probably wait. We didn't have to tell our teams, and they didn't have to ask permission. They just let us know which things wouldn't get done.

When the government told the most vulnerable people to shield and stay at home, the service to enable them to register their details to receive help was built, maintained, and iterated to begin with by volunteers from other teams. Of course, that left gaps in those teams. Again, the autonomy we gave to product teams meant they could reprioritize, while the folks at my level, one level removed, focused on things like supporting people through the switch to remote working or planning for what we'd do if we had a lot of staff sickness.

One of the product managers reporting to me at the time looked after the infrastructure that supported a service critical to people claiming help with their living costs. We knew there'd be a massive increase in people unable to work during lockdown and needing to register for financial support for the first time. This product manager had people working away from the team, volunteering on the Vulnerable People service. So he and the remaining team had been figuring out with their user, the owners of the identity verification platform, what they could do to make sure there were no issues with scaling for this huge increase in demand we expected. They decided to park all their roadmap work and just focus on scaling and stability. My response was, "Great. Thanks. Yes. Do that then, and tell me if there's anything I can do to help." They didn't ask permission, and I didn't expect them to. They were best placed to figure out their priorities with their customer, and they did. I carried on working on program-level problems.

But what can you do if you're not in a truly agile, user-centered, product-driven organization? What if you're expected to be an order taker sometimes? I have found there's a lot you can do if you can influence just one stakeholder, just one manager with a requirement that you're expected to fulfill. Often someone comes to us with, "We need a thing." That's actually pretty normal, and it's fine. Our job is to dig deeper.

Back in 2015, this was something we thought we might need to build: some kind of platform to bring together status on all the requests a member of the public might have open with different parts of government. But no user wakes up and thinks, "I need the government to give me a status tracking platform." So what's the real need?

Already, by framing the requirement as a problem being solved, not the thing being built, we can think about other ways to solve that problem. Users wanted to know the status of their transactions, and they wanted to know because we hadn't told them. Pulling together status of all the possible requests a member of the public might have open is a really hard problem to solve. Making it easy to tell them in real time when something happens with their request is much, much simpler. We'd already started working on that problem. We probably didn't need a separate status tracking platform.

So we're thinking about solving problems rather than building things. If our measures of progress have, up until now, been based on how much of the thing have we built, are we on time, are we within budget, we could probably improve on that. Not only because it's a better measure, but also because if you can get your stakeholders to agree to your commitment to deliver the benefit, you can get them away from caring so much about the thing.

Objectives and key results, OKRs, are how we measure success in the GaaP program. When we understand what's needed, the team gets together to propose OKRs. I'm going to take our example of a status tracking platform and apply it to a fictional organization. This didn't happen, but it easily could have done.

Let's imagine we have a fictional executive who's really attached to the idea of a status tracking platform. Maybe they had one in the last place they worked. Maybe it was great. As before, we start by asking why. It's because users want to know the status of their request. Maybe our executive has been looking at our social media feeds and can see how many people are frustrated at not knowing what's happening, which is great.

It's great to have these conversations because we can find out what our executive really cares about, what motivates them. In this case, it sounds like what they really want is happier users. If we can agree that's what they want, we can set it as an objective and suggest a key result we think we might achieve. We haven't quite got them to let go of the tracking platform idea yet, but we'll get there.

We could make a lot of users happier by sending them flowers. That's probably not the answer our executive is looking for. They probably don't want us to massively increase costs in the process. What if we could have happier users and reduce costs? In our fictional organization, like most other places, when users are unhappy or when they want to know the status of their request and can't find it for themselves, one of the things they do is contact us either through a call center or through our social media channels. The more users we have contacting us, the more we have to spend on staffing our contact centers and social channels. So reducing those contacts reduces costs.

If we can get to this common understanding with our executive that what we want is happier users and reduced contacts, we're really getting somewhere. Now when you come back to them with your proposal for how you can get happier users and reduce contacts, not only on time and within budget, but quicker and cheaper than you can build a status tracking platform, you might get a lot less resistance. I can't promise, but I've had conversations like this, and I've seen it work in more than one organization. It is possible.

If we'd asked our users, "Would you like a place to see all your request status?" they might have loved the idea. We could have spent hours testing different ways to present that information and convinced ourselves we were solving an important problem. In a way we would have been, but we could have solved a different problem much more efficiently.

I'm not an expert in user research, so I asked an expert for some tips that anyone can use. First, we're not doing market research, so be careful not to pitch your product idea. Try not to ask leading questions about preferences. Not only are these questions closed, they're also not very actionable. If a user's telling us about a great experience in another product, asking, "What did you like about that?" gets something much more useful about their preferences. Try to keep the discussion questions focused on real experiences, not hypothetical ones.

To make sure everyone really understands the needs of our users, we recommend everyone should observe at least two hours of research every six weeks. That could be watching user research sessions live or watching recorded playbacks. But you can learn about your users in other ways. It might be listening in on customer service calls. It might be looking at tickets in the support queue or looking at social feeds. If your users are other people within your organization, can you sit with them? Maybe not for the last year or so, but what's the online equivalent? Can you join their Slack channel? Can you ask to observe a task that's related to the problem you're solving?

Quoting users or research participants word for word is much more persuasive than only using a summary. It tends to really land. However, people can really anchor on those comments, so it can be a double-edged sword, and I advise using it carefully.

Start with the problem, not the solution. I don't know whether this is a question anyone asked when we were thinking about a request status platform, but if we had, what might the answer have been? "I realized it was a few weeks since I'd sent in my passport application, and I hadn't heard anything." Well, there's more than one way to solve that. Asking about a problem and its context helps us figure out if this is a real problem, not really a problem at all, or a symptom of a different problem.

So where are we now? GaaP products continue to go from strength to strength, and we've just started discovery on one of the most asked-for things we haven't built yet, which is a way to collect data from users to replace the PDF forms that low-volume services are currently using. Design system usage is dependent on front-end developer activity across government. What we think the graph shows is that after the rush of new services around March 2020, unsurprisingly, a lot of departments like us slowed down on some things. But in general, the usage continues to trend upwards, and you can see there has been dramatic growth in the last few months. Platform as a Service is also steadily growing. Pay continues to grow and has been on a nice gentle exponential curve since about 2019. Notify went through the roof in March 2020, and with vaccination scheduling and COVID tests making up a big chunk of its volume, hasn't slowed down yet.

So what's next? There are things we want to do with our existing platforms, and you can see those on our public roadmaps. This year we're putting in another bid for multi-year funding to tackle the next things we can do to make it easier for government to build great digital services. Often we talk to teams who would love to use GaaP platforms in their services, but there are constraints that prevent them. So we want to partner with some teams elsewhere in government to figure out how to unblock some of those. We're still figuring out how to make it possible to share things that aren't centrally built. What happens if another department builds a thing that serves a wider need? Is it possible to create the right incentives and remove some of the biggest risks for them providing a service for others?

I'd love to tell you more, but some things are still a bit up in the air. We'll blog about them in the open as soon as we can, so do keep an eye on our blog to find out more as it happens.

And now I have a story of my own to tell. Until I joined GDS two years ago, I'd worked almost entirely in the commercial sector and never really considered becoming a civil servant. But in October 2018, I was at a conference where Liam Maxwell gave a talk. Liam used to be the CTO for Cabinet Office and has held other senior positions in government technology. At the end of his talk, he talked about technology careers in the civil service, and not long after I applied for a job at GDS.

Making it easier for people to interact with government takes work, and we need people to help us do it. It can be pretty full on at times, but it can be fun, and it might be the most rewarding work you'll ever get to do. Look for the jobs link on our website and subscribe to our careers portal to get updates as new roles become available. Thank you. And if you're watching this live, I'll see you in the Slack.