A white label product management handbook for government digital services
View the Project on GitHub scottcolfer/product-management-handbook
A ‘product’ is something that is manufactured, purchased, owned and used by a customer. Think of a bar of soap: it is a ‘true’ product in this sense.
Product management in government is applied to public services and features of public services, not products. This move from genuine products to services is shared by lots of product managers, who find themselves providing services via the internet instead of physical goods. Think about the move from renting DVDs from Blockbuster to the market-domination of Netflix, for example.
We hear a lot about ‘end-to-end’ public services but what does that mean in practice? Several people have already provided us with excellent ways to understand this. Here are three principles to help us think about ‘end to end services’, based on posts published by Louise Downe and Kate Tarling.
Principle 1: a service helps a user to do something that needs to be done
To a user, a service is simple. It’s something that helps them to do something - like learn to drive, buy a house, or become a childminder. It’s an activity that needs to be done.
This isn’t always how government sees a service. Government sometimes sees services as discrete transactions that need to be completed in a particular way, like ‘Statutory Off Road Vehicle Notification (SORN)’.
‘Learn to drive’ describes a service. ‘Statutory Off Road Vehicle Notification (SORN)’ describes a transaction.
Reading: Good services are verbs, bad services are nouns Louise Downe
Principle 2: a service name starts with a verb
A core principle of Agile and Lean theory is that services should seek to maximise value. Services should be judged not on their adherence to cost and delivery schedules, but on their delivery of value.
When a service name starts with a verb like ‘Learn to drive’ it tends to focus the attention on value. It describes a thing a user needs to do.
When a service name starts with a noun like ‘Statutory Off Road Vehicle Notification (SORN)’ it tends to focus on a transaction. It describes something the government does.
Reading: Good services are verbs, bad services are nouns Louise Downe
Principle 3: Use the term ‘service’ accurately and sparingly
Lots of our ‘services’ aren’t really services. ‘Learn to drive’ is an end to end service. The elements needed to learn to drive probably think of themselves as services in their own right. However, none of them independently meet the overall need to ‘learn to drive’. So they are not service, they are a part of a service, or a ‘feature’ of a service.
Services A service helps a user to do something that needs to be done. It also helps government achieve policy intent on behalf of its citizens with whom it has a social contract. Services are best identified as verbs (visit the UK), rather than nouns (biometric residence permit).
The following are not services - they are things that help to build services:
Features Often the things we work on are just one step in a service. These are called features, and examples include:
Capabilities and activities
A capability is having all resources required to carry out a task – such as skilled staff and specialist tools – and also considers capacity and maturity. Appointment booking, for example, is a capability that requires:
Activities are the things people do in relation to using a service, including:
Technology
‘Technology’ means the digital systems, products, tools, hardware and applications we build, maintain and buy. Technology exists to support activities and capabilities – and enables us to deliver faster, clearer, simpler services.
Data
Data means the actual information that’s either generated by or used to carry out activities and services. Use descriptive words for data, such as ‘National Insurance number’, and avoid acronyms.
Reading: Creating a common language to describe services Kate Tarling
This helps us to understand where product management is most useful, and where it it less useful. Public services and features of public services in which value is measured by outcomes for users are places where product management is value. Capabilities like technology where value is measured by the service level of the technology are places where product managers should acknowledge that they are not the experts, since the focus is on quality and workflow. Professions like IT Service Management may be much more capable of working in these delivery conditions.
The title of ‘product management’ can obscure what it is that we do. Logic would dictate that if there is a product . . . and it is managed . . . then that person is a product manager. However, there are at least three contexts for management - value, workflow, and quality - and product management describes the management of one of those contexts: value.