The data-product operating model, end to end.

The phrase “data product” has become decorative. Operationally, what it should mean is straightforward: every analytic asset has a name, an owner, a documented purpose, a service-level expectation, and a path to retire it. When those five things are in place, the platform survives reorganizations and attrition. When they are absent, the platform is a graveyard of queries no one will admit to writing.

What follows is the operating model we have stood up across financial-services, public-sector and enterprise teams. It is not elegant. It is the one that has worked.

The unit: a data product

A data product is a named, owned, documented surface that other people in the organization consume from. Examples:

• A dashboard used in a weekly operating review.
• A semantic-layer metric exposed to BI tools.
• A scheduled report sent to a regulator.
• A feature store table consumed by a production model.
• A document-AI extraction service consumed by an application.

Each is a product. Each has the same five obligations: name, owner, purpose, SLA, retirement criteria.

The roles

Data product manager

Accountable for the portfolio of data products serving a business area. Owns intake, prioritization and the conversation with consumers. Not the builder; the person who decides what gets built and when, and who says no.

Producer team (engineers + analysts)

Cross-functional pod that builds, ships and operates a set of data products. Members are not rotated in for individual tickets. The same pod that ships a product owns its incidents.

Consumer

The named business stakeholder whose decision the data product informs. Every product has at least one. Products with no named consumer are candidates for retirement.

Platform team

Owns the shared infrastructure: warehouse, semantic layer, orchestration, governance. Does not own individual data products, but provides the paved road on which producer teams ship.

The intake

One front door, not five. Requests for new analytics work flow through a single intake (a form, a queue, a channel, the medium matters less than the singleness). The data product manager triages, asks the qualifying questions, and either accepts into a backlog, returns with clarifying questions, or declines with a documented reason.

The qualifying questions are the operating model in miniature:

• Whose decision does this inform?
• What changes when they have it?
• How will we know it is being used?
• What happens if we say no?

The SLA

Every product has a freshness SLA (how recent is the data?), an availability SLA (when is the product expected to be up?), and an incident-response SLA (what is the response time when it breaks?). Different tiers have different thresholds; we usually settle on three tiers, ranging from regulator-grade at the top to best-effort at the bottom.

The SLAs are public to consumers, and the producer team is on rotation against them. This is the part of the operating model most often skipped, and the part whose absence breaks trust fastest.

The on-call

Yes, data products need on-call. When the daily pipeline fails at two in the morning before a board meeting, someone has to fix it before the executive sees the blank dashboard. The rotation is named, the runbooks exist, the alerts have owners, and the incidents are post-mortemed.

On-call is also the discipline that surfaces fragility. The pipeline that pages someone every three weeks becomes the next re-engineering priority.

The retirement criteria

Every data product has stated conditions under which it gets retired: usage falls below a threshold, the consumer changes role, the underlying source goes away, a successor product subsumes it. Without retirement criteria, the catalog grows monotonically and the platform spends an increasing fraction of its capacity maintaining dead weight.

We have walked into organizations with thousands of dashboards, ninety percent of which had not been opened in a year. The fix is not a big spring-cleaning project. The fix is the policy.

The catalog

One place where every data product is registered, with its owner, purpose, SLA tier, dependencies, and usage statistics. The catalog is the source of truth for what exists. Anything that is not in the catalog does not exist, which is to say, it does not get on-call coverage, it does not get maintenance, and consumers know not to depend on it.

The cadence

The model runs on a recurring cadence:

• Weekly: producer team standup, intake triage, incident review.
• Monthly: portfolio review with consumers, SLA performance, retirement candidates.
• Quarterly: capacity planning, platform investment, access review.

None of this is exotic. It is the operating cadence of a mature software team applied to analytics. The reason analytics teams resist it is that it makes scope explicit, and explicit scope is harder to live inside than fuzzy scope. It is also the only way quality compounds.

The mistake we see most often

Organizations adopt the language (“data products”) and none of the discipline. The catalog is empty, the SLAs are aspirational, the on-call rotation is theoretical. After six months, the conversation reverts: people complain about reliability, the team is asked to do more with less, and the organization concludes data products do not work.

They work. The five obligations are not optional. The operating model is the obligation, not the slogan.