1 Where did this handbook come from?

Product management can be a vague profession, unclear to those of us doing it and misunderstood by our
colleagues. Some aspects of our role may be legitimately difficult to write about but a lot of our knowledge
is suitable to be made explicit through documentation. The first version of this handbook was created by
Scott Colfer as an attempt to document the role of product management for the Ministry of Justice. This
white label version has been created shared by Scott to see if the handbook has value for other government
digital services.

Context is everything. This handbook is intended to help us understand what product management looks like
within public services - rather than claiming to describe the entire product management profession.

Product management is a big topic. This handbook is meant to be the beginning of a conversation, not the
final word - it’d be great if this handbook looked different a year from now because we have used it, tested
it, and improved it based on our experiences.

The main gaps in this version are more detailed guidance for senior product managers and lead product
managers, along with more work to link directly with the capabilities and levels of mastery required of our
profession

Sharing is important. Much of this handbook is based on the work of others and their willingness to share, so
it is important that we do the same. Hence publishing this handbook in the open.

2 Who is this handbook for?

This is intended for government digital services. It’ll probably be a close-fit for UK product management
communities working to the digital, data and technology role description but will hopefully be of use for
local authorities and international government digital services too. Shout if you find it to be of use in any
other contexts.

Please consider improving the value of the handbook - we only know what we know, so it’d be great to get
the insight of others. Please comment on this document if you spot a way to improve it. This could be
something you find helpful that you’d like to add, or a refinement to something already in here. Anything
that you think will make it more valuable. You can comment and suggest improvements via Github.

3 About the author

Scott Colfer is a product leader with over a decade of experience working on products and services with a
social mission, ranging from startups to large enterprises, and spanning commercial, non-profit, and
government sectors. Scott is Head of Product for the Ministry of Justice, proudly supporting the digital
transformation of the UK’s public services.

Online profile - Twitter

4 Product management is responsible for value

Our teams require at least three perspectives if they are to work well:

Value - Workflow - Quality

This is true of delivery teams, management teams, and leadership teams.

Product management’s focus is optimising value, and so is most useful to an organisation when we are given
responsibility for value. We need to understand workflow and quality but equally need to acknowledge that
they are not our strengths and that others will be better at them than us. We’re only useful as a profession
when we understand our relationship with other professions.

Value Workflow Quality

Value professionals are
Workflow professionals are
responsible for improving the Quality professionals are responsible
responsible for the workflow of
value of things but still need to for the quality of things but need to
teams and departments but need
understand workflow and understand value and workflow
to understand value and quality
quality
Value professions include Workflow professions include Includes lots of professions, all those
product management, business delivery management, project that ‘do’ and ‘build’, e.g. developers,
analysis, economic analysis, management, programme technical architects, designers,
portfolio management management communication, training, service desk

Reading: Roles in production systems Melissa Perri, Dan North, Joshua Arnold, Georg Fasching

5 We run things like mini-businesses

Let’s explore what it means to be ‘responsible for value’.

Product managers run ‘things’ like they are mini-businesses, with the goal of optimising the value of that
‘thing’. The ‘things’ we work on tend to be public services or features of public services. Our role is to
increase the value of services and features by focussing on outcomes (not outputs).

Product managers make promises to solve problems (not commitments to specific solutions or features).
People tend to think about problems through existing solutions so organisations need people who are
passionate about problems over solutions, and focus on outcomes over outputs.

Organisations sometimes discuss problems through solutions, which may lead to solutions being agreed that
don’t solve the real problem (or solve the wrong problem). The product management profession provides a
space to focus on the problem to be solved, agnostic of the specific solution.

Teams and team members can sometimes get stuck in their own specialisms, and can benefit from someone
who is focussed on the overall, common goal that allows prioritisation of time and effort.

Reading: The First Principles of Product Management Brandon Chu

6 We manage the value of public and staff

services
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:
  applying for a visa
 applying for a licence
 granting or refusing permission.

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:

 an appointment booking system, which may be a technical capability

 physical locations or phone support to host the appointments
 a process for changing or cancelling appointments.

Activities are the things people do in relation to using a service, including:

 finding out how something works

 calling people for help
 applying for something.

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.

7 Origins of the role of Product Manager

Why are we called ‘product managers’? Product management has existed since at least the 1930s and grew
from ‘brand management’. Companies like Proctor and Gamble had many brands of the same product and
had typically focussed on their market leader and ignored the others. They decided to start running each
brand like a mini-business in its own right, led by a brand manager, and profits increased as a result. Product
managers looked after genuine products, like soap, when the profession started, hence the title ‘Product
Manager’.
Reading: The History and Evolution of Product Management Martin Eriksson

The Scrum Framework published in 2002 took the Agile Manifesto for Software Development, and tried to
define what Product Management looked like when purely applied to a software development team. The
resulting role is called ‘Product Owner’. This role is useful for junior Product Managers working in Scrum
teams but does not cover the full scope of product management. Unfortunately, many people confuse the
Product Owner role and the Product Manager role, which can sometimes pigeon-hole product management
within software development teams. In reality, product management is a business strategy role that optimises
the overall value of a ‘thing’: this is as likely to involve marketing and communication as it is to involve a
software development.

Reading: The product manager is dead. Long live the value manager Scott Colfer

8 We have publicly available role descriptions

You can find and use product manager role descriptions and career pathway published on GOV.UK.

These product manager role descriptions and career pathway were created by UK government’s Heads of
Product between August and November 2016, using feedback from their communities to help incrementally
improve them during this time.

These role descriptions suggest that product management requires seven essential skills:

1. Product ownership - Uses a range of product management principles and approaches. Captures and
translates user needs into deliverables. Able to define the minimum viable product and make
decisions about priorities. Writes stories and acceptance criteria. Capable of working with a range of
specialists in multidisciplinary teams.
2. Product lifecycle perspective - Understands the different phases of product delivery and is able to
contribute to, plan or run these. Able to maintain a product or process through the delivery phases,
through to live and into retirement. Able to lead a team through the different phases of the delivery
lifecycle. Can maintain and iterate a product over time to continuously meet user needs. Understands
and is aware of incident management and service support so that products are built effectively.
3. Agile working - Is aware of and understands agile methodology and how to apply the agile mindset
to all aspects of their work. Has the ability to work in a fast paced, evolving environment and utilises
an iterative method and flexible approach to enable rapid delivery. Unafraid to take risks, willing to
learn from mistakes and appreciates the importance of agile project delivery for digital projects in
government. Able to ensure the team has a situational awareness of what each other is working on
and how this relates to practical government objectives and user needs.
4. User focus - Understands users and can identify who they are and what their needs are based on
evidence. Able to translate user stories and propose design approaches or services to meet these
needs and engage in meaningful interactions and relationships with users. Puts users first and can
manage competing priorities.
5. Problem ownership - Understands and identifies problems, analysing and helping to identify the
appropriate solution. Is able to classify and prioritise problems, document their causes and
implement remedies.
6. Strategic ownership - Focuses on outcomes, not solutions. Is bold - develops ambitious visions and
strategies. Gets the organisation and team to buy-in. Translates the vision into prioritised deliverable
goals.
7. Operational management - Able to manage the operational process of designing and running a
product or service throughout its entire life-cycle. Able to implement best practice in new product or
service development and knows how to plan and operationalise the stages of new product or service
 development. Able to overcome operational constraints to deliver a successful product or service.
Works closely with other operational delivery teams.

We can measure our performance in each of these capabilities using our level of mastery:

 Awareness - Has knowledge of the skill and an appreciation of how it is applied in the environment
 Working - Applies knowledge and experience of the skill, including tools and techniques, adopting
those most appropriate for the environment
 Practitioner - Shares knowledge and experience of the skill with others, including tools and
techniques, defining those most appropriate for the environment
 Expert - Has knowledge and experience in the application of this skill. Is a recognised specialist and
advisor in this skill including user needs, generation of ideas, methods, tools and leading or guiding
others in best practice use.

These role descriptions are not infallible and not set in stone. They are published on Github and we can
submit requests to change them if we see ways to improve them.

9 The career pathway for product managers

The career pathway for product managers is: Associate Product Manager → Product Manager → Senior
Product Manager → Lead Product Manager → Head of Product Management

We can think of this as two main stages of our career, with smaller steps in between: product management,
and product leadership.

Product management
The journey to become a product management practitioner, taking our level of mastery from awareness, to
working, to practitioner. A strong product management practitioner will have learned and understood the
core concepts of product management - not just at the level of practices but also the underlying principles,
allowing both application and innovation. During this stage in our career we are likely to be focussed on
‘delivery’ teams.

Associate Product Manager Associate Product Manager is a training role. Associates are moving from
awareness to working level product management. Associate are associated with a more senior product
manager and focus on the tactical concepts of product management. This is where a lot of the basic, tactical
skills of product management are first learned and might involved helping a small feature team to prioritise
user needs and help them translate them to actions for the team using a backlog. The Scrum Product Owner
role is a helpful model for Associate Product Managers to use.

Product Manager Product managers move from working to practitioner product management. Product
Managers are often responsible for the overall value improvement of a feature of a public service (often a
software feature), or (more rarely) an end-to-end public service or staff service. Product Managers take
responsibility for broader product strategy by defining the problem statement and value proposition, building
a vision for an improved, future value proposition, and creating the strategy for how to get there. We may
provide this product strategy to an Associate Product Manager, who will help the team to figure out what
this looks like in practice, and provide challenge where needed. This is where a lot of the strategic skills of
product management are first learned.

Product Leadership
We don’t suddenly learn some magic new product management skills when we become a Senior Product
Manager. We learn all of our core product management skills within the Associate Product Manager and
Product Manager roles. Senior, Lead and Head of Product Management are about learning and adding
leadership skills to our abilities, and this is at the heart of what the move from practitioner to expert mastery
means. We still have the ability to ‘get our hands dirty’ and use our product management skills, but they’re
often used to apply product management at scale or to promote product management through example.
We’re increasingly likely to be managing value within middle-management or leadership teams, rather than
delivery teams. We’re also responsible for the performance management, support and development of the
members of our profession.

We’re often working in space in which we have influence, not authority: we’re being asked to support
business strategy and digital transformation but are not solely responsible for the outcomes and often not
playing a lead-role in this work. This means that the ‘soft-skills’ of teaching, mentoring, coaching and
facilitating are hard. Our colleagues responsible for workflow are likely to have more mastery than we have
within our profession, and may become key allies in our professional development.

Senior Product Manager Senior Product Managers can be thought of as ‘group product managers’. They
manage a group of ‘things’ that share commonalities, users, or interdependencies. For example, there may
be a grouping of things around sign-on, and a Senior Product Manager might provide the overall value
strategy for 2-5 things in this space. Senior Product Manager is an interesting point in our career pathway, as
it is the tipping point between product management and product leadership: we’re still expected to work
directly within delivery teams, but also expected to work with our Lead Product Manager to influence and
support overall strategy for our business unit and our profession.

Lead Product Manager Lead Product Managers can be thought of as ‘heads of product’. They head-up an
entire area of product management. Currently this is often implemented according to our internal
organisation, so we have a Lead Product Manager for each of our agencies/delivery arms/programmes,
responsible for the overall value of our work for that area of the business. In the future it may be that we
divide our portfolio around different value propositions such as public-facing services, staff-facing services,
core technology, and consultancy, with a Lead Product Manager heading up each area. Lead Product
Managers are product leaders, taking the product manager skills they learned in delivery teams and applying
them within management and leadership teams. They’re likely to be responsible for the value strategy for 3-
10 delivery teams, embeded with a management or leadership team and are less likely to work directly
within a delivery team. They are also a leader for their own product management community.

Head of Product Management Our implementation of Head of Product Management might often be
described as ‘Director of Product’ elsewhere. Product management is often described as a role which is
about influence, not authority. Head of Product is no different:

 Head of Profession: The space where you have clearest responsibility and authority is that of the
product profession itself. You are responsible for the the performance of the product management
profession and the product managers within in. This includes owning and improving the role of
‘product manager’ itself, plus the recruitment and performance management of product managers.
You are the most senior representative of the profession, responsible for making sure that it meets
the needs of our colleagues - which sometimes requires challenging assumptions about the role and
supporting the use of other professions.
 Head of Product: Product managers within government are responsible for the value of public
services or the features of public services. You are a senior representative of value strategy in your
role as Head of Product. Government is still unfamiliar with product management and its application
outside of delivery teams, within management and leadership teams (we are seeing our first Directors
of Product and Chief Product Officers being hired in government departments). As a result of this,
you will need to seek opportunities to support and influence value strategy at an organisational level
and are unlikely to be given clear authority.

Reading:
  Busting a digital myth: the naturally gifted product manager Lois Schonberger et al
 Product Management Job Titles and Hierarchy Martin Eriksson

10 Tool: Product management career pathway

diagram
The following diagram is an attempt to summarise product management career progression, to help us locate
where we are now and where we’d like to go next.

Let’s look at the sections of the diagram and explore what they mean:

Product Management Practitioner The Associate Product Manager and Product Manager roles increase
our mastery of the product management capabilities from awareness, to working level, to practitioner. We
will have learned and understood the core concepts of product management - not just at the level of practices
but also the underlying principles, allowing both application and innovation.
Product Management Expert The ability to ‘get our hands dirty’, continuing to manage products, with a
focus on promoting product management craftsmanship through example and teaching by doing. Also
expertise in applying product management at scale. We need to develop broader leadership skills too:

 Business Strategy - The ability to apply business strategy and management frameworks to employ
agile as a competitive business advantage such as Lean Start-Up and Lean Enterprise, product
innovation techniques, flow-based business process management approaches, and other techniques
that relate to innovating in the business domain
 Digital Transformation - The ability to facilitate, accelerate and (as appropriate) lead organisational
change and transformation. This area draws on change management, organisation culture,
organisation development, systems thinking, and other behavioral sciences.

The value of product management expertise, business strategy and digital transformation is often released
via ‘soft skills’ such as mentoring and teaching, coaching and facilitating. Workflow professionals may
often be the experts in these skills within our teams, but the skills remain important for product managers
too.

 Teaching - The ability to offer the right knowledge, at the right time, taught in the right way, so that
individuals, teams and organisations use the knowledge for their best benefit.
 Mentoring - The ability to impart your experience, knowledge and guidance to help develop other
product managers.
 Coaching - The ability to act as a non-directive coach (with the coachee’s interest determining the
direction, rather than your own expertise or opinion).
 Facilitating - The ability to act as a neutral process holder, guiding and
individual’s/team’s/organisation’s process of discovery, holding them to their purpose and definition
of success.

11 Training in the core, tactical principles and

skills of product management
Associate Product Manager is where some of us start our career as a product manager, and where we learn
the core, tactical principles and skills of product management. It can also be thought of as ‘Trainee Product
Manager’ since it’s a role for us to learn ‘on the job’.

Associate Product Manager/Trainee Product Manager is where we learn how to take a large vision and
medium-sized missions, and work with a team to create and prioritise small, achievavle goals. And to help a
team break these goals into small, actionable jobs to be done. The Product Owner role within the Scrum
framework describes the tactical product management skills required within a development team and as such
provides a helpful model or Associate Product Managers to work from.

Associate Product Managers may start with a general awareness of product management tactics but are
expected to develop rapidly, gaining working-level skills (i.e. can genuinely add value to a team) within six
to twelve-months (ideally). The Associate Product Manager and the host organisation both need to commit
to learning and development if this is rapid development is to be feasible.

Good conditions for rapid development of an Associate Product Manager include:

 association with a Product Manager or Senior Product Manager, ideally the person who owns the
overall vision for the product/service on which the Associate Product Manager is working
  initially placement on a mature team, in the development phase (referred to as ‘Beta’ within
government services); Associates initially placed in the exploration phase (inquiries, discoveries, or
alphas) may find this tricky, since even mature teams find this phase tricky
 given the chance to rotate across teams on different product/services, for different users, in different
phases of the product lifecycle (as their skills and confidence develops)
 provided with regular coaching and mentoring (ideally having a 1:1 every fortnight), and able to
access training and development quickly and easily.

We need to view Associate Product Managers as a large investment of time and effort in order to build
excellent Product Managers as the future (rather than viewing them as a cheap version of a Product
Manager).

The GOV.UK role description for Associate Product Managers is great, clearly setting out expected skills,
and the level of expertise required in each of these skills.

12 Work with agility

One of the biggest influences on the way we work is the Manifesto for Agile Software Development,
published in 2001:

We have come to value:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The manifesto is only a few lines long but is important because it allows us to focus on doing what is most
valuable, instead of just sticking to cost and delivery schedules. If we focus on problems and are agnostic
about solutions, we can do the least work possible to meet the needs of our users, and optimise the value of
our products and services. We often describe this as making promises to solve problems, not
commitments to specific solutions or features.

The Waterfall model was based on taking a point-in-time snapshot of the information we know and using it
to create a long-term plan that we would adhere to. The Agile insight was that we should change our notion
of what features will create business value over time as more information becomes available […] Agile
approaches added a time dimension where previously there was none.

The Art of Business Value by Mark Schwartz

Reading:

 The Manifesto for Agile Software Development

 Agile is Dead (Long Live Agility), Dave Thomas
 The Agile Manifesto for Public Services, Scott Colfer

Training:

 Digital and agile awareness course, GDS Academy: 1-day introductory course for anyone in
government
  Digital and agile foundation course, GDS Academy: 10-day foundation course for government
employees working in a multi-disciplinary team.

13 Make use of the Scrum framework

The Scrum framework takes the Manifesto for Agile Software Development and interprets it as a framework
for developing, delivering, and sustaining complex products. Scrum was published in 2002 by some of the
authors of the Manifesto for Agile Software Development. The Scrum Guide is published online.

The Scrum framework is helpful for Trainee/Associate Product Managers because it:

 is lightweight and easy to understand

 requires a Product Manager to be a key member of a Scrum team (it calls this person a ‘Product
Owner’)
 explains the point of a Product Owner, and how the Product Owner works with the teams though
artifacts (like the backlog) and ceremonies (like review).

Here are some key sections of the Scrum Guide for product managers:

 The Product Owner

 The Sprint
 Sprint Planning
 Daily Scrum
 Sprint Review
 Sprint Retrospective
 Product Backlog
 Sprint Backlog
 Increment
 Definition of Done.

There is a lot written about Scrum.

Reading:

Roman Pichler has written particularly extensively on Scrum, examples include:

 What’s the difference between a product manager and a product owner?

 Sprint review tips for product owners
 Agile Product Management with Scrum

Also:

 Product Owner Anti-Patterns, Stefan Wolpers

Training:

 Working level for product managers, GDS Academy: 3-day course that shares some of the core
Scrum concepts, contextualised for government
 Certified Scrum Product Owner course, Roman Pichler: 2-day course on Scrum Product Ownership
that leads to a professional certificate in Scrum Product Ownership from the Scrum Alliance
  Smart Scrum Product Ownership, Jeff Patton and Jeff Gothelf: 2-day course that leads to a
professional certificate in Scrum Product Ownership from the Scrum Alliance but takes a more
flexible approach to Scrum.

14 Make use of the Government Service Toolkit

Many of us work joined the Civil Service to work on public services because of the mission set by the
Government Digital Service, to build public services so good that people want to use them. The Government
Digital Service (GDS) has turned this mission in to a toolkit that has been adopted across government, and
gives us the space to improve the lives of the public by focussing on their needs.

GDS took The Lean Startup and adapted it for the context of working on public services within the Civil
Service. The Lean Startup provides a scientific approach to creating and managing new products and
services in order to get those products/services into users’ hands faster. In turn, the Lean Startup is based on
lean manufacturing, design thinking, customer development, and agile software development. GDS took all
of this and created the Government Service Toolkit. The Government Service Toolkit is a great shorthand
for what Lean Startup, lean manufacturing, design thinking, customer development, and agile development
means when working on public services. It’s a great tool for us all but particuarly useful for Associate
Product Managers looking for a practical way to begin their development.

Key sections of the Government Service Toolkit include:

 Government design principles - including the famous ‘start with user needs’
 Digital service standard - the 18-point standard that government services must meet
 Service manual, guidance on how to research - design and build services that meet the Digital
Service Standard
o this includes the common phases of agile government service development: discovery - test
your assumptions about the problem; alpha - testing assumptions about the solution and
looking for problem/solution fit; beta - build the thing and test it works; live - test that the
thing you built is being used, is useful, and it can can have its value continually optimised;
retirement - stop a thing because it’s no longer being used or no longer useful (or both).
o the type of team we’re often a part of
 Service assemssment, what happens at a service assessment, and checking if you need a service
assessment
 Technology code of practice - the set of criteria to help government design, build and buy better
technology.

15 The Product Manager role develops the

strategic principles and skills of product
management
Product Manager is where we step-up and develop the strategic skills of product management, having
developed our tactical skills in something like an Associate Product Manager role. We are often responsible
for the overall value improvement of a feature of a public service (often a software feature), or (more rarely)
an end-to-end public service or staff service.
Product Managers take responsibility for broader product strategy by defining the problem statement and
value proposition, building a vision for an improved, future value proposition, and creating the strategy for
how to get there. We may provide this product strategy to an Associate Product Manager, who will help the
team to figure out what this looks like in practice, and provide challenge where needed.

The GOV.UK role description for Product Managers is great, clearly setting out expected skills, and the
level of expertise required in each of these skills.

Training:

 Product Management, General Assembly - 10-week evening course (2 evenings per week), or a full-
time, 1-week intensive
 Product Management Foundations, Mind the Product - 1-day course

16 Make use of the Lean Startup

We own the strategy for our product (as well as the tactics) in our role as product managers. Scrum and the
Product Owner role are great for learning the basic product management tactics required as an Associate
Product Manager, but Scrum is tactical. Scrum gives us the backlog to work with (which is awesome) but
doesn’t help us to develop opportunities in the first place, or provide tools to develop a strategy for
optimising the value of our products and services.

The Lean Startup method by Eric Ries is a great at helping us understand how to develop opportunities,
then optimise the value of product and services:

 The Lean Startup method was published in 2011 and comes from lean manufacturing, design
thinking, customer development, and agile development
 The ‘pivot’ is at the heart of the Lean Startup: pivots represent the option to rapidly build, test and
learn so that we can fail quickly and cheaply
 The method is characterised by an extremely fast cycle time, a focus on what customers want
(without asking them), and a scientific approach to making decisions
 The method is most applicable for areas of extreme uncertainty, bringing strategy to extreme
uncertainty through:
o Validated learning
o Rapid build-measure-learn feedback loops
o Accountability (measure, manage, and prioritise).

Lots of The Lean Startup method now sounds obvious. This is in part because it’s had a huge influence in
the years since it was published and underpins how lots of organisations work. More specifically, it was an
influence on the Government Digital Service which was being developed around the same time as it was
published - you can see lots of The Lean Startup method implied in the GDS Service Toolkit.

Reading:

 The Lean Startup, Eric Ries

 The Lean Startup for Product Managers, Scott Colfer
17 Simplicity - the art of maximising the amount
of work not done - is essential
The point of validated learning, rapid build-measure-learn feedback loops, and accountability is to help us
spend the least time and money possible to meet the needs of our users through a compelling product or
service. The aim of every increment of our product/service is to create the minimum, viable product/service.

Minimum viable product

The concept of ‘minimum viable product’ has been used and abused over the last few years, so let’s return to
source and see what it originally meant. The Lean Startup helped to make the concept popular:

The Minimum Viable Product is that version of the product that enables a full turn of the Build-Measure-
Learn loop with a minimum amount of effort and the least amount of development time.

We talked about an increment in our guidance for Associate Product Managers - it is the work done during a
sprint which takes your product/service one step toward a vision. Our goal as product managers is to use
validated learning and accountability within a rapid build-measure-learn feedback loop (e.g. a sprint) to
prioritise the least work needed in order to meet our sprint goal. Our continual challenge is for each
increment to produce the minimum, viable product/service needed to meet our sprint goal. What is
acceptable for minimum and viable will change during the lifetime of the product/service as it grows in
maturity and number of users.

Continuous Delivery and DevOps

‘Continuous delivery’ describes a software development culture that get changes (experiments, features, bug
fixes) into production or in the hands of users safely and quickly in a sustainable way. This requires closer
working between development and web operations, which has since been labelled ‘devops’. Continuous
integration is a critical aspect of continuous delivery, which means working in small batches and using
automated tests to detect and reject changes that introduce regression.

‘The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win‘ introduces ‘The
Three Ways’, a description of the values and philosophies that guide DevOps processes and practices.

‘The First Way is about the left-to-right flow of work from Development to IT Operations to the customer.
In order to maximise flow, we need small batch sizes and intervals of work, never passing defects to
downstream work centres, and to constantly optimise for the global goals (as opposed to local goals such as
Dev feature completion rates, Test find/fix ratios, or Ops availability measures). The necessary practices
include continuous build, integration, and deployment, creating environments on demand, limiting work in
process, and building safe systems and organisations that are safe to change.’

‘The Second Way is about the constant flow of fast feedback from right-to-left at all stages of the value
stream, amplifying it to ensure that we can prevent problems from happening again or enable faster
detection and recovery. By doing this, we create quality at source, creating or embedding knowledge where
we need it. The necessary practices include ‘stopping the production line’ when our builds and tests fail in
deployment pipeline; constantly elevating the improvement of daily work; creating fast automated test suites
to ensure that code is always in a potentially deployable state; creating shared goals and shared pain between
Development and IT Operations; and creating pervasive production telemetry so that everyone can see
whether code and environments are operating as designed and that customer goals are being met.’

‘The Third Way is about creating a culture that fosters two things: continual experimentation (which
requires taking risks and learning from success and failure), and understanding that repetition and practice is
the prerequisite to mastery. Experimentation and risk taking are what enable us to relentlessly improve our
system of work, which often requires us to do things very differently than how we’ve done it for decades.
And when things go wrong, our constant repetition and daily practice is what allows us to have the skills and
habits that enable us to retreat back to a place of safety and resume normal operations. The necessary
practices include creating a culture of innovation and risk taking (as opposed to fear or mindless order
taking) and high trust (as opposed to low trust, command-and-control), allocating at least twenty percent of
Development and IT Operations cycles towards non-functional requirements, and constant reinforcement
that improvements are encouraged and celebrated.’

Reading:

 The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, Gene Kim, Kevin
Behr, George Spafford
 The Product Managers’ Guide to Continuous Delivery and DevOps Suzie Prince
 Why Continuous Delivery and DevOps are Product Managers’ Best Friends Suzie Prince

18 Make promises to solve problems, not

commitments to specific solutions and features
Focussing on problems is what helps us to do the least work possible to meet the needs of users. If we really
understand users’ problem and are usefully agnostic about solutions then we can be flexible enough to
always do the least work possible to meet our users’ needs.

 A gap in the market does not always mean there’s a market in the gap

Identifying a problem is not sufficient, we need to make sure that it’s a problem worth solving for our users.
As product managers, we need to help our teams continually ask these questions about the problem we want
to solve:

 Is it pervasive? Who specifically has the problem and does it affect lots of people?
 Is it urgent? Do those people need the problem to be solved right away or can they wait?
 Is it complex? Are people able to solve the problem for themselves or do they need someone else to
solve it for them?
 Is it valuable for users? How painful is the problem for them and would they be willing to change
their behaviour and use a new or different solution?
 Is it valuable for your organisation? Will solving the problem save more money than it costs to build
the solution?

We have a compelling problem when you can answer ‘yes’ to all of these questions.

We are likely to reframe our problem several times during the product lifecycle and may even change our
primary user. This is important and valuable as we refine the scope of our problem to be feasible to solve.
We’ll often find that we start with a massive problem space and refine this to something with a narrower
focus but greater feasibility of being solved. We might find that the problem is not ready to be solved and
that we need to pause or cancel our product/service.

Reading: The Practitioner’s Guide to Product Management, Jock Busuttil

 Problem/solution fit
We can start looking for the right solution once we understand our problem, with the goal of achieving
‘product/solution fit’. The Design Council has famously used a ‘double diamond’ diagram to explain how
we initially find problem/solution fit, and Jock Busuttil has refined it further.

Reading:

 The Design Process: What is the Double Diamond?, Design Council

 Find the tipping point in your research, Jock Busuttil

 Always be optimising value

Our job as product managers is to work with our teams to continually optimise the value of our products and
services - by ensuring that we keep and improve our problem/solution fit for our users - through the
minimum, viable product possible. This is the goal of every iteration of our product/services. How do we do
that?

We have some key tools that help us with our product strategy:

A problem statement should form the initial leap of faith for every product idea, then be refined and
improved throughout the life of our products/services. Melanie Cannon from DWP has written helpful
guidance on how to write a problem statement.

Value proposition, business model canvas, product vision, and product roadmap are some of the most
critical strategic tools we use day to day:

 a value proposition is where our organisation’s offer meets with our users’ needs, explaining how our
solutions fit with users’ problems - a value proposition canvas is a tool that can help to create a value
proposition
 a business model canvas describes how ‘profitable’ your value proposition is today, defining it in
terms of value and cost - it looks at the overall operating model and helps us understand
opportunities to optimise value - a business model canvas is a tool to help create a business model
 a product vision describes our goal in terms of the value of the product/service in the future - the
estimated value the product will have in the future should justify the invesment of money, time and
effort that we want to make - a product vision board is a tool to help us create a vision
 a product roadmap describes the steps needed to be taken from today (as described in the business
model canvas) to the future (as described in the vision) - the roadmap makes promises to solve
problems, not commitment to solutions or features - it is a flexible planning tool that should be
reviewed and updated regularly as we learn more about our product/service

We should run a regular product strategy meeting to review all of the above (in addition to the teams more
frequent sprint ceremonies).

Reading:

 Value proposition canvas, Strategyzer

 Business model canvas, Strategyzer
 Product vision board, Roman Pichler
 How to build product vision in 5 minutes, Ilya Leyrikh
 Product Roadmaps Relaunched, Todd Lombardo et al
o summary of key themes
 Roadmap principles, UK government product community
 Product roadmaps in 5 easy pieces, Scott Colfer

Training:
  Strategyzer workshops
 Product strategy and product roadmap, Roman Pichler

 Product lifecycle

Our strategy will be strongly influenced by where our product is at in its lifecycle.

The above diagram is a standard description of a product lifecycle, and if you imagine that ‘sales’ is more
likely to mean ‘adoption’ when working in government then it works for us. The GDS service standard takes
us to somewhere around ‘introduction’ or early ‘growth’ but we often forget about the rest of the lifecycle:

 Introduction: initially, we’re looking to define the core features of our product in order to find
problem/solution fit, so lots of the work will be focussed on development. As we get data that
increases our confidence in the software’s features our focus will move to resilience (e.g.
infrastructure, information security, service desk, etc) and the skills needed in our team will become
more diverse.
 Growth: Once our service is resilient, our focus will be on increasing adoption. This may require
marketing, communication, training and operational skills just as much as it requires development
skills (maybe even more so).
 Maturity: Once our service approaches its maximum possible adoption then we look to optimise its
value over time. New features is one aspect of this but we also need to prioritise innovation, service
improvement, and technical debt.
 Decline: We need to review the vision, roadmap and business model canvas for our product/service
throughout its lifecycle and at some point the value proposition will weaken to the point where the
product/service should be retired. This may be because a business process or policy has changed
significantly, a key technology has improved, a ‘competitor’ has a better offer (and lots of other
reasons). Here we need to continue to meet the needs of users until they have moved to the new
solution.

 Prioritisation and metrics

All of our work as product managers comes to life in the act of prioritisation. Our job is to lead our teams in
prioritising the work that is most valuable. As we’ve seen in this guidance, value is context specific,
depending on this like what problem we’re solving, who we’re solving it for, who our client is, and what
stage of the product lifecycle we’re in. We can use the business model canvas to define what’s valuable
today, our vision to define what’s valuable in the future, and our roadmaps to define what we think is
valuable between now and then.

We can use data (often known as ‘metrics’) to measure value, set goals, and inform strategy - in other words,
to help us prioritise our work. A lot is written about prioritisation but it’s still something of a ‘dark art’.
Framing goals as hypotheses with pass/fail criteria helps us to bring more rigor to this process.

Reading:

 Product Prioritisation by the Numbers, Kate Bennet

 Deciding on priorities, GDS Service Manual

Here are a couple of tools we can use to get going with prioritisation:

 Prioritise today: impact vs effort is commonly used to evaluate options immediately in front of us.
Here’s a guide to impact vs effort priorisation from Andy Wicks. Here’s a useful article called Why
Prioritization by Impact/Effort Doesn’t Work by Itamar Gilad to help avoid some of the pitfalls of
this approach.
 Prioritise over time: we will need to prioritise different types of work as our product matures. Here’s
a guide to the different types of work required by a mature product from Barry Overeem.

Metrics (or data) is most useful when it leads to action. They should run through our vision, roadmap,
business model canvas, and backlog. Metrics (or data) is most useful when it leads to action, e.g. it helps us
to test a hypothesis about how to improve the value of our product/service, or helps us to prioritise an area
for improvement. DWP has shared how they identified their key metrics for a service, and the GDS Service
Standard contains a lot of advice on key performance indicators.

19 People are our competitive advantage

Product are only valuable if they’re being used. This requires as much understanding of people as it does of
technology and product management. In fact, technology is (often) simple; people are (often) complicated.
[Nikki Lee](https://twitter.com/nkkl from 18F shared a thread of Tweets that summarises this well:

 “So my first Product Management Hot Take on government systems is that it doesn’t matter how
great your idea is if you can’t build and deploy it to users.”
 “We don’t talk about it all that often, but a lot of product management in an organization of size is
politics. What are the power structures in place? What are the rules, both written and unwritten? Who
made those rules? What did they want?”
 “Doing this effectively requires empathy, strong communication skills […] It /also/ requires a deep
understanding of whatever it is you’re proposing.”

We improve the value of our products and the value of our product management by empowering and
empathising with people.

Teams (‘including ‘stakeholders’)

Team composition - The agile team onion is a model for teams in large organisations, helping them to
understand the full range of people in their teams and the value of each level of involvement. Used with your
delivery manager and team, it will help to define the expectations of everyone in the core team, as well as
the expectations of collaborators (who occasionally support the work of the team) and supporters
(stakeholders who can remove blockers).

Team functionality - The five dysfunctions of a team helps us to understand the kind of behaviour that
indicates that our teams are dysfunctional. Typical indicators of a dysfunctional team are: inattention to

results; avoidance of accountability; lack of commitment; fear of conflict; absence of trust.

Reading:

 The Agile Team Onion, Emily Webber

 The Five Dysfunctions of a Team, Patrick M. Lencioni
 Stop saying ‘the business’, start saying ‘our business’, Jeff Patton

Users

Our entire way of working on digital services in government gives us the opportunity to understand the
needs of our users before we try and solve their problems. Our guidance for Associate Product Managers
includes a section on the Government Service Standard that outlines a lot of this.

Discovery helps us to start all of our products by understanding the needs of our users, so that we can do the
least work possible to solve their problems. This is how we optimise the value of public services. Discovery
is a critical phase for our products and introduces lots of the concepts and approaches that we’ll use
throughout the lifecycle of the products we work on.

We focus on services that solve problems for users, and make promises to solve these problems (over
making commitments to particular solutions or features), something that requires us to understand what a
service is.

Reading: How the discovery phase works, GOV.UK

Training: Introduction and basic training days for user research for government services, GDS Academy
We build services for all users

Government builds services for everyone in the UK: if someone is entitled to something, we make sure they
get it. Accessibility therefore becomes more important for public services then it can be in private services.
GDS has published guidance on accessibility and shared an accessibility reading list.

Reading:

 Accessibility guidance, GDS

 Accessibility reading list, GDS
 Accessibility posters, Home Office

20 It’s OK to say ‘no’

Our responsibility is to optimise value. If a proposal for action provides little confidence that it will improve
value then it’s our job to question further - and sometimes, we’ll find that there’s a better opportunity. It’s
our responsibility, along with other professions like business analysis and portfolio management, to help our
colleagues to re-prioritise work based on return on investment when we can see better alternatives.
Sometimes this means saying ‘no’ - constructively, based on analysis of assumptions underpinning
investment proposals - but ‘no’ nonetheless. We need to work with other value-focussed professions to
create an organisational culture where this is OK and actively rewarded.

21 Product leadership puts our product

management skills to work at a larger scale by
developing our business strategy and digital
transformation skills
Product leadership within public services

We learn all the core product management skills within the Associate Product Manager and Product
Manager roles. Senior, Lead and Head of Product Management are about learning and adding leadership
skills to our abilities. We’re now expected to work at a larger scale, amongst a complicated set of value
contexts, possibly in an enterprise setting that’s undergoing significat change.

This is the heart of what the move from practitioner to expert mastery means for many product leaders
working on public services. We still have the ability to ‘get our hands dirty’ and use our product
management skills, but they’re often used to apply product management at scale or to promote product
management craftsmanship through example. We’re increasingly likely to be managing value within
management and leadership teams, rather than delivery teams. We’re also responsible for the performance
management, support and development of the members of our profession. We’re often working in spaces
where we have influence, not authority: we’re being asked to support business strategy and digital
transformation but are not solely responsible for the outcomes and often not playing a lead-role in this work.
This means that the ‘soft-skills’ of teaching, mentoring, coaching and facilitating are hard. Our colleagues
responsible for workflow are likely to have more mastery than we have within our profession, and may
become key allies in our professional development.
As product leaders we need to remain brilliant at both the basics of product management and of leadership.
Every now and then a flash of inspiration is needed and will emerge, but what our profession and our
organisation needs from us most of the time is excellence in the basics that keep everything going:

 Product leaders will not always be the best product manager in the profession since we should aim to
hire hiring people better than us - but we should remain an excellent product manager, none the less
 We should be the strongest product leaders in the profession, and lead by example.

The career pathway to date has prepared us for this. We are now a visible, first point of contact for the
profession, so need to live up to the expectations of that role but recognise that we must share leadership
amongst the profession in order to avoid being a bottleneck, and to release the true value of the profession as
a whole.

The emergence of product leadership

‘Product leadership’ is something that’s emerged as a valuable role in the last 2-3 years. Mind the Product
has introduced a Leadership Forum, and organisational improvement was a key theme of the 2018 Mind the
Product conference in London. Mind the Product has now introduced a quarterly product leaders meetup to
its London events, aimed solely at Heads of Product, Product Directors, and Chief Product Officers.
Summer 2017 also saw the release of a book on Product Leadership, much of it generated through insights
from Mind the Product’s international network of product leaders.

Reading:

 The Rise of Product Leadership, Brian Crofts

 Product Leadership, Martin Eriksson et al

Product leadership in the Civil Service

Simon Wardley (business intelligence professional & creator of Wardley ‘Value Chain’ Mapping) has made
the following provocative statement about leadership in general:

Almost all companies are clueless on strategy, it’s all meme copying and gut feel. There’s an entire field yet
to be discovered, to be understood. It’s a wonderful time.

 Twitter, 11 Jan 2018

More specifically, John Manzoni (Chief Executive of the Civil Service) has challenged leadership in the
civil service to improve to meet the needs of a complex, multidisciplinary government context:

We need leaders with empathy, who can manage their teams through transformation and encourage
continuous improvement. Leaders with broader experience, who are effective in a complex,
multidisciplinary world, who lead with their hearts and their guts, as well as their heads, who see the big
picture. Leaders whose instincts - developed through experience - are collaborative; who are used to
working across boundaries, confident beyond their own professional area, and inspire and empower their
teams - building on the commitments in our Leadership Statement.

 Civil Service transformation speech, 24 Jan 2018

We have a need and an opportunity to help shape product leadership and in doing so to help shape Civil
Service leadership.

Reading: A civil service fit for the future, John Manzoni

22 A note on product leadership roles and career
progression
Product leadership is in its infancy. Product leadership roles and career progression is highly variable as a
result. Associate Product Manager to Product Manager is a fairly consistent career pathway but, in all
honesty, all bets are off from that point onwards. Use and implementation of Senior Product Manager, Lead
Product Manager, and Head of Product is highly variable for a lot of reasons, here are just a few:

 if an small-medium organisation produces a single product and only has a few Product Managers
then their career progression and use of roles might be Associate Product Manager –> Product
Manager –> Head of Product
 if an organisation is medium-sized and/or produces more than one product then it may have internal
groupings that require Senior Product Managers (sometimes called Group Product Managers), and
use of roles and career progression might be Associate Product Manager –> Product Manager –>
Senior Product Manager –> Head of Product
 if an organisation is Enterprise sized and/or has several business areas then it might have a Lead
Product Manager who acts like a head of product for each business area, each of which has its own
groupings, and use of roles and career progression might be Associate Product Manager –> Product
Manager –> Senior Product Manager –> Lead Product Manager –> Head of Product. The Senior
Product Manager in this context is comparable to the Head of Product in the small organisation with
a single product.

You only need to take a look at the Mind the Product Jobs board to see this variation.

What’s the point of this observation? This handbook will focus on product leadership as a single ‘thing’ and
share guidance that’s (hopefully) useful whether you’re a Senior Product Manager, Lead Product Manager,
or a Head of Product - with limited space dedicated to Senior Product Manager, Lead Product Manager, and
Head of Product as individual roles.

23 Keep being brilliant at the basics

You should be brilliant at the basics of product management tactics and strategy learned to this point in your
career. The skills you learn as an Associate Product Manager and Product Manager provide you with the all
the basics you need as a product leader - your challenge is to apply them at scale, in abstract settings.

The training available to you may become narrower as your expertise develops, with general courses
diminishing in value (except as an occasional refresher). A few learning providers offer training for more
senior product managers looking to develop their expertise:

Mind the Product Training: Mind the Product is the largest and oldest community for product managers and
began offering training in 2017. Mind the Product Training offers courses in topics like user story mapping,
product roadmapping, stakeholder mapping for product leaders, visual thinking for product people,
continuous product discovery, and user research interviews.

Jam Workshops: Jam is an annual product conference and like Mind the Product they have started offering
training. Current workshops include ‘design sprints done right’, and ‘using jobs to be done for better product
strategy’.

General Assembly: You may wish to increase your awareness of how other professions in your team
function, and General Assembly has a range of classes and workshops that may be of use.
24 Develop expertise in business strategy & digital
transformation
Remember our career development diagram? It helps us to understand that when we move from product
management to product leadership, we need to start focussing on our generall leadership skills. Working on
public services within digital and technology teams within UK government, ‘leadership skills’ can often
mean two things in particular:

Business Strategy - The ability to apply business strategy and management frameworks to employ agile as a
competitive business advantage such as Lean Start-Up and Lean Enterprise, product innovation techniques,
flow-based business process management approaches, and other techniques that relate to innovating in the
business domain.

Digital Transformation - The ability to facilitate, accelerate and (as appropriate) lead organisational change
and transformation. This area draws on change management, organisation culture, organisation
development, systems thinking, and other behavioral sciences.

There are many resources out there to help with developing our expertise when it comes to business strategy
and digital transformation but three of particular value are:

Lean Enterprise by Jezz Humble, Joanne Molesky, and Barry O’Reilly provides essential guidance across
business strategy, digital transformation, and (to some extent) product management expertise. They take the
concepts of The Lean Startup and explain how they work in an enterprise setting.

The Art of Business Value by Mark Schwartz focusesses on business strategy. The book is intended to help
define the role of Chief Information Officer in a modern, value-driven organisation where technology is
becoming less important than the outcomes it helps deliver, but in doing so provides lots of tools to help us
work out what ‘value’ actually means in the context of government.

An Introduction to Wardley Maps by Simon Wardley provides an introduction to the eponymous value
chain mapping tool that Simon developed to help organisations build their business strategy. This video
featuring Simon also provides a useful introduction. Simon provides the story of developing Wardley
Mapping in this post.

Additional reading: Why product people should care about business strategy, Roman Pichler

25 Develop expertise in teaching, mentoring,

coaching and facilitation
The value of product management expertise, business strategy and digital transformation is often released
via ‘soft skills’ such as mentoring and teaching, coaching and facilitating. Delivery Managers may often be
the experts in these skills within our teams, but the skills remain important for product managers too.

Teaching - The ability to offer the right knowledge, at the right time, taught in the right way, so that
individuals, teams and organisations use the knowledge for their best benefit.
Mentoring - The ability to impart your experience, knowledge and guidance to help develop other product
managers.

Coaching - The ability to act as a non-directive coach (with the coachee’s interest determining the direction,
rather than your own expertise or opinion).

Facilitation - The ability to act as a neutral process holder, guiding and individual’s/team’s/organisation’s
process of discovery, holding them to their purpose and definition of success.

There are many resources out there to help with developing our expertise when it comes to teaching,
mentoring, coaching and facilitating, but these are particularly valuable:

Building Successful Communities of Practice by Emily Webber contains the model on which many
government departments have designed their communities of practice - you can see a recent summary here.
Emily’s community maturity model can measure improvements in the strength of our profession.

Everyone needs a coach by Kate Leto and Barry O’Reilly is a useful article for those new to coaching and
mentoring; it provides and introduction to the difference between a coach, a mentor, and a consultant, and
the possible value of each.

Executives and safety (get it done individuals can be toxic in agile environments) by Chris Matts

Hard skills vs. soft skills Kate Leto and Martin Eriksson

26 See the bigger picture

You need to be aware of all the dimensions of leadership and make sure they’re in balance. Georg Fasching
is an executive coach who has developed a leadership model to help us find this balance.
Georg talks about what the dimensions mean in a general sense in his introductory post.

Scott Colfer (Head of Product, Ministry of Justice) has personalised this model and attempted to
contextualise for product management in his own team in this post.

27 Improve public services, one step at a time

We’re in the midst of a huge amount of work to transform government. Government is massive, complex
and over 800 years old, so how do we transform it? The answer is: focus on changing one small thing at a
time, and eventually it will add up to big change.

The shift towards end-to-end services that truly meet the needs of the public and civil servants will take time
to achieve: it’s a long-term and challenging target condition. We are starting a process of innovation in
conditions of uncertainty, so we cannot know in advance how we will reach this target condition. It’s up to
us, and everyone else working within public services, to run a series of experiments that allow us to make
small changes, quickly.

Tools like the ‘plan-do-check-act’ cycle help us to run these experiments and make small changes quickly.
Here’s a summary of the cycle:

 Plan. Recognise an opportunity and plan a change.

 Do. Test the change. Carry out a small-scale study.
 Check. Review the test, analyze the results and identify what you’ve learned.
 Act. Take action based on what you learned in the study step: If the change did not work, go through
the cycle again with a different plan. If you were successful, incorporate what you learned from the
test into wider changes. Use what you learned to plan new improvements, beginning the cycle again.

We can apply these small improvements to our teams, our service areas, our profession, our business units,
and public services as a whole.

This general approach to improvement, applied to multiple levels of an organisation, is often referred to as
an improvement ‘Kata’ (a Japanese word that’s been taken and used to refer to a basic pattern that is used to
improve our mastery of something). It does not tell us what to do, it just tells us how to improve. You can
find a video explaining Kata here.

The improvement Kata is suited to conditions of uncertainty, but is also suited to helping us to avoid burn-
out. Government is 800 years old and one of the largest organisations in the country - if we each try to
change it, at scale, on our own then we will burn out. The improvement Kata helps us to balance the need to
help government improve, with the need to set realistic targets: as long as we are focussing on improving
one thing every few weeks then we can be proud that we’re doing our job well.

We may want to work more closely with areas of our organisation beyond ‘delivery teams’, like
procurement and portfolio. They are both places where prioritisation and investment decisions are made
based on value - things that product management does well and should step-up and support. Change
management is another area of the organisation that we should work more closely with: continuous delivery
and continuous integration are integral to our way of working and are (in effect) modern methods of change
management. Lean Enterprise dedicates a section to translating continuous delivery for traditional, enterprise
Change Management process.

Reading:

 Transforming a 150-year-old government agency, Tera Atlas

  Why Enterprise Agile Teams Fail, Sam McAfee

28 It’s still OK to say ‘no’

Our responsibility is to optimise value. If a proposal for action provides little confidence that it will improve
value then it’s our job to question further - and sometimes, we’ll find that there’s a better opportunity. It’s
our responsibility, along with other professions like business analysis and portfolio management, to help our
colleagues to reprioritise work based on return on investment when we can see better alternatives.
Sometimes this means saying ‘no’ - constructively, based on analysis of assumptions underpinning
investment proposals - but ‘no’ nonetheless. We need to work with other value-focussed professions to
create an organisational culture where this is OK. We also need to give the profession as a whole permission
to work in this way.

29 Senior Product Manager can often be thought

of as a group product manager
Use and implementation of product leadership roles like Senior Product Manager can vary a lot, as we’ve
previously noted. We’re going to take a look at what Senior Product Manager might look like in an
enterprise with mutliple business areas.

Senior Product Managers can be thought of as ‘group product managers’. They manage a group of things
that share commonalities, users, or interdependencies. For example, there may be a grouping of things
around sign-on, and a Senior Product Manager might provide the overall value strategy for 2-5 things in this
space. They’re likely to have a Lead Product Manager for their business area.

Senior Product Manager is an interesting point in our career pathway, as it is the tipping point between
product management and product leadership. We’re still expected to work directly within delivery teams,
but also expected to work with our Lead Product Manager to influence and support overall strategy for our
business unit and our profession. We’ll need to maintain our ability to work in a delivery team in the ways
we’ve learned as an Associate Product Manager and Product Manager, but increasingly need to develop
your product leadership skills in order to focus on the needs of the broader organisation.

The GOV.UK role description for Senior Product Managers is great, clearly setting out expected skills, and
the level of expertise required in each of these skills.

30 Lead Product Manager can often be thought of

as a ‘head’ of product for an area of the business
Use and implementation of product leadership roles like Lead Product Manager can vary a lot, as we’ve
previously noted. We’re going to take a look at what Lead Product Manager might look like in an enterprise
with mutliple business areas.

Lead Product Managers can be thought of as ‘heads of product’ for an area of the business. These areas are
often the clients we work for, so we might be leading all of the in-house software development for a single
programme, department, or delivery agency: we’re responsible for the overall value of our work for that
client, building an overall value proposition that helps us to priortise opportunities. We’re also responsible
for leading the product management community in our area of the business. We probably spend less and less
time working directly in delivery teams, and more and more time working with management teams and with
functions from the broader operational teams. Lead Product Managers will report in to the overall Head of
Product.

The GOV.UK role description for Lead Product Managers is great, clearly setting out expected skills, and
the level of expertise required in each of these skills.

31 Head of Product: have empathy, avoid

dogmatism
Use and implementation of product leadership roles like Head of Product can vary a lot, as we’ve previously
noted. We’re going to take a look at what Head of Product might look like in an enterprise with mutliple
business areas.

Product management is often described as a role which is about influence, not authority: Head of Product is
no different. You are likely to have at least two version of your role when working in government, one of
which you will give you some authority, and the other in which you will need to seek influence:

1. Head of Profession - The space where you have clearest responsibility and authority is that of the
product profession itself. You are responsible for the the performance of the product management
profession and the product managers within in. This includes owning and improving the role of
‘product manager’ itself, plus the recruitment and performance management of product managers.
You are the most senior representative of the profession, responsible for making sure that it meets
the needs of our colleagues - which sometimes requires challenging assumptions about the role and
supporting the use of other professions. This role is similar to all other heads of profession
2. Head of Product - Product managers in government are responsible for the value of public services
or the features of public services. You are the most senior representative of value strategy in your
role as Head of Product. Government is still unfamiliar with product management and its application
outside of delivery teams, within management and leadership teams (we are seeing our first Directors
of Product and Chief Product Officers being hired in government departments). As a result of this,
you will need to seek opportunities to support and influence value strategy at an organisational level
and are unlikely to be given clear authority. This is covered to some extent by the head of product
role description on GOV.UK.

Our job is to improve the value of public services. Our scope is often the digital, technology, or data features
of these services. It is important to remember this when thinking of the value of our work - it often needs to
sit in a much larger context, and we need to be conscious of optimising one feature of a public service at the
cost of passing a problem downstream to an operational team. If optimising a feature of a service does not
show a real improvement in overall value for users of that service then we should question whether it’s the
right thing to do.

In all of this we need to have empathy and avoid dogmatism. Many digital teams are large enterprises, the
departments they’re sat within even larger. We work in multiple contexts at once - if you can’t work with
organisational complexity then government in 2018 is not the right place for you to pursue your career. As
Head of Product you need to acknowledge these different contexts, retain focus on our unique selling point
as a profession (improving value through value strategy), be aware of our limits, and seek opportunities to:
  Support and influence value strategy at the organisational level, work with Heads of Business Units
to empower Lead Product Managers to do the same at a local level within their own business units
 Work with, support, and learn from the other value-focussed professions so that we all align to
similar goals and make the most of our time and expertise
 Work with, support, and understand more about the professions focussed on workflow and quality,
so that you don’t over-optimise for your own profession and allow a narrow view to blind you to
bigger goals.
 Most importantly, work with central leadership and leadership of local business units so that the
product professions really helps your organisation to accomplish its missions.

What we needs is principles & trust, derived from clear visions that help us understand user-focussed
objectives. What we don’t need is dogma, and we avoid dogma with empathy. The Agile Manifesto for
Software Development describes this as “individuals and interactions over processes and tools”.