The GDS Service Standard: What Commercial Software Teams Can Learn From It
What the UK government's 14-point Service Standard asks for, how it maps to commercial product work, and practical ways to apply it without bureaucracy.
What can commercial teams learn from the Service Standard?
The Service Standard is the UK government's 14-point checklist for building and running public services. Its core ideas apply to any digital product: understand users and solve their whole problem, make the service simple and accessible, use a multidisciplinary team and iterate, choose technology deliberately, define success and measure it, and operate reliably. Commercial teams can adopt it as a lightweight phase-review checklist without the formal assessments government uses.
This guide is for product managers, designers and engineering leads at commercial software companies and agencies.
The 14 points, grouped
The points are published in the GOV.UK Service Manual. Grouping them makes them easier to use.
| Group | Points | Commercial equivalent |
|---|---|---|
| Users | 1 Understand users and their needs; 2 Solve a whole problem for users; 3 Provide a joined up experience across all channels; 4 Make the service simple to use; 5 Make sure everyone can use the service | User research, journey mapping, omnichannel design, usability and accessibility |
| Team and ways of working | 6 Have a multidisciplinary team; 7 Use agile ways of working; 8 Iterate and improve frequently | Cross-functional product teams, short cycles, continuous delivery |
| Technology and data | 9 Create a secure service which protects users' privacy; 11 Choose the right tools and technology; 12 Make new source code open; 13 Use and contribute to open standards, common components and patterns | Security and privacy by design, deliberate architecture, design systems, open standards |
| Outcomes and operations | 10 Define what success looks like and publish performance data; 14 Operate a reliable service | Product metrics, SLOs, incident management |
Phases: discovery, alpha, beta and live
The Service Manual describes four phases. Commercial teams can use the same gates to stop investing in ideas that do not work.
| Phase | Question to answer | Exit evidence |
|---|---|---|
| Discovery | Is there a problem worth solving, for whom? | Research findings, risks, a recommendation to stop or continue |
| Alpha | Which approach works, and is it feasible? | Tested prototypes, technical spikes, a plan for beta |
| Beta | Does the working service meet needs at scale? | Usage data, accessibility audit, security testing, support model |
| Live | Are we running and improving it well? | Performance against targets, incident history, roadmap |
A lightweight phase-review checklist
- Who are the users, and what evidence do we have about their needs?
- Are we solving the whole problem, including offline and support steps?
- Can people with access needs use it? Have we tested with assistive technology?
- Do we have the skills we need on the team, including research and design?
- How often do we release, and how do we learn from each release?
- What are the security and privacy risks, and what have we done about them?
- Why did we choose this technology, and how will we exit it if needed?
- What does success look like, and how are we measuring it?
- How will we run it: monitoring, support, incident response?
Where commercial products differ
Some points need adapting. Publishing performance data and opening source code suit public services; commercial products may share selected metrics with customers and keep code private. Commercial teams also balance user needs with revenue and competition. The underlying discipline still applies: evidence over assumption, accessible by default, small iterations and reliable operation.
Hypothetical example: a B2B scheduling product
This example is hypothetical. A SaaS company planning a new scheduling module adopted the checklist for phase reviews. Discovery interviews showed that customers' real problem was rescheduling, not booking, so alpha prototypes focused there. A beta with ten customers included an accessibility audit and a defined success metric (reschedules completed without support). Two planned features were dropped after alpha.
Common mistakes
- Treating the points as paperwork rather than questions.
- Skipping discovery and alpha for a full build.
- Leaving accessibility to a final audit.
- Measuring outputs (features shipped) instead of outcomes.
Sources
Conclusion
The Service Standard is a clear, free description of good digital delivery. Commercial teams can use its points as phase-review questions and its phases as investment gates, adapting the points on open code and published data. For research methods, see user research methods, and for public sector bids, UK public sector software procurement.
Want a discovery and alpha before committing to a build?
ZSpace Labs is a remote-first technology studio that works with clients globally on research, service and interface design and product engineering. If it would help to plan a phased approach, we are happy to talk it through.
Common questions.
A set of 14 points, published in the GOV.UK Service Manual, that government teams use to create and run good public services, covering users, teams, technology and operations. Central government services are assessed against it at key phases.