Product management, in about three minutes

The most precise public description of the product manager’s job in Britain is not in a book about products. It sits in a civil service capability framework, where the role appears at five levels, each pinned to a grade. Associate product manager at HEO or SEO, product manager at SEO or Grade 7, senior product manager at Grade 7, lead product manager at Grade 7 or 6, head of product at Grade 6.

Grades are not a detail. A grade determines who a person can overrule, whose budget they sit inside, and how much it costs to disagree with them. Publishing the role against a grade settles in one line the question most private organisations leave permanently open, which is how much authority the product manager actually holds. If you want to know whether your own product managers have a job or a job title, that is the test, and it takes about ten seconds.

The same framework says the role is there to make sure products provide value and achieve the right outcomes by balancing user and business needs, and lists among its responsibilities to make decisions on priorities for your teams.

Decisions on priorities. Not recommendations, not facilitation, not a backlog that reflects whichever stakeholder was most recently annoyed.

The only question that separates the role from project management

A project manager is accountable for a plan being met. A product manager is accountable for the plan being right, which means the defining act of the job is refusal. Everything else in the role can be delegated, automated or absorbed by a competent delivery function. Refusal cannot, because refusal requires someone with the standing to disappoint a named senior person and survive it.

This is why the grade matters more than the method. A team can run flawless discovery, write immaculate user stories and still build whatever the loudest director wanted, and from the outside that team looks like a functioning product organisation. The tell is not in the artefacts. It is in whether anything substantial was ever removed from the roadmap over a stakeholder’s objection, and whether the person who removed it is still in post.

What is the product, actually

Point 2 of the Service Standard tells teams to solve a whole problem for users. Read against a typical enterprise estate, that is a harder instruction than it sounds.

Most things called products inside large organisations are components. A payments capability, a customer record, an authentication layer, a case management screen. Each has an owner, a roadmap and a set of metrics, and none of them corresponds to anything a user is trying to do. The user is trying to change an address, claim a refund or register a vehicle, and that journey crosses four components owned by four people who each report into a different director.

When a product manager is given a component and asked to produce outcomes that only exist at the journey level, the role becomes structurally impossible. No amount of prioritisation skill fixes it. The two workable answers are to move the ownership boundary to match the user’s problem, or to be honest that the person is running a component and measure them accordingly. The common third answer, which is to keep the boundary and hold the person to journey outcomes anyway, produces the turnover rate this profession is known for.

Four numbers you have to publish

Point 10 of the standard requires teams to identify metrics that indicate how well the service is solving the problem it is meant to solve, and to track performance against them. Then it goes further than any private board paper. Central government services must publish data on the mandatory key performance indicators, and there are four of them: cost per transaction, user satisfaction, completion rate and digital take-up.

Consider what that combination does. Cost per transaction stops a team claiming success for a service that is expensive to run. Completion rate stops it claiming success for a service people start and abandon. Digital take-up stops it claiming success for a channel almost nobody uses. And publishing means the figures cannot be quietly redefined when they turn awkward, which is the standard fate of an internal target.

Almost no commercial product organisation operates under a comparable constraint. Objectives are set quarterly, reviewed internally, and rewritten when they are missed. That is not dishonesty, it is the absence of an external reader. The practical suggestion for anyone running product outside government is not to adopt the four metrics, which are shaped for public services. It is to pick a small number, write down their definitions, and hand those definitions to somebody with an interest in the answer being unflattering.

The part of the job nobody does

Alpha exists to try out different solutions to the problems learnt about during discovery, and the guidance is blunt about what happens to the output. Expect to throw away any code, and lots of the ideas you test, at the end of alpha.

Throwing away work your own team produced is the least performed duty in product management and the one that most reliably distinguishes people who are good at it. It is unpleasant for obvious reasons. The team is attached to the thing, the sponsor has told their peers about it, and the sunk cost is visible while the saved cost is hypothetical. Organisations that cannot do this accumulate features nobody uses, each defended by whoever built it, until the roadmap is entirely maintenance and the product manager’s remaining function is scheduling.

The same reluctance applies at the other end of the life cycle. Retiring a service is a product decision, it is almost never anyone’s objective, and the cost of not making it compounds quietly in support contracts and integration debt for a decade.

Three minutes, spent

Nothing above is a definition of product management, because the definition was never the difficulty. The difficulty is that the role is usually created without the authority, given a component and measured on a journey, held to metrics it can revise, and staffed by people who have never been permitted to cancel anything.

Where those four conditions are fixed, almost any method works. Where they are not, no method does, which is worth remembering the next time a reorganisation proposes to solve a delivery problem by renaming a team. The adjacent role, and the one most often confused with this one, is covered in what delivery managers actually spend their week on. The rest of this desk’s work on how software gets specified, bought and run sits under SaaS and enterprise software.