Previously, we wrote about the need to test a different way of improving complex public services. NewCo is a transformative new way of working - it's about creating bounded space for small, multidisciplinary teams to look at a service differently.

Quick recap on CustomerFirst

Many public service transformation programmes begin with a solution. A technology platform is selected, a target operating model is designed and delivery teams are mobilised. Yet despite significant investment, outcomes can fall short — because the constraints that really shape performance sit across organisational boundaries and are rarely tackled together

We established Customer First to try a new approach; radical improvement to services through taking a whole system view. That means looking beyond technology to the policies, incentives, processes, data, culture and organisational behaviours that shape customer outcomes. In many cases these wider factors are much more important than software.

This perspective has shaped how we have structured ourselves and how we approach service improvement. Rather than assuming every problem requires a large-scale transformation programme we start by testing whether meaningful change is possible. exploration sprints are one way of doing that.

Sometimes an exploration sprint confirms that the opportunity is significant, but that progress is constrained by barriers that sit across organisational boundaries. In these cases, the evidence may point towards our NewCo approach; creating the focus, governance and freedom needed to deliver change across a wider system.

All of this raises an obvious question for CustomerFirst: how do we know whether a service is ready for this kind of end-to-end improvement approach before committing significant time and resource?

That is the purpose of an exploration sprint.

What is an exploration sprint?

An exploration sprint is a short intervention to identify opportunities for meaningful service improvement and whether there is sufficient organisational appetite, alignment and partnership potential to realise them through adopting a NewCo model.

Typically lasting around two weeks, the sprint is designed to:

• rapidly surface system constraints
• identify an aspect of a service suitable for experimentation
• test leadership appetite for working differently
• avoid committing major resources too early

It is not an audit, consultancy review or discovery.

Rather than exploring user needs from scratch, it asks a prior question: are the conditions in place to make improvement viable at all?

Looking at how the system behaves

One of the recurring patterns in transformation is that programmes are often designed around assumptions of a future state before enough is understood about how the current system behaves today.

Frontline workarounds. Governance bottlenecks. Policy ambiguity. Risk culture. Supplier dependencies. Fragmented ownership.

These things shape customer outcomes every day but often remain largely invisible at programme level.

Exploration sprints are designed to expose some of those realities early, not through months of analysis, but through direct engagement with leaders, frontline staff and the flow of work through the system.

In practice, organisations often discover that the:

• apparent problem is not the real problem
• real constraint sits outside technology
• highest value opportunity is somewhere different from where the programme originally expected

What happens during the sprint?

Week one focuses on understanding the current service:

• demand and complexity
• operational performance
• high level journeys
• leadership and frontline perspectives: senior buy-in
• policy fit
• visible constraints

Week two focuses on viability:

• narrowing down recurring constraints
• identifying a specific service slice suitable for test and learn
• assessing organisational readiness
• developing a recommendation on whether to proceed further

The output is intentionally concise, usually a short readout covering:

• service context
• constraints
• candidate areas for experimentation
• organisational readiness
• recommendation

Our goal is to create enough shared understanding to make a better decision about whether to move through to delivery.

Thin slices, not wholesale redesign

An important idea behind exploration sprints is that improvement does not always require large scale redesign. Instead, we look for thinner parts of a service where different ways of working can be tested quickly and safely.

That might involve:

• reducing friction in a customer interaction
• testing a different operational process
• changing how evidence is gathered
• exploring whether policy assumptions hold true in practice
• creating new ways for policy, operational and digital teams to work together around live outcomes

The aim is to learn whether targeted intervention changes system behaviour in useful ways.

Learning before certainty

Traditional transformation often seeks certainty before action. But in highly complex services, certainty is frequently unavailable until the system is placed under real-world pressure.

Exploration sprints accept that reality because they create a lightweight way to test whether a different approach to improvement is genuinely viable before organisations commit significant funding or energy.

Improving complex public services is rarely about producing the perfect plan upfront. It is about creating the ability to learn, adapt and improve faster than the system currently allows.

Why organisations use exploration sprints

An exploration sprint provides a low cost, low commitment way to build evidence before making larger investment decisions. It creates a shared understanding of the problem, uncovers hidden constraints and identifies practical opportunities for improvement. Leaders get a clearer view of where effort and investment will have the greatest effect, rather than committing to a major programme before the real picture is understood.

For CustomerFirst, exploration sprints are a foundational part of how we work. Before we ask an organisation to commit to a test and learn phase, we want to be confident that the conditions for meaningful improvement actually exist. That means understanding the system and making sure the work we do together is pointed at the right problem from the start.

If you lead a service facing these challenges and want to explore whether an exploration sprint could help, you can find out more about CustomerFirst (opens in new window) and how we work.