Same Table, New Name: The Data Product Quality Gap
Data mesh gave the industry a real idea: treat data like a product. Most organizations took the label and left the operating model behind. Here is the gap, and what it takes to close it.
Written and Prepared by Zeynep Balci, Snr. Data & AI Consultant.
Most enterprises adopted the term “data product” and skipped the operating model behind it. A renamed table in the data catalog still has no accountable owner, no data quality bar set by its consumers, and no feedback loop. That gap stays invisible with a handful of products and becomes unmanageable at a few hundred. This article covers the principles most organizations skip, why ownership, quality, compliance, lineage and adoption each decay at a different speed, and how Alex Solutions makes data product health visible across a whole portfolio so teams act before a consumer finds the problem first.
In this article
The Rename Is Not the Operating Model
Everyone in data knows the pitch. Stop treating data as a byproduct of applications, and start treating it the way a product team treats a product: with an owner, a defined audience, a quality bar set by the people who use it, and a way for those people to push feedback back upstream.
Most enterprises adopted the vocabulary and skipped the substance. A table gets renamed customer_360_data_product in the data catalog. Nothing else changes. The owner field still points at a distribution list nobody reads, the quality bar is whatever the last engineer assumed, and the first time anyone asks who is accountable, the answer is “it’s complicated.”
Calling something a data product does not make it behave like one. A real product has three things a renamed dataset almost never does.
An accountable owner
Someone has to own the trade-offs: what gets fixed first, what “done” means, who gets called at 2am. Most data products have a name in a field and nobody who plays that role day to day.
A consumer-set quality bar
The builder is a poor judge of whether it is good enough. They already know its shortcuts. The bar has to come from whoever depends on it, and be checked continuously.
A feedback loop, not a one-way publish
A product team hears from its users constantly through tickets, requests and churn. Most data products publish once and never hear back. The first sign of trouble is a bad number in an executive dashboard, with no way to trace where it came from.
This is the most common starting point Alex Solutions sees inside enterprise estates: a data catalog full of product labels, and very little product behaviour behind them.
Why Data Products Stall at Scale
None of this is controversial in principle. It falls apart on arithmetic. A handful of data products can be governed by good intentions and a spreadsheet a steward keeps up to date.
A few hundred, spread across a dozen domains, cannot. At that point, “we review data product health quarterly” quietly becomes “we review the ones someone complained about.”
The organizations that get furthest with data products are not the ones with the best intentions. They are the ones who made health something you can see, not something you have to ask about.
That is the real gap between a renamed table and a data product. It is not ambition. It is whether ownership, quality, compliance posture and lineage are visible and current enough to act on before someone downstream finds the problem first.
How Alex helpsThis is the arithmetic problem Alex’s Enterprise Data Operations Platform is built around. Metadata orchestration and automated data lineage keep data product health visible and current across a whole portfolio, so “quarterly review” never turns into “review the ones someone complained about.”
The Principles Most Organizations Skip
Data mesh named four principles. “Treat data as a product” was only one of them, and it is the only one most organizations adopted. That is exactly why it did not stick.
Practice has since added a fifth that the original framing underplayed: adoption. Here is how the five usually play out.
Domain ownership
The team closest to the data owns it end to end, not a central team inheriting something it did not build.
Data as a product
The one principle everyone adopted, usually alone. Without the other four, it is a naming convention.
Self-serve data platform
Consuming domains should not need a ticket and a three-week wait to get access to a product.
Federated computational governance
Rules stay consistent across domains but get enforced automatically, not by a central committee everyone waits on.
Adoption
A data product that is technically excellent and nobody uses is not a success story. It is a cost centre with good documentation. Usage has to be tracked and acted on with the same seriousness as uptime, not assumed because something got published.
What Happens When Only One Principle Lands
The result is predictable. Products have no real owner and no self-serve access. Governance is either a bottleneck or theatre, and no one watches whether anyone uses the thing. The label changed. Nothing that makes a product a product arrived.
Federated computational governance carries the most risk here. It is where regulation, data security policy and access rules either get enforced automatically or not at all. Alex Solutions treats that enforcement as an operational job, run continuously by governance agents, rather than an item on a committee calendar.
Five Attributes, Five Decay Rates
Ownership, quality, compliance, lineage and adoption do not erode on the same schedule. That is part of why a single status chip hides so much.
Ownership decays with the org chart
Reorgs, attrition, a team disbanded mid-quarter. The easiest of the five to miss, because the field still has a name in it.
Quality decays with upstream change
A schema shifts, an ETL step drops rows, a vendor redefines a field. The product looks the same until a consumer’s numbers stop adding up.
Compliance decays with the outside world
A regulation is amended or a residency rule tightens. A product compliant on day one can drift out of compliance with no change made to it at all.
Lineage decays with refactoring
Pipelines get rewritten and tools get swapped. The trail stops being accurate, usually discovered during an audit or right after something breaks.
Adoption decays without anyone watching
Nobody cancels a data product the way they cancel a subscription. They stop querying it and rebuild what they need somewhere else. Without usage tracked as its own signal, a product can sit at zero real consumers for months while every other dimension still reads “healthy.”
Score these five together as one number and you lose the ability to tell which clock is running out. Score them separately, and a product that is solid on data quality but has drifted on ownership, or quietly lost its audience, stops hiding behind an average that looks fine.
How Alex helpsAlex scores Quality, Compliance, Ownership, Lineage and Adoption as five independent signals, not one blended average. A product drifting on a single dimension shows up immediately instead of hiding behind the other four.
Renamed Dataset vs. Actual Data Product
The difference is easiest to see side by side. Each row is a question a consumer should be able to answer in minutes, without messaging the team that built the product.
| Attribute | Renamed dataset | Actual data product |
|---|---|---|
| Ownership | A name in a field, set once at creation | An accountable owner, current and reachable |
| Quality bar | Assumed by whoever built it | Defined by the people who consume it |
| Compliance posture | Checked at onboarding, then forgotten | Revisited as the product and its context change |
| Lineage | Reconstructed after something breaks | Traceable on demand, before it is asked for |
| Adoption | Assumed because it shipped | Tracked as real usage, reviewed like any other signal |
How Alex helpsA gap Alex surfaces does not stop at a report. It becomes a tracked, assigned action, and the moment it is resolved, the catalog record updates itself. That is agentic data operations in practice at Alex Solutions: the right-hand column becomes the state your catalog is actually in.
What It Looks Like When It Works
In a working model, every domain publishes through the same health gate. Consumers on the other side, whether analysts, applications or AI agents, only build on products that pass.
domain
domain
domain
domain
Health Gate
analysts · apps · AI agents
Every domain’s data products pass the same five-signal health gate before consumers build on them.
A consumer can find the data product, see its current standing across all five dimensions at a glance, and know within minutes whether it is safe to build on today. No message to the producing team required.
When something needs fixing, it becomes a tracked, assigned action with an owner and a deadline. It does not wait as a bullet on next quarter’s steering committee agenda.
When the org reshuffles, checking who still owns what, and who still uses what, is part of the reshuffle checklist. Alex Solutions customers treat that as routine, not something a governance team discovers is broken six months later.
Where to Start
You do not need a portfolio-wide program on day one. These five moves get a data product practice off the ground without another manual review cycle.
1
Pick one domain, not the whole catalog
Product thinking dies the moment it is applied everywhere at once with no one accountable for any one part.
2
Let consumers define “good”
Ask the people downstream what they would need to trust this without double-checking it themselves.
3
Decide how you will notice decay first
A remediation process with no detection layer in front of it just waits for someone to complain.
4
Treat the org chart as a governance input
Ownership drifts every time a team reorganizes. Build that into the review cycle, not around it.
5
Make health visible where people already look
If checking a data product’s status means opening a spreadsheet nobody remembers exists, it is not governed. It is hoped for.
This is the layer Alex Solutions spends most of its time on: helping data teams see where ownership, quality, compliance, lineage and adoption stand for the data products they have already built, without adding another manual review cycle to keep up with.
Frequently Asked Questions
What is the difference between a dataset and a data product?
A dataset is a table or file in a data catalog. A data product has an accountable owner, a quality bar defined by its consumers, a current compliance posture, traceable lineage and measured adoption. Renaming a dataset gives it none of those things.
Why do data mesh and data product programs stall?
Most programs adopt the “data as a product” principle on its own and skip domain ownership, self-serve access and federated computational governance. Manual review works for a handful of products but breaks down at a few hundred across many domains.
How should data product health be measured?
Score ownership, data quality, compliance, lineage and adoption as separate signals. Each decays at a different rate for different reasons, so a single blended score hides exactly the drift you need to catch.
Does automated data lineage matter for data products?
Yes. Lineage decays every time a pipeline is refactored or a tool is swapped. A data lineage tool that maps flows automatically keeps the trail accurate on demand, rather than reconstructing it after an audit finding or an incident.
How does Alex Solutions support data products?
Alex’s Enterprise Data Operations Platform scores Quality, Compliance, Ownership, Lineage and Adoption independently across the whole portfolio. Gaps become tracked, assigned actions, and catalog records update automatically once they are resolved.
Working Through This at Your Organization?
Compare notes with a team that has seen what works for organizations further along than “we renamed the tables.”
