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

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: