Making Product Work in Public Services

If you want to adopt the product playbook, you need to change how the game is played

When I began working in the public sector almost a decade ago, I came from a product design background. I’d seen what empowered teams could do and was convinced that public services would benefit from:

• Tighter feedback loops that connect investment to public impact

• Stable, empowered teams that can learn and adapt

• Transparent trade-offs that build trust across policy, operations, and delivery

• Co-shaping between tech and policy that keeps services grounded in reality, not theory

In many ways, that promise has taken root. I’ve seen multidisciplinary teams form, roadmaps replace project plans, user research and discovery become routine, agile rituals spread across departments.

Yet it’s still rare to find true product ownership and leadership.

Public organisations are built for programmes, policy cycles, and procurement gates - not for continuous learning. As John Cutler writes, product-centricity depends on an economic logic that government simply doesn’t have.

So the question isn’t whether being product-led matters; it’s how to make it work inside systems designed for something else.

The organisational mismatch

Product companies sit close to their source of value. They sell the very software they invest in. Money, feedback, and impact flow in tight loops: build something, release it, see the numbers move. When those loops tighten, it’s easy to justify investment and learn what works.

Public services operate in a completely different economy.

Their impact is collective, not just transactional. Outcomes are slow, diffuse, and often political. Funding comes in waves through policy cycles, not revenue. The technology is rarely the product; it’s the infrastructure that enables human and policy systems to work.

So when governments try to “go product”, the structure can’t support it. Projects are still how money moves, leaders still plan in programmes and teams still need permission for decisions that real product teams make every day.

The result is what Cutler calls the translation layer: agile language sitting on top of old funding and accountability models.

When programme delivery meets product leadership

So much has happened by the time a “digital refresh” actually begins. Multiple business cases have been written, approvals secured, suppliers lined up. So by the time the money is allocated and teams are in place, the pressure is on and everyone expects visible progress fast.

That’s how product work in the public sector usually starts: high urgency, low clarity.
Teams are told to “get on with it,” as they walk straight into assumptions that have never been tested with users or operations. Every discovery feels like a delay because it challenges something already promised.

From a programme lens, this looks like “hiding behind Agile,” slowing progress and being cagey about what teams can really deliver.

From a product lens, this is the work: testing, reframing, uncovering the problems left out in the business case to define the actual scope.

Programme delivery is built for predictability; product leadership is built for adaptation. One manages commitments upward; the other manages learning outward.

When they meet without shared understanding, the result is frustration on all sides: programme teams see endless iteration, and product teams see endless interference.

Product disciplines challenge the status quo

Product thinking demands that organisations choose priorities and make trade-offs visible. It asks uncomfortable questions: which outcomes matter most, what are we not going to do, and who decides?

It brings tech and operations closer to the table - people who actually build and run things - which threatens the existing hierarchy.

In most public bodies, technology is still treated as a cost centre. Operational staff are rarely participants in “digital transformation” and often casualties. Decisions are filtered through programme boards or political priorities.

Silos keep everyone safe because they keep accountability fragmented. Product disciplines undo that safety.

They give delivery teams a language for value and impact. They expose duplicated effort and hidden dependencies. They make it harder to hide behind “the minister wants it.”

Adopting product ways of working often feels like a power struggle, because it is one.

Shared accountability goes both ways

However the issue isn’t just resistance to product ways of working.

In-house product and design teams, often set up to model “modern” delivery in complex conditions, can become just as doctrinaire as the programme structures they oppose. When teams become frustrated and feel undermined, they can fall into a defensive posture, holding fast to rituals and textbook definitions.

They aren’t set up to empathise or address the constraints their counterparts operate under, such as funding cycles, supplier contracts, and political promises already in motion.

The result is two sides each guarding their own version of “the right way to deliver,” both convinced they’re protecting value, and both cutting off the collaboration needed to find it.

What’s missing isn’t conviction, but shared accountability.

Product disciplines should challenge power, but not hoard it. They work best when they widen the circle of evidence and invite others into the decision.

The goal isn’t to win the argument between programme and product, but to build a practice where learning can travel upwards as easily as authority travels down.

What needs to change

If public services want the benefits of product disciplines, they have to change both how they deliver and the conditions that surround delivery.

It’s not just adopting new rituals, but building shared understanding across people who hold different kinds of power.

Ways of delivering

1. Work with live evidence, not abstract business cases
   Insight means little if it’s confined to a single discipline. Bring policy, operations, and delivery together to look at evidence and decide what it means. The work is not gathering data, but agreeing on what it tells you.

2. Build stable, cross-boundary teams

   Continuity of people, not just funding, is what allows trust and translation to form. Product and programme expertise should sit side by side long enough to understand each other’s pressures.

3. Balance autonomy with alignment
   Teams need room to act, but within a clearly owned service and shared direction of travel. Service ownership provides coherence; teams provide motion. Both depend on each other.

4. Synchronise rhythms of planning and reflection
   Policy cycles, programme reviews, and product iterations often run on different clocks. Align them so evidence and decisions can meet in time to matter.

Conditions for delivery

1. Leadership that strives for clarity
   Leaders need to set clear, purposeful priorities while making it safe for others to experiment and adapt. That means being precise about goals, not just ‘being more efficient,’ but defining what it actually means.

2. Mutual respect for different forms of expertise
   Policy, operations, design, and technology each hold a different truth about how the service works. Delivery improves when those truths can coexist rather than compete. It’s a requirement for truly shared outcomes.

3. Fluent translation
   Product teams must make evidence and trade-offs legible to decision-makers, not just tick methodology boxes. Programme and policy leads must reciprocate by making constraints transparent early on.

4. Psychological and political safety for learning
   Learning often looks like slowing down. Leaders need to model curiosity over certainty, speak to problems rather than glossing over them and protect the space where uncomfortable findings can be surfaced.

Real progress happens when product and programme people learn each other’s pressures: when product teams translate learning into language that can survive governance, and when programme leaders make space for learning before committing to scope.

Service ownership as the connective tissue

This is where service ownership helps.

It gives teams a shared horizon and connects those learning loops across the system.
A service owner’s role is to keep purpose, policy intent, delivery reality, and operational performance connected: to give product teams the clarity and boundaries they need to learn safely.

It requires leadership that can define and hold value. Leaders who can say what a service is for, who it serves, and how they’ll know it’s working, make it possible for product and service teams to align their learning around something real. Without that, every part interprets '“efficiency” and “modernisation” however it aligns with their remit.

When someone is responsible for the whole, teams can focus on their part without guessing how it fits. Service ownership helps turns product autonomy from a risk into a collective responsibility.

Public services don’t need to become product companies

They need to become learning organisations that use product disciplines to stay responsive while protecting legitimacy and care.

The real work is not “going agile” or “funding teams.” It’s building the conditions where evidence can challenge power, where people can act on what they learn, and where accountability scales from features to outcomes that matter to the public.

When you import product thinking without changing structures or incentives, you get theatre. When you adapt it to serve public purpose, you get transformation that actually works.

Beneath the shift from “projects to products,” we should be enabling a deeper one of technocracy to stewardship: building organisations that can both deliver and care.