Product in Public Services

Nov 17, 2015

In August 2015 I joined the Ministry of Justice as a Product Manager as part of their work to transform public services. My prior product experience was with teams who were some combination of startup, social enterprise or charity so I’ve been trying to get my head around what product means in public services.

Minimum Viable Product Management.

The purpose of product management seems to remain the same whatever sector I’ve worked in.

Product Management is a strategic business role that helps teams to create the simplest, most valuable product they can: the minimum viable product.

Understanding the problems of users and stakeholders is key to this role, based on the principle that when we genuinely understand someone’s problem we can build the minimum viable product needed to solve it (and conversely, when we don’t understand our users we have to guess their needs and consequently build solutions to imaginary problems).

I’m taking the term ‘minimum viable product’ from The Lean Startup (in which it means “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”), and using it in a different way. In my interpretation, minimum viable product is a good way to describe the benefit of product management: by understanding users a product manager helps their team to deliver the most value with the least effort.

Product Managers should critically challenge assumptions about (i) Users, (ii) Problems & (iii) Solutions in order to generate insights that enable the team to prioritise their time. This is known as a ‘user-centred’ approach to product development.

A Product Manager will help a team to understand the needs of users and make simple, valuable stuff.

*MVP is for life not just Version 1. Every product iteration should continue to be a minimum viable product. Your insights will increase (hopefully) and as they do so will your definition of viability. A ‘mature product’ should remain a minimum viable product.

Digital by Default

Working on digital services on the UK right now is a great opportunity to do stuff that matters. In 2013, government gave itself 400 days to transform 25 major services, making them digital by default and simpler, clearer and faster to use as part of the Transformation Programme. This work continues and has become a well-defined, cross-government initiative powered by a great set of design principles, service manual and service standards - all of which put the user first.

However, despite all of these amazing resources, the role of a product manager can sometimes be unclear. Since joining Ministry of Justice Digital and wanted to get my head around product management of public services so I’ve been discussing ideas with colleagues at MOJ like Kylie Mulholland, and across government.

What’s a Product?

In general terms, a product is a ‘thing’ or a service that is valuable to its users. Sounds simple(ish)? Product in government can be murky. There are application programming interfaces (APIs) and microservices . . . which are components driven by business logic rather than products with clear value for users . . . but which can be clustered to create a platform that does have a value proposition and thus become a product.

## Product without Revenue

Working on products in government can feel a little abstract because we lack the certainty of revenue. Revenue sits behind product management in a commercial setting, the ultimate anchor of a business model: is the cost of your business activity less than the revenue it will generate (i.e. is it profitable)?

Public services lack this clarity but there are still ways to test your success. The Cabinet Office requires digital services to measure four types of data in order to measure their success:

cost per transaction

user satisfaction

completion rate

digital take-up (the proportion of transaction completed online).

Currently these four measures of success seem to complement each other but it’s feasible that in the not too-distant future, when the ‘low hanging fruit’ has been digitally transformed, user satisfaction and completion rate may be at odds with cost per transaction. There may also be a case for a measure of technical debt: architectural decisions made during development may give a low cost per transaction in the short term but shorten the lifespan of the software; conversely, adopting an architecture like that of microservices could mean that there is no short term reduction in the cost per transaction but lengthens the lifespan of the software and enables a more dramatic cost reduction in the future.

I’ve come into contact with Social Return on Investment when working on product and services for charities and social enterprises but (honestly) I found it to be a complex way of measuring success (New Philanthropy Capital summarised SROI a few years ago).

Assisted Digital

The unique thing about working on product in public services is that you’re building something for everyone in the UK - you’re not chasing product/market fit in the same way that you would elsewhere. Public services are ‘digital by default’ but about one in five adults is offline or has low digital skills.

I’ve worked on digital products aimed at offline adults before but they were only aimed at offline adults - it’s a different type of challenge to develop something for online and offline users. I’m looking forward to the this challenge and am looking forward to my first assisted digital support project - helping the most in need and the most isolated is something you rarely get the chance to do.