This week I celebrated my first anniversary at Government Digital Service. When the days are long and the work is hard, it’s easy to get dismayed, but that’s when I pinch myself to remember that I work on the UK government’s website. Next week I’m on leave, heading over to General Assembly to teach on their product management course, which is always fun. Means I might have the headspace to write up those blog posts I’ve been meaning to for ages!

Five Things That Happened

We did more things than this


The first team retro for Search Performance & Resilience went well. We’re clearly on the right track – it was a very positive session – and we have made the uncertain more certain early on, but we exposed issues around the dev VM. Our developers have to download a lot of data to emulate on their virtual machines, which means they often run out of disk space, but this problem is compounded when you’re having to load large search indexes too. It’s a programme-wide problem and we’re not the only team facing this issue, but it is more acute for our developers.

We’d heard word that Chris had developed a way to take a slice of the data, meaning you needn’t load everything, but weren’t entirely sure the scripts existed. He had previously put together mini-environments though and I asked whether we could explore that too.

I asked whether we might be moving too fast, as I didn’t want us to miss any important details, but everyone thought were moving at a fine speed. This was improved later in the week when meeting the AWS Migration team. They were planning on migrating Rummager, our search API, but have had to focus on other parts of the infrastructure. Our roadmaps align though and they should be ready to help us route traffic from dependencies to the new Search API once it’s up and running.

And finally I filled in a massive, gigantic spreadsheet charting our costs for search functionality over the next three years. As Liz Sarginson, our deputy director for Technical Operations, said: ‘Product managers should know the costs and financial effects of their decisions.’


We’re getting a programme-wide roadmap put together, and I shaped how we might improve our product pipeline. Currently we have support tickets lumped in with feedback and feature requests, which means we’re mixing together the ‘I want to report a broken thing’ tickets with the ‘I want to know how to do a thing’ tickets. And the ‘I want to be able to do a new thing’ tickets get barely any time spent exploring the problem area.

My proposal is to look into our current models for support, ongoing user testing, feedback and triage, aiming to quanitfy the operations and expose the pain points. We need to collect qualitative data on how this has been handled at other organisations and agencies, and I’ve some experience of doing this at NOW TV and Porism. (My pipeline for eCasework was really slick and meant our user retention went up, because user felt like they were being listened to.) We’re in need of a good knowledge base too, or at least some rules around making sure it’s updated. Too much of our product knowledge is stored up in people’s heads, which is not helpful when new people join the programme or move across product areas.

After that, I’d like to look at how we work more closely with departments and end users, the next layer of the gumball: collecting and validating user needs, lean testing and research models, onsite observation for innovation, guerilla UX testing and other methods for improving our new product development. How do we best become aware of signals from users and ensure we don’t miss opportunities?


We held the first Product People LDN of 2019. Four people working in agile delivery teams spoke about their experiences working on EU Exit projects, with some excellent highlights. Move user research closer to policy, meaning it’s shaped based on real user need. Don’t force an MVP to be ready by a deadline, you’ll almost certainly miss the real and huge opportunities to create efficiences across government. Keep your cool about you and use your agile nous. Focus on purpose in a noisy context.

Thanks to everyone who made it over to Whitechapel, to the speakers for their time, and to my colleagues for helping me hand out passes, direct people to room, etc. It’s such a good cross-government community!

If you missed out on the event, view the presentations.


We had a playback session for the Explore Personalisation mission. We’ve just started turning over the rocks to find out what’s beneath, interviewing other organisations, international governments and others to explore this area. Mark starting putting together some excellent desk research on the rise and fall of personalisation on other Web platforms. I pestered people at Facebook, Netflix and elsewhere to talk to us, but no dice so far. I did a little vomit because Facebook refers to itself as ‘the Internet’s leading social utility’.

We’ve lost our delivery manager to EU Exit projects, so I’ll try and keep the ship sailing.


Chatted to Fajer about GOV.UK Registers. I was delighted to hear that she’d been enthused by meeting folks at the Department for Digital, Culture, Media and Sport and the Department for Transport. It sounds like she can see the opportunities for taking Registers to the next level, helping pin together some of the fabulous efforts the open data community in government is already realising.


What I Learned

What it’s like navigating a team through ambiguity. Exploring a nebulous problem area isn’t easy, especially when it is ill-defined and not related to goals. But having a wide-enough scope to uncover glimmers of the possible is one of the ways we can innovate (little ‘i’). Grateful to John for his post reminding me that being at the centre of the tornado is the job.

What I Could Do Better

It took me a couple of hours, split over a few days, to put together the gigantic costs spreadsheet for Search Resilience & Performance. It kept popping up in stand-up, unfinished, so I could perhaps be better at carving out time for large pieces of work like that. Maybe I should have a logbook of how long certain tasks usually take, that’d be helpful in planning my week.


Thank you to the people who’ve signed up to my mailing list this week, I’m really glad to hear people think it’s a ‘great collection of stories’!

These weeknotes took me two and a half hours to write on a Saturday morning. It always takes me that long, and I often do it on a Saturday morning.