Product Management Handbook


A white label product management handbook for government digital services

View the Project on GitHub scottcolfer/product-management-handbook

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]( from 18F shared a thread of Tweets that summarises this well:

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). Alt text

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. Alt text



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.