By Andrew Tan
The product that wasn't
I was on a call with a data platform team last month. They had just finished a six-month initiative to "productize their data assets." The presentation was impressive: a data product catalog with thirty-seven entries, each with an owner badge, a freshness SLA, and a consumer satisfaction score. The team had read the McKinsey report. They had adopted the terminology. They were proud.
Then I asked a simple question: "When the customer churn prediction model drifts and starts flagging the wrong accounts, who gets paged?"
Silence. Then three people started talking at once.
The data scientist who built the model said it was the ML platform team's problem — they managed the inference endpoint. The ML platform team said it was the data engineering team's problem — the feature pipeline was producing stale inputs. The data engineering team said it was the source system's problem — the upstream CRM had changed a field mapping three weeks ago and nobody told them. The CRM team, when they were finally dragged into the thread, said the field mapping was documented in a Jira ticket that the data team had been cc'd on.
The customer churn prediction model was listed as a data product. It had an owner badge in the catalog. But when it actually failed — when it started damaging the business in real time — ownership fragmented into four teams, none of whom had agreed on whose problem this was.
This is not a tooling failure. This is a definition failure.
What "data product" actually means
The phrase "data product" has become popular for good reasons. It shifts the conversation from "pipelines and tables" to "value and consumers." It encourages teams to think about who uses the data, what decisions they make with it, and what quality standards they need. This is all genuine progress.
But the term also creates a dangerous illusion. Calling something a product implies a set of organizational commitments that most data teams have not actually made. A real product — software, hardware, a service — has:
- A single person or team accountable for its behavior in production
- Defined SLAs that are monitored, not just documented
- A change management process that evaluates downstream impact
- Incident response procedures with clear escalation paths
- A retirement plan when the product is no longer viable
Most "data products" have none of these. They have a catalog entry, a freshness badge, and a consumer survey that gets sent once a quarter. The gap between the language of product management and the reality of data operations is where things break.
The runtime is where ownership dies
The hardest part of owning a data product is not the modeling logic, the feature engineering, or the dashboard design. It's the runtime behavior: what happens when the pipeline is actually running in production, dealing with real data, real failures, and real surprises.
Here are the runtime responsibilities that most data product definitions conveniently omit:
Schema drift handling. Upstream systems change their output without warning. A column gets renamed. A type changes from integer to string. A nullable field suddenly starts returning nulls. The data product owner needs to detect this, assess downstream impact, and either adapt or halt production before bad data propagates. Most teams find out about schema drift when the dashboard breaks, not when it starts.
Late data and backfill coordination. A batch job misses its window. A streaming consumer lag spikes. A third-party API delivers yesterday's data today. The owner needs to know whether the product's consumers can tolerate staleness, how to communicate the delay, and how to trigger a backfill without creating duplicates or inconsistencies. This is operational work, not analytical work.
Cost accountability. Data products consume compute, storage, and egress. Who pays for them? Who decides when the cost exceeds the value? I've seen teams discover that a "productized" dataset was costing $40,000 per month to produce and was being queried by exactly two people, one of whom had left the company. Without runtime ownership, nobody is watching the economics.
Consumer impact assessment. When a data product changes — new columns, different aggregations, corrected historical data — the owner needs to know who is affected and how. In practice, this means maintaining consumer lineage, communicating changes in advance, and managing versioning. Most data catalogs show lineage at the table level. They don't show which executive's quarterly forecast depends on a specific derived metric.
Failure recovery with authority. When a data product breaks at 2 AM, the person who gets paged needs more than technical skill. They need the authority to make decisions: skip a bad batch, replay from a checkpoint, temporarily disable a consumer, or call an executive and say "we need to pause the campaign until we fix the targeting model." If the "owner" is a junior data analyst who needs three approvals to touch production, they don't actually own the runtime. They just own the documentation.
The organizational trap
Data teams often adopt product language without product authority. They're told to "think like product managers" but given none of the organizational support that makes product management work.
A software product manager can say no. They can deprioritize a feature request, sunset an old product, or push back on a deadline because quality standards aren't met. A data product "owner" usually cannot. They're a matrixed coordinator between data engineering, analytics, ML, and business stakeholders, with responsibility for outcomes but no authority over the resources that produce them.
This creates a specific pathology I see everywhere: the data product owner becomes a professional apologizer. They track freshness SLAs they can't enforce. They document schemas they don't control. They run consumer satisfaction surveys that generate action items for other teams. They're accountable for the product's success but given only enough control to describe its failures.
The result is cynical data teams who learn to game the system. Freshness SLA missed? Change the SLA. Consumer complaint? Add it to the backlog for the platform team. Schema drift incident? Write a post-mortem that recommends "better communication" and move on.
None of this is malicious. It's what happens when you assign ownership without authority.
The practical test
If you want to know whether your data products are real products, try this test:
Pick one catalog entry. Ask these questions:
- If this product fails in production right now, who is woken up?
- Does that person have the authority to fix it without a committee meeting?
- Can they tell you the exact cost of producing this product last month?
- Can they list every downstream consumer and what each one uses it for?
- If they needed to change the schema tomorrow, do they have a process to assess and communicate impact?
- If the product's value drops below its cost, can they retire it?
If the answer to any of these is "no" or "it depends," you don't have a data product. You have a data output with a product label.
This is not a moral failing. Most data teams are doing the best they can with organizational structures that predate the product movement. But pretending that a catalog entry equals a product commitment doesn't help anyone. It creates the illusion of maturity while hiding the same operational gaps.
Where the shift actually happens
Fixing this doesn't require a new tool or a new framework. It requires organizational clarity:
Define ownership at the runtime level, not the catalog level. The owner is not the person who wrote the description. The owner is the person who can answer the six questions above without checking Slack.
Give owners authority, not just accountability. If someone owns the runtime, they need control over the pipeline, the compute budget, the consumer communication, and the escalation path. Ownership without authority is a performance review waiting to happen.
Separate product ownership from data domain ownership. The person who understands the customer domain is not always the person who can manage production operations. In small teams, these are the same person. In larger teams, they shouldn't be forced to be. What matters is that the operational owner has a clear contract with the domain expert, not that one person does everything.
Measure runtime health, not catalog completeness. A data product catalog with 100% completion scores and broken pipelines is worse than no catalog at all. It creates false confidence. Track the metrics that matter: incident response time, schema drift detection speed, consumer-reported error rates, cost per consumer. These are boring operational metrics. They're also the only ones that tell you whether the product works.
What we see
At layline.io, we work with teams who have made this shift — and teams who are still struggling with it. The pattern is consistent: the teams that succeed are the ones who stopped treating "data product" as a metadata exercise and started treating it as an operational commitment.
The technology helps, but it's not the deciding factor. What matters is whether the organization is willing to give someone the authority to own the runtime — including the hard decisions about cost, quality, and retirement that come with it.
The teams that do this don't just have better data products. They have data teams that aren't burning out. Because nothing destroys morale faster than being accountable for outcomes you can't control.
If your team is wrestling with data product ownership and trying to figure out what runtime accountability actually looks like in practice, get in touch. We've seen this pattern across enough organizations to know what works — and what looks good on a slide deck but falls apart in production.
Andrew Tan is a serial entrepreneur and founder of layline.io, building enterprise data processing infrastructure that handles both batch and real-time workloads at scale.
