The CPO Playbook
Process
17 août 2026 · Dernière mise à jour
Contenu à réviser
FR / EN
Login

The Product Roles.

Who does what in a product organisation — the core roles, the adjacent ones, the specialisations, and the seniority ladder. What each one owns, what they are measured on, and where the boundaries genuinely blur.

01The core roles

— the four seats present in almost every product team

Product ManagerPM

Product Manager — chef de produit in French job ads, though the English title dominates in tech.

Owns
The what and the why: problem framing, discovery, prioritisation, specification, and the outcome once shipped. Not the how — that belongs to engineering.
Measured on
Product outcomes: adoption, retention, conversion, revenue impact of the area owned. Not on volume shipped.
Works with
Engineering and Design daily; Data, PMM, Sales, Support weekly.
Typical week
Customer interviews, backlog refinement, writing specs, reviewing metrics, arbitrating scope with engineering, stakeholder updates.

Product OwnerPO

A Scrum role, not originally a job title.

Owns
In the Scrum Guide: maximising the value of the work the team produces, through backlog management — ordering items, making them clear, ensuring the team understands them.
Measured on
Backlog health, sprint predictability, acceptance quality — closer to delivery than to outcome.
Works with
The Scrum team daily; the PM or stakeholders for direction.
In practice
In many European companies — France included — PO is used as a job title for an execution-focused PM: closer to the sprint, further from strategy and discovery. This local usage does not match the Scrum definition, which is why the two titles are so often confused.

Product Marketing ManagerPMM

Responsable marketing produit.

Owns
Positioning, messaging, go-to-market and launch. Also competitive intelligence, pricing input, sales enablement and the narrative given to the market.
Measured on
Launch performance, feature awareness and adoption, win rate against named competitors, quality of sales collateral.
Works with
PM (constantly — they are two halves of one story), Marketing, Sales, Customer Success.
Boundary
The PM decides what gets built and why; the PMM decides how it is explained and sold. When the boundary is unclear, launches slip or ship unannounced.

Product DesignerUX / UI

Designer produit — often split into UX Designer and UI Designer in larger teams.

Owns
Flows, interfaces, interaction and the design system. In many teams also user research, shared with the PM.
Measured on
Usability (task success, time on task, error rate), design-system consistency, and contribution to activation and funnel completion.
Works with
PM and Engineering daily; Research and Brand as needed.

Where it actually breaks

Having both a PM and a PO on the same scope without an explicit split is the most common structural failure. It produces duplicated arbitration, contradictory priorities for engineering, and no single accountable owner. If both roles exist, the boundary has to be written down: typically PM owns discovery and outcome, PO owns delivery and backlog.

02The adjacent roles

— present once the product org reaches a certain size

Product Ops

Owns
The machinery of the product org: tooling, rituals, templates, the feedback pipeline, experiment infrastructure, and the reporting layer.
Exists to
Stop PMs from each rebuilding their own process. Appears typically past 15–20 people in product.

Product Analyst / Data

Owns
The tracking plan, dashboards, funnel and cohort analysis, and experiment readouts — including whether a result is statistically meaningful.
Critical because
Every KPI on this site dies if the underlying events fire inconsistently. Instrumentation is a product deliverable, not an afterthought.

User Researcher

Owns
Qualitative and quantitative research: interview protocols, usability testing, surveys, synthesis into an insight repository.
In smaller teams
Absorbed by the PM and the Designer — which is workable, but interview quality and synthesis rigour usually suffer.

03The specialisations

— the same craft, pointed at a different problem

Growth PM / PLG PM

Owns
A funnel and a metric rather than a feature area — acquisition, activation, conversion, retention. Ships experiments, not roadmap items.
Distinctive
Treats pricing, packaging and paywalls as product surfaces to be tested. Full detail on the dedicated page: The PLG Product Manager.

Platform / API PM

Owns
Internal or external capabilities consumed by other teams — APIs, SDKs, shared services, infrastructure the product depends on.
Distinctive
The customer is often another engineering team. Success is adoption of the platform and the velocity it gives downstream teams, which makes it harder to attribute to end-user metrics.

Technical PMTPM

Owns
Products where the hard problems are engineering ones: developer tools, data infrastructure, performance, migrations.
Distinctive
Requires enough technical depth to hold real architectural trade-off discussions. Note that in some companies TPM means Technical Program Manager, a delivery-coordination role — check which one a job ad means.

AI / ML PM

Owns
Products whose behaviour is probabilistic rather than deterministic: model selection, evaluation criteria, data strategy, and the UX of uncertainty.
Distinctive
Specs cannot fully define the output, so the work shifts to defining evaluation, acceptable failure modes, and fallback behaviour. Quality is a distribution, not a pass/fail.

04The seniority ladder

— what changes at each level is the scope of ambiguity owned, not the volume of work

Associate / Junior PMOne feature Executes a defined scope. The problem is handed over already framed; the work is to deliver it well.
Product ManagerOne product area Frames the problems in their own area, runs discovery, owns the outcome. Needs direction on strategy but not on execution.
Senior PMA complex area Handles ambiguity without a brief, manages cross-team dependencies, and influences peers who do not report to them.
Principal PMIC track Senior individual contributor: works the hardest company-level product problems without managing people. Parallel in level to a manager, not below it.
Group PM / LeadSeveral PMs First management step: still owns a scope, and now also grows two to four PMs.
Head of ProductThe product org Owns the whole product surface and the team that builds it. Translates company strategy into a product roadmap.
VP ProductOrg & process Owns the operating model as much as the product: hiring, rituals, prioritisation frameworks, and cross-functional alignment at scale.
CPOExec / company Sits at the executive table. Owns product strategy as a component of company strategy, arbitrates investment across the portfolio, and answers for product results to the board.

Reading the ladder

Titles are not portable between companies: a Senior PM in a 2,000-person company and a Head of Product in a 30-person startup can own comparable scope. Read the scope of ambiguity owned, not the title.

One useful test across all of these roles: ask what the person is accountable for when the number does not move. The answer separates a product role from a delivery role far more reliably than any job title does.

← Back to the Playbook