00:00:12

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's 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 has 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, okay, ours, here's Julia.

00:01:06

My name is 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 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. And this was the text message, my manager, and several other senior leaders in GBS received. Please, can you join a call? And when he joined, he got this warm welcome. I'm so glad you volunteered. And 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.

00:01:59

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 ended up figuring out what skills we needed to quickly set up a new service, recruited a few key people from around GDS and by intern recruited more people. And 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 of this year, about how that all happens. So I'm going to skip to the feel-good bet by the evening of Wednesday, March the 25th, just five and a bit days after that first text message food boxes were being prepared to be delivered the next day.

00:02:50

Seeing the photos of the first food boxes was an emotional moment for everyone involved. And in the first wave of the pandemic, 4.7 million food boxes were 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. And 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 well as making it easy for people to register. But there were other things we just had to do the quickest thing and come back to it later. And by the summer, the vulnerable people service, we were running was very different to what we had on the day at first went live.

00:03:36

So, as I said, I'm a head of product for the government as a platform program at GDS. And 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 and ensuring the effective running of government. I've been at GDS two years. And I'll tell you a bit about GDS is history in the moment. And I've been with gap 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 gap 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 have to send communications to users, have to receive payments from users and have to host services.

00:04:38

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. And because what we do is mostly open source. What we've created has been reused as the basis for similar services around the world.

00:04:58

And since March, 2020 gap has been critical to the government's response to COVID-19 because of gap service owners across government could move incredible speed, creating new services in just a few days as a design system enables usable, accessible, consistent services to be built fast, as well as providing the design patents with the vulnerable people service front-end. We enable 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 government UK pay makes it easy for service teams to take car payments from their users and is used by over 200 public sector organizations ranging in social media, NHS, and the passport office to museums in Northern Ireland and the Orkney islands council, and went 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 after EK notify makes it easy for services to send emails, SMS messages, and physical letters to their users.

00:06:01

And it's 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's 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 our usual volume and a peak of 11.7 million messages a day. The platform sent its billions message in May, 2020. And since then we've spent well over a hundred million text messages telling people their COVID test results and tens of millions of emails, texts, and letters related to scheduling vaccination appointments. And 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 my email headers and see for myself, it had come through our platform and gov.uk platform as a service, which provides an on demand platform, enabling new services to get started quickly hosting services for more than 50 public bodies, including Navy news, the newspaper that celebrates the deeds of the Royal Navy around the world, the civil aviation authority service to register a drone or light aircraft and the department for education's teaching vacancies, job finder and gov.uk paths.

00:07:15

Also how 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, Jason Manford had just quit. The one show Nigel Havers had just walked out. If I'm a celebrity, get me out of here. And if neither of those names mean anything to you, it was also the day prince William and Kate Middleton announced their engagement. And around that time, there were nearly 2000 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. So on the 23rd of November, 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 direct gov, which at that time was the government's main online platform. Instead of just reviewing direct gov, 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 or evolution. Martha laid out a vision that gave us the mandate to set up the government digital service in 2011.

00:08:35

The first GDS project was the government. UK alpha 14 people spent 10 weeks meeting about a hundred user needs. It was more about making a point than making a product. And the point was 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. And by 2012 government UK was able to replace direct gov. Then in January, 2013, we launched the exemplar program. This is where we worked with government departments to build a 25 great digital services using truly agile methods, meeting policy objectives, not building the thing, prototyping, experimenting, iterating, creating long lift product teams with sustained funding. And in March 13, we launched the service standards, which laid out how departments can build and sustain good quality digital services.

00:09:28

This is the current version of the service standard, which came into effect in July, 2019. You can find both this and the original one online. And this is our poster version. Each of these is supported by guidance in our service manual, but I'll just take you through the key things we covered with these 14 points. So meeting users' needs, this is about user research, user centered service, design, simplicity, and accessibility, providing a good service. We believe that you need a multidisciplinary agile data informed product team, able to iterate and improve a product. And of course we care about privacy and we have guidance to help teams make good technology choices. In particularly we have a commitment to open source.

00:10:14

And then in June, 2013, we started service assessments. A servicing could have a 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 there a set of common needs? There were things being built again and again. And we identify the 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. I in 2015, the gap program began to do just that.

00:10:52

And 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 say the people working on the service to book a driving test can 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've thought that if you ever visited our office being funded to build something in one department, for the benefit of others, there are other models, but creating incentives for sharing is hard. So for us, this was key to getting started in the early days of the 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.

00:11:36

And one of the nice things about solving common problems is their common people recognize them. I 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, not only that, but by having real users use your product for real work early, you start getting data to help you improve. And it's fine not to be everything to everyone. This guy's a bit against the grain for us at GDF because when we build things for the public to use, one of the points of the service standard is 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 have 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. We can avoid feature bloat and the support burden that comes with it. We can continue to run an iterate our products with quite small teams.

00:12:32

And we have a truly agile organization. We support experimenting and not being put under pressure to pretend we will not. We know all the answers at the start and not fixing on a solution too early and building the thing. It means we can focus on outcomes, solving real problems, delivering real benefits. Uh, UCD approach means a big focus on understanding real user needs through user research, prototyping, and again, experimentation. And there's 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's really important. We create things that are easy to use. So we take data about how users interact with our services to inform our decisions on what to improve.

00:13:18

And because we fund long lift 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, and we're able to build deep expertise in what we do and get to really know our users, unlike project team, which is typically disbanded when the project finishes and everyone goes off to do something new and in an emergency, if we have things that can safely be paused, we can free up people to deal with the emergency.

00:13:52

So coming back to March, 2010, because these platforms already existed, that teams could focus on helping their users, the team scrambling to solve these urgent problems in the pandemic. And 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. 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. And 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. So of course, that left gaps in those teams. Again, the autonomy we gave to product teams meant they could reprioritize.

00:14:37

And 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 do. If we had a lot of staff sickness, one of the product managers reporting to me at the time, it looks after the infrastructure that supported the service critical to people claiming help with their living costs. And we knew that'd be a massive increase in people unable to work during lockdown and needed 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 here 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, but decided to park all their roadmap work and just focus on scaling and stability.

00:15:21

And my response was great. Thanks. Yes. Do that then. And tell me if there's anything I can do to help. I 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. And 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 are expected to be an order taker? Sometimes I found this 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. So back in 2015, this was something we thought we might need to build some kind of platform to bring together status.

00:16:06

And 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 that their transactions and they wanted to know because we hadn't told them I'm pulling together the status of all the possible requests. The member of the public might have open is a really hard problem to solve, making easy to tell them in real-time when something happens with a request is much, much simpler, and we'd already started working on that problem. We probably didn't need a separate status tracking platform.

00:16:48

So we're thinking about solving problems rather than building things. And if our measures of progress have up until now have been based on how much of the thing have we built? Are we on time? Are we within budget? We could probably improve on them. 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. So objectives and key results, okay. ELs are how we measure success in the gap program. When we understand what's needed, the team gets together to propose APLs, 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 that they worked. Maybe it was great. And as before we start by asking why, and as before, it's because your users wants to know the status of their request. So it may be our executive has been looking at our social media feeds and can see how many people are frustrated and not knowing what's happening, which is great.

00:17:52

It's great to have these conversations because we can find that what, what our executive really cares about, what motivates them in this case, it sounds like what they really want is happy users. And if we can agree that that's what they want, we can set it as an objective and we can suggest the 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 that. But 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. So 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 the 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. And the more users we have contacting us, the more we have to spend on staffing, our contact centers and social channels. So reducing those contexts reduces costs.

00:18:52

And if we can get to this common understanding when they're executive, that what we want is happier users and reduce contacts. We're really getting somewhere. So now when you come back to them with your proposal for how you can get happier users and reduce contact, 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. And if we've asked our users, would you like a place to see all your request status? They might've loved the idea. We could have spent hours testing, different ways to present that information and convinced ourselves we were solving an important problem. And in a way we would have been, but we could have solved a different problem, much more efficiently.

00:19:39

I'm not an expert in user research. So I asked an expert for some tips that anyone can use. And here's what I got first. We're not doing market research. So be careful not to pitch your product idea and 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? We get something much more useful about their preferences and 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.

00:20:39

It might be looking at tickets in the support queue or looking at social feeds. If your users or other people within your organization, can you sit with them? Okay. Maybe not for the last year or so, but what's the online equivalent. Can you join the slack channel? Can you ask to observe a task on a relate that's related to the problem you're solving and 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 and start with the problem, not the solution. So 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 of them? I realized it was a few weeks since I've sent in my passport application and they hadn't heard anything well, there's more than one way to solve that, asking about 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.

00:21:44

So where are we now got 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. So what we think this graph shows is that after the rush of new services around March, 2020, which I picked out in pink, unsurprisingly, a lot of departments like us slowed down on some things, but in general, we usage continues to trend upwards and you can see that been dramatic growth in the last few months platform as a service is also steadily growing hi continues to grow and has been on a nice, gentle, exponential curve since about 2019.

00:22:31

And notice if I 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. And this year we're putting in another bed for multi-year funding to tackle the next things we can do to make it easier for government to build great digital services. And often we talk to teams who would love to use gap 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. And we're still figuring out how to make it possible to share things on centrally built. What happens if another department builds the thing that serves the wider need, is it possible to create the right incentives and remove some of the biggest risks for them providing a service for others?

00:23:22

I'd love to tell you more, but some things are still a bit up in the air, but 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. And at the end of his talk, he talks about technology careers in the civil service. And not long after I applied for a job at GDS. So 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.