Data Products and Domain Ownership

In an illustrative scenario, 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.

Dehghani describes product thinking for analytical data through six qualities: consumers can discover the data, address it through a stable interface, assess its trustworthiness, understand its meaning, combine it through shared conventions, and access it securely. Each quality needs technical implementation and an operating commitment; a catalog label alone supplies neither.

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.

• 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

In Dehghani’s account, a data product owner connects the product’s vision and roadmap to consumer satisfaction. The following decisions need accountable ownership, with local authority and shared approval boundaries made explicit.

• What the fields mean. A bug fix restores an approved definition; a definition change proposes a new meaning. Both can alter published results. Assess affected periods, consumers, and numeric impact, then apply the contract’s notification, restatement, and approval criteria. A definition change also needs agreement on the new meaning.
• What is promised and what is not. State the supported fields, uses, quality targets, and change policy. Scope commitments to what the team can maintain and make unsupported uses explicit.
• 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.

These decisions require business judgment informed by engineering constraints. The distinction between the owner, steward, and custodian still applies. One person can hold several roles if authority, skills, time, backup coverage, and any required separation of duties are supported. Shared definitions and organization-wide controls may require decisions beyond the product owner’s local mandate.

Domain ownership moves work, it does not remove it

Data mesh places domain responsibility near the people who understand the data and its uses. This can reduce translation through a central team, provided the domain has the capability and mandate to maintain its analytical products. Proximity to the source helps establish meaning; it does not by itself establish every consumer’s requirements.

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 reduces repeated work. The mesh platform principle calls for abstractions that simplify provisioning and product lifecycle management. Shared pipeline, testing, and access capabilities let domains spend less effort rebuilding infrastructure and more on their products.

Federated computational governance combines local decisions with global conventions needed for interoperability. Domain and platform representatives decide which rules apply across products and which remain local, then implement enforceable policies in the platform. This governance model needs explicit authority and exception paths before conflicting identifiers or definitions spread.

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 — cataloging, virtualization, lineage, policy enforcement — rather than whether to adopt the concept.

Measure adoption alongside quality and value

The count of registered products describes an inventory; renaming tables can increase it without changing their usefulness, and retirement can reduce it. Data product adoption concerns actual use. Read the following signals alongside quality, reliability, support, and operating cost.

• Verified consuming teams and uses. One team can be a valid product audience. Team count measures reach, not product status. Query logs reveal observed accounts, which may be shared or split across teams. Combine query tags, BI or application metadata, owner mappings, and consumer confirmation; state the period, observed paths, and unidentified uses.
• Unnecessary duplicate work retired. Removing a separately maintained pipeline can show reduced duplication after the replacement is validated. Caches, offline extracts, reproducible snapshots, and recovery copies can remain legitimate ways to consume the product; their existence does not disprove adoption.
• Time from a consumer’s question to a usable answer. Separate discovery, access approval, interpretation, and execution. Compare similar questions and consumer groups; a rise prompts investigation and may reflect a harder workload rather than worse documentation.
• Consumer satisfaction, asked directly. Ask whether users can find, interpret, and rely on the data. Their answers add context that logs cannot supply; combine that feedback with measured quality and support outcomes.

Separate observed changes from effects attributed to the product. A retired pipeline and its avoided charges can be documented, but net savings also include migration and new operating costs. Less reconciliation time may free capacity without reducing payroll. Faster answers can reflect staffing or easier questions as well as better data. State the baseline, workload, comparison period, and concurrent changes. Stronger causal claims, whether about time, cost, or business outcomes, need an appropriate comparison or experiment and its assumptions; being one input among several does not make an effect inherently unmeasurable.

Where to start

A bounded use case makes the operating obligations testable. Taxonomy can support discovery, but pair it with a product whose consumers and unmet needs are known.

• One starting candidate is a dataset that two teams already copy. Confirm why the copies exist and what each consumer needs; duplication can indicate demand without proving that both copies should disappear. A product serving one team can also be a valid starting point.
• 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.
• Retire only unnecessary duplication. Validate replacement functionality, quality, performance, and recovery before removing an old path. For retained copies, record source and version, refresh and correction propagation, retention, and ownership.
• Only then generalize, and let the second domain reuse whatever made the first one cheap.

A maintained product with known consumers gives the organization evidence about contracts, support, and adoption. Use that evidence to improve the next product and explain the program’s value when priorities or sponsors change.

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?
• Snowflake, QUERY_HISTORY view