Leeds Digital Festival: Product thinking in the public sector
Is building products for the public really that different from building for paying customers?
That was the question behind our panel at Leeds Digital Festival 2026. On paper, the public sector looks different:
👉 Different stakeholders. You answer to ministers, policy teams, and taxpayers.
👉 Different constraints. Governance, security, and ministerial priorities all shape how teams work.
👉 Different definitions of success. There's no profit line, and some outcomes take decades to show.
And artificial intelligence (AI) is raising new questions about safety and accountability on both sides.
Four product leaders from across government and health shared where the two sectors overlap, and where they really do differ.
The panel:
Michala Hare: Head of Role for Product Management at the Department for Work and Pensions (DWP). DWP is responsible for welfare and pensions, and has around 90,000 staff.
Debbie Blanchard: Head of Profession for Product Management at the Department for Education (DfE). DfE is responsible for children's services and education in England.
Atif Ahmed: Head of Product at NHS England. Atif helps NHS organisations adopt and scale AI-powered technology. He spent many years in the private sector before moving into public service.
Helen Stear: Head of Product and Digital Change and Engagement at the Medicines and Healthcare products Regulatory Agency (MHRA). The MHRA regulates medicines and medical devices in the UK. Helen leads a small team of senior product managers, alongside a team of change managers.
Key-takeaways (TL;DR):
- Businesses can choose their customers, but public services serve everyone. This means they may move slower, but they take everyone with them.
- Government product managers balance business, policy, and user needs, and it takes bravery and resilience to do it well.
- Teams can stay autonomous inside guardrails that must get clearer as the stakes get higher.
- AI moves products from predictable to probabilistic, so teams need new ways to measure, assure, and stay accountable.
- Without profit, impact is proven in layers, from everyday metrics and access to services, up to the mission and the human stories.
We’ve chosen to highlight five key themes from the discussion. We've removed who said what to give a general overview of the panel's views.
Jump ahead:
- What makes public sector product different?
- What does that ask of a product manager?
- How do teams stay autonomous when the stakes are high?
- What does AI change?
- How do you prove impact without profit?
- Is building products for the public really that different from building for paying customers?
What makes public sector product different?
You cannot leave anyone behind.
The panel agreed that the definition of product does not change in government. You're still building products that are available, resilient, accessible, and usable.
The difference is who you build for. A commercial business can make the right call for most of its customers, and leave out users who are not profitable. In the public sector, it's not okay to leave people behind. You have to meet people where they are: their digital maturity, their channels, their tools, and their technology.
Some users are going through hard moments.
Many users are going through tough times, such as losing a partner or a child. So research has to come from a sensitive, empathetic place.
Many services are also tasks nobody wants to do, like taxing a car or claiming a benefit. The goal is less about delight and more about reducing friction, so people can get through quickly and get on with their lives.
When something breaks, it matters more. If a shopping website is down for a couple of hours, you come back later. Someone in real need cannot wait, so recovery has to be fast.
The trade-off is speed, not people.
As mentioned above, leaving people behind is not an option. You might do a little less, but you take everyone with you.
This may explain why public services can look slower from the outside. Regulation, governance that protects taxpayers' money, and the need to keep data secure all exist because the service has to work for everyone.
You speak for users when the pressure is on.
In the heat of delivery, with a deadline and a budget, the product manager is the one who says: "Hang on, our users are extremely diverse, and they have these needs."
What does that ask of a product manager?
You have to balance business needs, policy needs, and user needs.
Government product managers work across a broad range of stakeholders across policy, user research, and more. One day it's a bug fix. Next, a minister wants to talk.
Teams are also closer to political agendas. When those shift, work sometimes has to change course. Product managers need to triangulate business needs, policy needs, and user needs.
Product teams don't own the policy, so product managers must be brave enough to argue with evidence and challenge where they need to. But it also means knowing when to get on with it. Both take resilience.
Without competition, there's a risk of complacency.
Product managers also have to push for real change. Something that has always been done one way ends up being digitised rather than reimagined. Starting with a shared problem, rather than a solution someone has already thought of, keeps that challenge open.
Departments are growing their own.
Product is a transferable skill set. People from policy, operations, and back-office roles have moved into product, and often bring a practical sense of what users go through.
How do teams stay autonomous when the stakes are high?
Give teams freedom over the what, and guardrails on the how.
Autonomy is still possible in government, but it’s autonomy within constraints. Those constraints are clearer and often bigger.
One useful split is between what a team does and how it does it. Teams get autonomy over the what. The how is shaped by guidelines, frameworks, and recognised good practice.
The higher the stakes, the clearer the guardrails need to be.
In the public sector, getting it wrong can mean real harm, not a refund. So the guardrails, frameworks, and safety checks around a team have to be clearer and more defined. Clear guardrails give teams the psychological safety to be as autonomous as possible inside them.
Standards work best when used in spirit, not as tick-lists.
Many teams want standards. They're a comfort blanket and help teams navigate public sector constraints. But they're written broadly for a reason. The aim is to show you're working in their spirit, not to tick off "10 rounds of user research, fully documented". A newer product practice might hold them tightly at first, then loosen up as it finds its feet.
Nowhere is this tested more than with AI.
What does AI change?
Products are moving from predictable to probabilistic.
Traditional software is predictable: the same input gives the same output, so you can test it and know what to expect.
AI products are different. Language models are probabilistic systems that work from the context they're given, and that context is always partial.
AI can also be confidently wrong, so it needs reviewing. That's why teams need new ways to measure success, assure safety, and deploy.
Example: AI scribes, which listen to a consultation and write the clinical note.
The panel discussed AI scribes for clinicians. Human notes can contain errors too, through dodgy handwriting or missing key points. A general practitioner (GP) might write two or three bullet points from a 15-minute conversation and miss things that matter years later.
It’s unusual to capture that human error or omission rate. The panel suggested it's probably higher than the AI's error rate right now.
Because AI tools capture the whole conversation, notes can include detail a busy GP would usually miss. That could prove useful to clinicians and patients in future care.
This is the level of thinking AI asks of product managers. It's not just whether the tool makes mistakes, but how its risks compare with the process it replaces.
Accountability stays with people, so you may need to add friction.
The clinician is still accountable for the note. They have to read it, and if something goes wrong, they're liable, not the AI.
After 99 accurate notes, it could become natural to just hit save, like accepting software terms and conditions. So teams are thinking about deliberate friction, or metrics that flag it. If someone saves a note five seconds after it was generated, did they really read a nine-minute conversation?
Inside product teams, AI is helping with:
👉 scoping and refining outcomes faster
👉 thematic analysis of user and market research
👉 comparing off-the-shelf products against broad requirements
👉 building knowledge bases before workshops with partners
But it also raises expectations. With AI, anyone can build a prototype overnight. Teams feel pressure to match that pace, from inside and outside their organisation. The answer goes back round the circle. You still have to speak to users and make sure it's safe, secure, and works properly.
Some departments are setting up AI councils, internal use policies, and teams focused on the ethics of AI in services for citizens.
The reality is that some people use AI for fun in the evening. Others are fearful of it or feel it has passed them by. Public services must be aware of this. Change teams have a big role in winning hearts and minds, so nobody gets left behind.
How do you prove impact without profit?
Success is harder to see, and can take decades.
Without revenue and profit, measures of success are more complicated. Some play out over a very long lifecycle. You might not see a trend for five, 10, or 20 years.
Measure in layers.
Teams start with the high-level mission, then break it down into granular measures they can capture through digital services. Processing something faster, or saving assessors time with a new tool, connects back to the bigger ambition.
Public services often have KPIs (key performance indicators) already, like delivering a service within a set time. Showing how a digital product meet service standards can be meaningful.
Define outcomes as you go.
Set and iterate your success measures as you build and deploy. Then test and learn: did the product achieve what you hypothesised? Usage and adoption are the core metrics.
Count access as impact.
This is where the first point comes back round. If a service becomes more accessible, more people know it's there and that it might be for them. Not all of them will qualify. But even a small rise in the number who do means more people getting something that helps them. Fewer complaints and better citizen satisfaction are signals too.
Let the stories show what the numbers mean.
Some of the most powerful evidence is human. Doctors using AI scribes say they can now put their children to bed every evening, because they're not staying late doing notes.
Is building products for the public really that different from building for paying customers?
The fundamentals of product don't change. The panel agreed that product means the same thing in both sectors. What changes is what's at stake. Leave people out, and they may miss support they rely on. Get it wrong, and people can be harmed. So the guardrails are clearer, the pace is slower, and the responsibility on product teams is greater.
What next?
Want to join us at the next one? Sign up to our newsletter or follow us on LinkedIn.
