The Roles · Who makes it

Product manager

Written from published sources

The person who decides what the product is. The body of knowledge frames the work across a lifecycle — conceive, plan, develop, qualify, launch, deliver, retire — with a decision point between each phase. A product manager owns those decisions and the reasoning behind them, and owns them without commanding any of the teams whose work depends on them.

What the day looks like

  • Talking to customers, and to the people who talk to customers, which is a different and larger population.
  • Deciding what enters the roadmap, and revisiting it when the evidence moves.
  • Writing the requirement precisely enough that engineering can build it and loosely enough that they can build it well.
  • Holding the gate between lifecycle phases, including the decision to stop.
  • Preparing the launch with marketing, support and training, all of whom need the product before it exists.

What it answers for

  • The product solving a problem somebody has, evidenced rather than assumed.
  • The decisions and their reasoning, in a form that survives the person who made them.
  • Everything the organisation promised about the product being true when it ships.

What it is measured on

  • Adoption and revenue, which arrive long after the decisions that caused them.
  • Delivery against the roadmap that was committed.
  • Retention and the outcomes customers report.

Who it receives from

Customers and the field
Problems, described as requests for features.
Engineering
What is possible, at what cost, and what the architecture will resist.
Support and the case volume
Evidence of where the product is failing people, which outranks most opinions.

Who it serves

Engineering
A clear problem and the reasoning behind its priority.
Sales, marketing and training
Something they can describe accurately.
Customers
A product that changes in the direction of their actual difficulty.

Who else has a stake

  • Every team whose plan depends on the roadmap being roughly true.
  • Executives whose commitments were made from an earlier version of it.
  • Customers who bought partly on what was said about the future.

What it takes

  • Reading evidence about people, which is harder and less exact than reading evidence about systems.
  • Enough technical depth to be told the truth by engineers and to know when an estimate is a negotiation.
  • Writing that leaves engineering room to solve the problem rather than to implement a solution.
  • The nerve to hold a gate closed.

What the job turns on

A roadmap is a list of refusals. Every item on it represents many that were declined, and the declining is where the role is actually exercised — most of all at the gate, where stopping something the organisation is already committed to costs more socially than continuing it costs commercially. Product managers who can close a gate produce focused products; those who cannot produce long roadmaps and thin releases, and both look like activity from outside.

The published sources

Where it leads

Roles that lead here

The work itself

The Practice covers how this work is done — triage, escalation, evidence, handover — across the whole corpus.

Read The Practice