Measurement is shared work. Accountability cannot be shared so widely that it disappears.
A product manager, designer, researcher, engineer, analyst, and leader may all contribute to the same measurement system. They do not all own the same decisions. When those distinctions remain implicit, definitions drift, broken evidence waits for somebody else, and dashboards outlive the questions they were meant to answer.
The useful question is not:
Which discipline owns measurement?
It is:
Who is accountable for each decision that keeps this measurement useful?
Own decisions, not job-title territory
Assign ownership at the level of a measurement slice: one question, workflow, set of evidence, metrics, and intended use.
Four accountabilities normally matter.
| Accountability | What the owner must be able to decide | Typical owner |
|---|---|---|
| Purpose and action | Why the measurement exists and what decision or response it supports | Product or service owner |
| Definition and interpretation | What the workflow, event, or metric means; how it is calculated; where its limits sit | Product, analytics, or a named definition steward |
| Implementation and reliability | How evidence is captured, tested, monitored, repaired, and changed safely | Engineering or data owner |
| Use and review | Where the measurement is used, when it should be reviewed, and whether it should be changed or retired | Product and the team using the evidence |
One person may hold several accountabilities in a small team. The important thing is that the hats remain visible.
Shared contribution still matters
Explicit ownership does not turn measurement into a hand-off chain.
Design and research may clarify what people are trying to achieve, which steps are meaningful, and what event data cannot explain. Engineering may identify a more reliable source than the interface event originally requested. Analytics may show that a proposed denominator answers a different question. Operational colleagues may know that completion often happens outside the product.
The owner is accountable for reaching and maintaining a defensible decision. They are not expected to make it alone.
Example: the service-quotes workflow
For a marketplace helping customers request, compare, and accept service quotes, ownership might look like this:
| Decision or artefact | Accountable owner | Essential contributors |
|---|---|---|
| What counts as an eligible service request | Product owner | Operations, analytics, providers |
What quote.accepted proves |
Definition steward | Product, engineering, analytics |
| Whether the event fires from an authoritative state change | Engineering owner | Analytics, product |
| How quote acceptance rate is calculated | Metric owner | Product, analytics |
| Whether a monitoring view still supports a real decision | Dashboard owner | Product team, operations, leadership |
| When downstream work-completion evidence is good enough to use | Evidence owner | Operations, research, analytics |
This prevents a familiar failure: every team can see the acceptance rate, but nobody can approve a definition change, explain an unexplained movement, or decide that the metric should be caveated.
Ownership needs decision rights
Putting a name beside a metric is not enough.
An owner needs permission and a route to:
- approve or reject a definition change;
- stop a release when critical instrumentation is not testable;
- add a visible caveat when evidence is incomplete;
- prioritise repair when confidence is too low for the intended decision;
- remove a dashboard or metric that no longer has a job;
- escalate when the issue crosses product, data, privacy, or operational boundaries.
Without those decision rights, ownership is only contact information.
Separate creation from stewardship
The person who creates an artefact may not be the person best placed to maintain it.
A consultant may design a dashboard. An analyst may define the first formula. An engineer may implement the event. Ownership must survive team changes, project closure, and handover.
For every important measurement slice, record at least:
Purpose owner
Definition steward
Implementation owner
Primary users
Review trigger or cadence
Escalation route
This is enough to make handover possible without inventing a large governance structure.
Test whether ownership is real
Choose one important metric and ask:
- Who can explain what decision it supports?
- Who can approve a change to its definition?
- Who investigates when the source data breaks?
- Who decides whether a caveat is acceptable?
- Who checks that the dashboard is still used?
- Who can retire it?
If the answers are unclear, the metric is being borrowed from the organisation rather than owned by it.
Measurement remains collaborative. Ownership is what gives that collaboration a point of accountability when something must be decided, repaired, or stopped.