Most of What We Call a ‘Service’ Isn’t One
Product in Service October 2025
Welcome
This is the Product in Service Month Note for October from Scott Colfer. Most product management guidance is for SaaS startups, this is for everyone else.
This month’s feature is on working on a understanding the landscape of a complex service.
Product In Service now in paperback!
My book ‘Product In Service: A Manifesto For Pragmatic Product Management’, is now available in paperback.
Thanks to everyone who bought a copy of the e-book and helping to make it the top-selling non-profit and charity book on Amazon at the end of its first week on sale.
Most of What We Call a ‘Service’ Isn’t One (and Why That Matters for Product People)
In government and the wider public sector, we’ve built our identity around “services.”
Digital teams design them, measure them, apply the Service Standard to them.
But most of what we call a service isn’t actually a service.
More often, the work we label as a “service” is really something else:
An experience (like applying, enrolling, or updating).
A capability (like payments, case management, or publishing).
Or a technology system (like a website or platform).
The Service Standard itself, our flagship guidance, is rarely been applied to a true end-to-end service. Most of the time, it’s applied to fragments: experiences, capabilities, or tech.
And that mislabelling matters. You can end up treating a website like a whole service, or expecting a tech platform to deliver a citizen journey.
Platforms
In 2015, when I first joined Digital Government, the identity of the profession was crystal clear. We were about citizens. The mantra was simple: design better digital services, create better experiences for the public.
But I wasn’t working on a shiny citizen-facing service. I was working on Cloud Platform, an internal capability. My job was running and evolving something that’s not visible to the public. At the time, there wasn’t much useful product thinking for this space. Everyone else was talking about journeys and front doors; I was knee-deep in infrastructure.
That tension never left me.
Seeing the Work Differently
A few years later, when I became more senior and joined the portfolio board, the picture widened. Looking across the whole digital portfolio, I realised something that changed how I saw the field: over two-thirds of the work was staff-facing.
Not citizen services. Not the big flagship websites. But publishing tools, case management systems, platforms, finance integrations — the less visible machinery of government.
The identity of Digital was rooted in citizen experiences. But the daily reality was far more complex, layered, and messy.
Stretching Product Thinking into Technology
This is where I first started pushing product thinking into “Technology.” It didn’t fit neatly. The metaphors were wrong. The tools assumed clean interfaces and end-to-end control. What I had was legacy technology contracts, patchy infrastructure, and processes built up over decades.
It was stretching. It took time. But eventually, we learned how to treat even these capabilities and technologies with product care. Iteration, roadmaps, user focus, service levels, long-term investment.
That’s when the penny dropped:
Most frameworks and models collapse when faced with this kind of work. They only operate if you can wipe the slate clean. But that’s not the reality in services.
In real services, you inherit fragments, fault lines, and layers built over time. You cross professions: policy, operations, IT, finance, design. No slate is ever clean.
From Clean Slates to Orientation
That realisation changed how I thought about product in service.
Instead of searching for the perfect framework, I needed tools that helped me orient in the mess. Tools that helped me see the ground under my feet, not imagine a new world from scratch.
That’s where the Service Landscape came in.
The Service Landscape
Think of services as a landscape. Each layer is part of the terrain. Together, they’re the ground we walk when we deliver to people.
Think of four layers:
Services: the mountains, the big promises an organisation makes.
Experiences: the paths people walk to access those services.
Capabilities: the tools, processes, and functions that make it possible.
Foundations: the bedrock: IT, data, infrastructure, governance.
Here’s the key: product rarely lives at the top of the mountains. It’s much more often in the paths, the tools, or the foundations.
The Layers in Detail
Services: The Mountains
Most organisations deliver a small handful of core services — usually between one and five. They are vast, multifaceted, and define both purpose and promise.
Examples:
Higher Education → Education, Research, Staff Operations
Local Government → Social Care, Education, Waste, Housing, Roads, Libraries
Civil Service (Justice) → Legal Aid, Prisons, Probation, Courts & Tribunals
Charity → Advocacy & information for a marginalised community
These are the mountains of the landscape — visible from afar, shaping everything around them.
Reality check: product work rarely lives here. You don’t see Chief Product Officers running entire mountain ranges. Most of us work further down the terrain on experiences, capabilities, or foundations.
Experiences: The Paths
Experiences are the paths people actually walk. They aren’t “products” by default, but they can be managed like products: they have users, flows, outcomes, and pain points.
Patterns that repeat across services:
Pre-service: awareness, eligibility, application
During: use, participation, updates
Post-service: follow-up, feedback, closure
Verbs that give them away: Explore. Apply. Enrol. Receive. Manage.
These verbs reappear across sectors. That repetition makes experiences a prime candidate for product thinking — not because they’re shiny, but because they’re patterned and improvable.
Capabilities: The Tools & Shelters
Capabilities are the functions an organisation needs to deliver its services. They’re the tools and shelters scattered across the landscape.
Examples:
Make a payment
Confirm identity
Manage cases
Send notifications
Store or retrieve documents
Each capability can be delivered by people, processes, or technology. Some are fragile and bespoke; others become repeatable, standardised . . . even platformable.
A capability becomes a product when it’s reusable, stable, and intentional.
If others depend on it, and you run it with investment, service levels, and roadmaps, then it’s not just a function, it’s a product.
This is especially powerful in large federated organisations, where platformed capabilities provide coherence across the whole landscape.
Foundations: The Bedrock
Foundations are the underlying conditions that enable or constrain everything above. They’re often invisible until they crack.
Examples:
Processes & operating rules: back-office workflows, escalation paths
IT & infrastructure: hosting, networks, devices, integration layers
Data & records: systems of record, quality, interoperability
Policy & regulation: statutory obligations, compliance frameworks
Funding & governance cycles: budgets, approvals, audits
Procurement & contracts: suppliers, SLAs, commercial terms
Weak or rigid foundations mean paths crumble, tools break, and mountains become inaccessible. They’re rarely glamorous, but they are decisive.
A Website in the Landscape
I tested this with a team facing a familiar problem: a website rebuild. The contract was expiring, the tech was dated, and something had to change.
Looking at the landscape together, they noticed a few things:
Foundation (output-driven project): In budgets and portfolios, it was framed as a simple website rebuild. That makes it a foundational project — just tech work. But their division had been set up to avoid output-driven projects.
Experience (change programme): Senior leaders described it as a chance to create the mythical “single view of the customer.” That made it an experience-level ambition — redesigning silos and journeys. Visionary, but unrealistic within the scope and timeline of a website contract.
Capability (stretch but achievable): What felt stretching yet realistic was to focus on internal publishing. Treat publishing as a capability, and consciously design it as a platform. That meant blending tech (a CMS staff could actually use) with change (better ways of working for content creators).
The Service Landscape didn’t solve the problem. But it helped the team see where they thought they were, spot when they were in the wrong part of the map, and align on where they actually should be.
Over to you
Services are landscapes: messy, inherited, full of fault lines. We can’t wipe the slate clean. But we can orient ourselves.
That’s the power of the Service Landscape. It’s not a framework. It’s a compass. A way to see where you are, and align on where you should be.
Where do your “products” really sit in the landscape? And where should they?
My Upcoming Public Talks
How to Win at AI Without Talking About AI (much) 24th October 15:30 (pre-recorded talk forAI Week 2025)
September’s Notes & Talks
Product in Service: Making “Product-Centric” Approaches Work in the Real World (recording of a talk for Blackmetric)
Demystifying Product Management (recording of a talk for Leeds Digital Festival)
Using AI Without Losing Yourself (blog post)
Why Discoveries Fail (and How to Stop it Happening to You) (blog post for Herd Consulting).
Thanks
That’s it for October, thanks for reading.
I’d love to hear your experiences of product management in the public sector, you can comment below or connect on LinkedIn.
See you in November,
Scott
Incredibly supportive of this framing. Thanks so much for sharing.