Data Product Adoption

Data product adoption is the extent to which people actually use a data product instead of working around it. It is worth naming separately because the number most programs report — how many data products exist — cannot go down, and rises fastest when tables are renamed.

The distinction matters for a specific reason: a data product’s whole justification is that consumers stop building their own version. If they have not, the organization now maintains the product and the copies.

Four signals

• Distinct consuming teams, counted from query logs rather than from stated intentions. One consuming team means an internal table with a better name — which is fine, and is not a product.
• Copies that stopped existing. A consumer deleting their own extract is the strongest evidence available, because it is costly: they are betting their reporting on your freshness and support. Nobody does it as a favour.
• Time from a new consumer’s first question to a usable answer. This is the operational test of two claims the product makes — that it is discoverable and that it is self-describing, or as the data mesh formulation puts it, that “quality products require no consumer hand holding to be used.” Rising time means one of those claims is false.
• 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.

Two numbers that look like adoption and are not: registrations in a catalog, which measure documentation effort, and raw query volume, which one scheduled job can dominate. Query volume from distinct teams is the version worth reading.

When adoption is low, the cause is usually one of four things

• Nobody can find it. Discoverability is the cheapest failure to fix and the easiest to overlook, because the producing team always knows where it is.
• 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. No stated freshness commitment, or one that has been missed without anyone saying so. Trust is why objectives reported publicly do more for adoption than better documentation.
• 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. Asking two consumers is usually faster than inferring it from logs.

What can and cannot be attributed

Programs are often asked to show business value, and the honest answer distinguishes two kinds of claim.

Claim the left column with numbers and describe the right column as enabling rather than causing. Overclaiming here is expensive in a specific way: the first time a sponsor tests an attribution that does not hold, every other number in the report becomes suspect.

A useful complement is ownership coverage — what share of shared datasets has a named owner and a contract at all — which is the same idea as catalog coverage and predicts where the next incident will be. Coverage tells you whether the practice is spreading; adoption tells you whether it is working.

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

Reference: Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (2019-05-20).