The Data Product Ownership Model: What "Owned" Actually Means

Almost every enterprise data catalog now has an owner field. Almost every one of those fields is lying.

The data-as-a-product idea has won the argument. Most large data organizations we work with have adopted the language: data products, domain ownership, a catalog with an assigned owner for every important table. What they have not adopted is an ownership model that survives contact with a reorg. A name in a metadata field is not ownership. It is a hope, recorded once, and rarely checked again. The gap between the recorded owner and the person who would actually get paged when a pipeline breaks at 3 AM is where most data platforms quietly rot.

This paper is about closing that gap. Not the tooling, which is mostly fine. The operating model underneath the word "owner."

Why a name in the catalog is not an ownership model

Walk into a data organization that has been running a catalog for two years and audit the owner field on its top 50 data products. In our engagements the pattern is consistent: somewhere between 30% and 50% of those owners have changed teams, changed roles, or left the company. The field still shows their name. Nobody updated it, because updating it is nobody's job, and because the moment you write a name into a field the organization tells itself the ownership question is settled.

It is not settled. Ownership is not an attribute of a table. It is a standing commitment by a funded team to keep a promise about that table, and standing commitments decay the instant they stop being maintained. The catalog records the label. It does not record whether the label still means anything.

The contrarian point we make on every engagement is this: assigning an owner is the easy 5% of the work, and organizations act as if it were the whole job. The hard 95% is deciding what the owner is accountable for, giving them the capacity to deliver it, and granting them the authority to defend the interface. Skip any of those three and you have produced an orphan with a name attached. We have seen catalogs with 800 data products and, by our count, fewer than 100 that anyone was genuinely accountable for.

The three transfers that make ownership real

Real ownership requires transferring three distinct things to a named team. Most programs transfer one, occasionally two, almost never all three.

Accountability for a service level objective. An owner has to be accountable for something measurable, or the accountability is decorative. Borrow the discipline from site reliability engineering: a data product should publish an explicit service level objective, the same way a service does. Freshness within 60 minutes of the source commit, 99% of the time, measured monthly. Schema stability with a 12 week deprecation window on any breaking change. Completeness above an agreed threshold. Without a target, "owner" means "the person we blame after the fact." With one, it means "the team on the hook for a promise consumers can plan around."

Capacity to sustain it. Ownership costs engineering time, and that time has to come from a budget line, not from goodwill. A domain team asked to own eight data products on top of shipping features will deprioritize the data products every quarter, because that is what their performance review rewards. We size sustained ownership at roughly 15% to 20% of one engineer per active data product per year for maintenance, schema evolution, and consumer support. A domain with ten data products is carrying close to two full-time engineers of standing obligation. If that headcount was never funded, the ownership was never real, whatever the catalog says.

Authority over the interface. The owner has to be able to say no. No, we will not add that column on your timeline. No, we will not break the contract for one consumer's convenience. No, you cannot bypass the published interface and read our raw tables directly. An owner without the authority to refuse becomes a request queue, and a request queue is not an owner. It is a shared mutable resource with a name on it, which is the distributed-monolith failure mode dressed in product language.

Accountability without capacity produces burnout and attrition. Capacity without authority produces a team that ships whatever it is told and owns nothing. Authority without accountability produces a gatekeeper. You need all three pointed at the same named team, or the model does not hold.

The ownership spectrum and the paved road in between

Ownership can sit at several points on a spectrum, and teams tend to argue about the endpoints while the answer lives in the middle.

At one end, a central data platform team owns every data product. This scales badly. The central team becomes a bottleneck, has no domain context, and ends up owning schemas it does not understand for producers it cannot influence. At the other end, every domain owns its data products end to end, including the infrastructure, the pipelines, the observability, and the on-call. This is the full data mesh vision, and it fails in a specific way: each domain reinvents the platform, badly, and you get 40 slightly different ways to define a service level objective and no shared tooling to enforce any of them.

Conventional data-mesh advice says federate ownership to the domains and let a thousand data products bloom. We disagree with the sequencing, not the destination. Federating ownership before you have a paved road produces orphans faster, because you have handed domains a responsibility with no supporting infrastructure and no template for what "good" looks like. The domains that were already strong build decent data products. The rest produce abandoned pipelines with an owner field filled in, and the platform team spends the next two years cleaning up after a decentralization it was not resourced to support.

The model that works is neither endpoint. The platform team owns the paved road: the ingestion framework, the catalog, the observability, the contract-enforcement layer, the default service level objective template, and the on-call tooling. The domain team owns the data product on that road: the schema, the semantics, the quality, the service level objective, and the promise to consumers. Ownership is federated. Capability is centralized. Zhamak Dehghani's original data-as-a-product principle assumed exactly this self-serve platform underneath, though it is the part most adopters skip, because building a paved road is slow and renaming your tables "data products" is fast.

The lifecycle nobody funds: birth, sustain, sunset

Ownership is treated as a birth event. It is a lifecycle. Three phases, and organizations fund the first one and ignore the other two.

Birth is easy. A team spins up a data product, fills in the catalog, publishes a schema, and announces it in a channel. Everyone celebrates. The sustain phase is where the cost actually lives: patching pipelines when a source system changes, evolving the schema without breaking consumers, answering the questions of every new team that wants to build on the product, and holding the service level objective when the underlying data gets messy. Sustain runs for the entire life of the product, which is usually measured in years, and it is the phase no capacity plan accounts for.

Sunset is the phase almost nobody executes. Data products accumulate the way legacy code accumulates, and for the same reason: retiring one requires proving nobody depends on it, which requires lineage nobody maintained. So the orphaned products stay, each carrying a maintenance tax and a compliance surface, until the catalog is 60% noise and consumers cannot tell the 200 live products from the 600 dead ones. A real ownership model includes an explicit decommissioning path with a named decision-maker, the same way a disciplined modernization program budgets for deleting legacy code rather than leaving it running forever. If nobody is allowed to kill a data product, nobody is really the owner of it. They are its caretaker in perpetuity.

Regulatory pressure is making orphaned ownership expensive

For years the argument for real ownership was operational: better reliability, lower on-call burden, faster consumer onboarding. That argument was always true and never quite urgent enough to force the funding. Regulation is changing the math.

The EU AI Act, in force since August 2024 with high-risk obligations phasing in through 2026, requires documented data governance for the datasets that feed high-risk AI systems, including their provenance and quality criteria. You cannot document the governance of a data product that has no accountable owner. The NIST AI Risk Management Framework makes the same assumption from the other direction: it treats named accountability and documented data provenance as baseline controls, not aspirations. An auditor asking "who is accountable for the quality of this training dataset" does not accept a stale catalog field as an answer. When the honest answer is "someone who left in 2024," the finding writes itself.

Financial-services clients face parallel pressure from long-standing data-lineage and data-quality supervisory expectations, which assume a named, accountable data owner as a matter of course. A platform with a real ownership model produces this evidence as a byproduct of operating. A platform with owner fields full of departed employees produces it through a frantic archaeology project two weeks before the audit.

What to put in place this quarter

If your catalog is full of owner fields you do not trust, the fix is not a bigger catalog. It is a smaller, real ownership model applied to the products that matter. Start here.

1. Audit the owner field on your top 50 data products against current HR reality. Count how many owners still hold the role. That orphan rate is your baseline, and it is usually worse than leadership expects.
2. For the 10 products that feed revenue or regulatory reporting, publish an explicit service level objective with a freshness target, a stability window, and a quality threshold. An owner with no target is not accountable for anything.
3. Fund the sustain phase openly. Put the 15% to 20% per-product engineering cost into a domain's headcount plan as a named line, so ownership competes with feature work on the budget instead of losing to it silently.
4. Grant owners the authority to refuse: the right to reject a breaking change, enforce a deprecation window, and block direct reads around the published interface. Write it down, and back one refusal publicly, so the authority is known to be real.
5. Build the paved road before you federate further. If domains lack a shared ingestion, catalog, observability, and contract layer, fix that first. Federating ownership onto bare ground manufactures orphans.
6. Give every data product a decommissioning path with a named decision-maker and a lineage check. A product no one is allowed to retire is a liability no one truly owns.

The organizations pulling ahead on data are not the ones with the largest catalogs. They are the ones where a small set of named teams are genuinely accountable for a small set of well-run data products, funded to sustain them and empowered to defend them. Ownership is not a field you fill in. It is a promise you resource. The sooner data leaders treat it that way, the sooner the catalog stops lying.