Cambridge University Press & Assessment has published a framework defining 12 distinct roles for the organisational design of data-driven product management — a concrete answer to a question most product orgs still resolve by improvisation: who actually owns data work inside a product team?

Most companies bolt data responsibilities onto existing job titles. A product manager "does analytics." An engineer "owns the pipeline." The Cambridge framework takes the opposite position: if product management is genuinely data-driven, the organisation needs explicit, named roles with clear boundaries — and it identifies twelve of them.

Why does role design matter for data-driven product management?

Frameworks like this attack a known failure mode. When data responsibilities are implicit, three things break:

• Accountability gaps. Nobody owns metric definitions, so two dashboards report two different activation rates and roadmap arguments stall.
• Skill mismatches. PMs are asked to be part-analyst, part-experiment designer, part-data engineer — and do none of it well.
• Scaling walls. What works for one squad collapses at 20 teams because the data decisions everyone repeated informally were never anyone's job.

Role-based organisational design forces the tradeoff into the open: you can hire specialists for each of the 12 roles and pay the coordination cost, or you can merge roles into generalists and pay the quality cost. The framework's value is in making that choice explicit rather than accidental.

What does a 12-role structure imply in practice?

A dozen roles is a lot. Very few individual product teams will carry twelve data-focused people. The realistic reading — and the way most org-design frameworks of this shape get applied — is as a coverage checklist rather than a headcount plan:

• Map each of the 12 roles to a named person on your team today, even if one person holds four of them.
• Surface the roles nobody holds. Those are your silent failure points.
• Watch for single points of failure: a role held by exactly one person with no backup.

Where does this kind of framework work — and where does it fail?

Role-heavy designs work best in organisations with mature data infrastructure and enough volume to justify specialisation: think large platforms, marketplaces, or regulated products where measurement discipline is mandatory. They fail in two predictable ways:

• Over-engineering. A seed-stage startup that hires for all 12 roles will burn runway on organisational scaffolding before it has a product worth measuring.
• Waterfall role silos. If the 12 roles turn into 12 handoffs, you've rebuilt the function-organised company that product teams were meant to replace. Roles should clarify ownership, not add queue length.

The honest limitation: a published framework describes intent, not adoption. Whether Cambridge's 12 roles hold up will depend on whether practitioners can map them onto real teams without doubling headcount — and the source article itself does not report live case data, so treat this as a design proposal, not a validated benchmark.

What should PMs take from it?

For a practicing product manager, the immediate Monday-morning move is diagnostic, not structural. List the 12 roles against your team. Find the two or three that nobody owns. In most teams, those gaps — metric definition ownership, experiment quality control, data governance — are exactly where the recurring arguments live.

As product organisations move from "we use data" to "data work has owners," expect role-definition frameworks like this one to become a standard part of team topology decisions, sitting alongside squad-and-tribe models rather than replacing them.