Data Product Adoption

Data product adoption is the extent to which intended consumers actually use a data product for supported purposes. Product counts describe an inventory and can rise through renaming or fall through retirement and consolidation. They do not establish use or value.

A product can replace redundant definitions or pipelines while still being consumed through caches, extracts, or snapshots. Distinguish unnecessary independent maintenance from copies needed for performance, offline work, reproducibility, or recovery. Manage retained copies through source and version records, update and correction rules, retention, and responsible owners.

Four signals

• Verified consuming teams and uses. A single team can be a valid product audience; more teams indicate broader reach. Query logs show access accounts, not necessarily teams. Combine query tags, report or application metadata, owner mappings, and consumer confirmation to identify uses.
• Unnecessary duplicate work retired. After validating the replacement’s functionality, quality, performance, and recovery, record which separately maintained paths were removed and what upkeep was avoided. Deleting an extract alone does not prove trust, and retaining a legitimate copy does not disprove adoption.
• Time from a new consumer’s question to a usable answer. Break it into discovery, access approval, interpretation, and execution. Compare similar requests and consumer groups. An increase can reflect complexity, queueing, or unfamiliar users, so investigate before blaming discoverability or documentation.
• Satisfaction, asked directly. The product owner’s own measure is “the satisfaction of her consumers.” A short recurring question to the people who use it finds problems no log reveals — a field they do not trust, a definition they quietly reinterpret.

Catalog registrations measure documented inventory. Raw query volume can be dominated by scheduled jobs or tests. Count verified uses and consumers within a stated period, document the paths observed and gaps such as downstream exports, and separate automation from the business uses it serves.

When adoption is low, investigate these four possible causes

• Nobody can find it. Check discovery from the consumer’s starting point. Better descriptions or navigation may help, but the effort depends on whether the underlying catalog and access paths work.
• It does not answer their question. The grain is wrong, a needed dimension is missing, or history does not go back far enough. This is a roadmap input, not a promotion problem.
• They do not trust it. Check whether freshness objectives are stated and met, failures are visible, and field meanings are clear. Reliability evidence and usable documentation address different gaps; determine which is blocking the consumer.
• Switching costs more than staying. Their existing pipeline works. Migration needs a reason and often a hand — and the reason has to be better than the platform team’s preference.

Each of those points at a different fix, which is why “adoption is low” is not yet a diagnosis. Talking to a few consumers can provide an initial account of the obstacles. Compare what they report with the intended audience and observed uses before treating it as a diagnosis for everyone.

What can and cannot be attributed

Report observations separately from attributed effects. The distinction applies to cost and time as well as business outcomes.

Record the baseline, period, workload, and concurrent changes. A before-and-after difference alone does not identify the product’s effect: a reduction from ten hours to six could come from the product, added staff, or both. Multiple contributing inputs do not make attribution inherently impossible, but the evaluation design must separate their effects well enough to support the claim.

Ownership coverage complements adoption. Define the in-scope inventory and required fields, such as an accepted owner and contract, as with catalog coverage. The ratio identifies management gaps; it does not predict where the next incident will occur. Read adoption alongside quality, reliability, support, and maintenance cost to assess whether the product is useful and sustainable.

How adoption fits with contracts, ownership, domain operating models, and the mesh and fabric framings is worked through in Who Is This Table For?.

References

• Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (2019-05-20)
• Snowflake, QUERY_HISTORY view