Who Is This Table For? Data Products and Domain Ownership

A platform team renames its curated tables “data products,” adds a description field, and announces the change. Six months later there are two hundred data products, the same people ask the same questions in the same chat channel, and nobody can say which of the two hundred anyone depends on. The label was free. Everything that makes the label true was not.

What distinguishes a data product from a table someone published is a set of obligations, and the useful question is which of them your organization has actually taken on.

It is not a product without a consumer

The first test is the one most often skipped: name the consumer, and name the decision or system that depends on the output. Not “the business” — a team, a report, a service.

That test matters because it is the only thing that makes the rest decidable. Which fields must be stable follows from who reads them. What freshness is required follows from how quickly the decision is made. Whether a schema change is breaking follows from what someone promised. Without a named consumer, every one of those becomes a guess that the producing team makes on the consumer’s behalf and usually gets wrong in the safe direction — promising everything, changing nothing, and shipping slowly.

The data mesh literature approaches this as product thinking applied to analytical data, and its list of required characteristics is a good checklist precisely because each item is a consumer-facing property rather than a technical one. In Dehghani’s formulation a domain data product must be discoverable (“a data product must be easily discoverable”), addressable (“should have a unique address following a global convention”), trustworthy and truthful (“no one will use a product that they can’t trust”), self-describing (“quality products require no consumer hand holding to be used”), inter-operable and governed by global standards, and secure and governed by a global access control (“accessing product datasets securely is a must”).

Turning characteristics into obligations

Those six are properties. What an organization can actually hold someone to is a smaller set of artifacts, and this is the translation that makes the difference between a definition and an operating model.

Characteristic	What it becomes in practice
Discoverable, addressable	Registration in a catalog with a stable location, and a name that does not change when the implementation does
Self-describing	Field-level meaning, including which metric definition each measure follows. The test is whether a new consumer can use it without asking anyone
Trustworthy	Stated quality dimensions that are measured — not a quality score, but the specific data quality properties consumers rely on — plus a freshness objective someone reports against
Inter-operable	Shared identifiers and conformed dimensions so results can be joined across domains, which is interoperability in the plain sense and the hardest one to retrofit
Secure	Access enforced by the platform rather than by each consumer’s arrangement with the producer
All of the above, as a promise	A data contract: what the fields mean, what may change and with what notice, what the quality and freshness commitments are

One obligation is missing from most programs and it is the one consumers notice first: support. Someone has to answer “this number looks wrong” within a stated time. A product with a contract and no support channel is a document, and consumers respond by building their own copy — which is how a platform ends up with nine versions of revenue.

The owner is a role, not a name in a field

Data mesh names the accountable role explicitly: “a data product owner makes decisions around the vision and the roadmap for the data products, concerns herself with the satisfaction of her consumers.” Read that as a job description rather than a title, and it becomes clear what a data product owner actually decides.

• What the fields mean, and therefore which change requests are definition changes needing announcement rather than bug fixes.
• What is promised and what is not, which is the contract — and the courage to leave things out of it, because a promise about every column is a promise you will break.
• Which consumer request gets built next, which is a roadmap and the part that makes this a product role rather than a maintenance one.
• When to deprecate, including telling a consumer that a field they use is going away.

Note how little of that is technical. It also does not replace the operational roles — the distinction between the owner, steward, and custodian still applies, and a product owner who is also the only engineer is a staffing problem wearing a governance label.

Domain ownership moves work, it does not remove it

The organizing principle behind all of this is decentralization: pushing responsibility, in the mesh formulation, to “people who are closest to the data.” The argument is sound — the team that produces the data understands what it means, and a central team translating for twenty domains becomes the bottleneck and the wrong place for the knowledge.

What the argument does not say is that the work shrinks. It moves onto teams whose main job is something else, and three conditions decide whether that succeeds.

• Capability. A domain team now needs to model data, write tests, run a pipeline, and answer consumer questions. Expecting that without engineers produces published tables that nobody maintains — worse than a central bottleneck, because the failures are distributed and invisible.
• Incentive. A team measured entirely on its own product outcomes will deprioritize a dataset other teams need. Someone has to make the data product part of what that team is accountable for, or decentralization becomes neglect.
• A platform that makes it cheap. This is the third mesh principle, described as a “high-level abstraction of infrastructure that removes complexity and friction of provisioning and managing the lifecycle of data products.” Without it, every domain rebuilds pipelines, tests, and access control from scratch — and the cost of being a producer exceeds what any domain will volunteer for.

Standards are what keep the result joinable, which is the fourth principle: federated computational governance, characterized as “decentralization and domain self-sovereignty, interoperability through global standardization, a dynamic topology” with the platform enforcing the standards automatically. The operating model behind that — who decides which rules are global, and how enforcement happens — is governance proper, and it is worth settling before the first domain publishes rather than after the third incompatible customer identifier appears.

Mesh and fabric answer different questions

These two terms are often presented as competing choices, which makes the decision harder than it is. They address different problems.

	Data mesh	Data fabric
What it is about	Who is responsible: decentralized ownership organized by business domain, “to provide more ownership to the producers”	How access is made easy: “a modern data architecture designed to democratize data access across an organization”
Primary mechanism	Organizational — domain teams, product owners, contracts, federated standards	Technical — integration and automation that “uses intelligent and automated systems to break down silos,” driven by “active metadata (which uses knowledge graphs, semantics and AI)”
What it does not settle	How the plumbing works	Who decides what a field means, or who answers when it is wrong

Which means they are compatible, and the honest framing is that a fabric’s automation can serve a mesh’s domains. It also means neither is a purchase that produces the other: buying metadata automation does not create owners, and declaring domain ownership does not make discovery work. Data fabric as a term is also used loosely by vendors, so when it appears in a proposal the useful question is which specific capability is being offered — cataloguing, virtualization, lineage, policy enforcement — rather than whether to adopt the concept.

Adoption is the only evidence that any of it worked

The measure programs reach for is the count of data products, and it is the one number that cannot fail. Renaming tables increases it. Data product adoption is harder to move and worth more, and four signals show it.

• Distinct consuming teams, counted from query logs rather than from intentions. One consumer means an internal table with a nicer name.
• Copies that stopped existing. The strongest signal available: a consumer deleting their own extract because the product is now reliable enough.
• Time from a consumer’s question to a usable answer. Rising means the discoverability and self-describing claims are not holding.
• Consumer satisfaction, asked directly. Mesh’s own guidance puts the product owner’s focus on “the satisfaction of her consumers” and measuring it, which is unusual in data work and exactly right — the people who use the thing are the only ones who know whether it is usable.

Value measurement has a second trap worth naming, because it wastes a lot of effort. Attributing business outcomes to a dataset is mostly not possible: revenue moved for many reasons and the data product was one input. What is attributable is cost and time — duplicate pipelines retired, hours not spent reconciling two numbers, a decision that used to take a week. Claim those, and describe the rest as enabling rather than causing.

Where to start

Programs that begin by defining a taxonomy and renaming everything produce a spreadsheet. Programs that begin with one painful dataset produce a capability.

• Pick one dataset that at least two teams already copy. The duplication is your evidence of demand and your baseline.
• Name its owner and its consumers, and write the contract with them rather than for them. Expect the conversation to reveal that the two consumers wanted different things, which is information you needed.
• Commit to a freshness objective and a support channel, and report against both. This is the part that earns trust and the part programs skip.
• Get the copies deleted. Until that happens you have added a dataset rather than replaced two.
• Only then generalize, and let the second domain reuse whatever made the first one cheap.

One product that two teams rely on and nobody copies teaches an organization more than a catalog of two hundred, and it is the only version of this work that survives a change of sponsor.

References: Dehghani, Data Mesh Principles and Logical Architecture (2020-12-03); Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (2019-05-20); IBM, What Is a Data Fabric?.