Your data product has contributors but no owner

The data product had been flagging incorrect values in the weekly executive dashboard for three days before the investigation concluded. The analyst had traced it to the data engineering team, the data engineering team had traced it to the data source system owner, and the data source system owner had shown that the data they sent was exactly what their application produced. All three had done their jobs correctly. The data pipeline had ingested exactly what the data source had delivered, and nobody had specified what the data source was supposed to deliver. The data product had no owner — only contributors.

This is the pattern that sits underneath most data quality failures, governance breakdowns, and incident response gaps. The technical work is done correctly. The accountability for whether the output is fit for the decision it is supposed to support was never assigned.

Most data platforms have data pipeline owners — engineers accountable for whether data arrives on schedule, whether the load completes, whether the data pipeline runs. Almost none have data product owners — people accountable for whether the data that arrives is right for the decision it is supposed to support. The gap between those two accountabilities is where data quality failures live.

The attribution gap

When a data quality issue surfaces, the investigation follows a predictable path: from the analyst who noticed the discrepancy, to the data engineer who owns the data pipeline, to the data source system team who own the upstream data. Each stop tends to produce the same finding — this part was done correctly. The data pipeline ingested what it received. The data source system sent what its application produced.

The investigation ends at technical correctness because that is where accountability ends. Nobody was accountable for whether what arrived was fit for the use case it was built for. The failure lives in the gap between "the data arrived" and "the data was right" — a gap most data platforms have no role to close. When the gap produces a visible failure, the question is not what went wrong but who should have prevented it. The answer is usually nobody, because the role does not exist.

What the role owns

A data product owner is accountable for things a data pipeline owner is not. The definition of "fit for purpose" agreed with the business consumer before the data product is built — not after a data quality incident forces the question. SLAs for correctness, not just freshness or delivery completeness. The backfill decision when data is found to have been wrong: whether to correct historical records, which downstream consumers to notify, and who authorises the correction. The language that makes the data product defensible in a quarterly business review. And the escalation path when a data quality threshold is breached.

None of these are engineering decisions. They sit at the intersection of what the business needs and what the data platform can deliver — which is exactly why no one owns them by default. Engineering teams own the technical delivery. Business teams own the decisions that depend on the data. The question of whether the data that was delivered supports the decision that was made belongs to neither function, so it defaults to nobody.

The mandate problem

The most common response to a data product ownership gap is to assign the responsibility to someone who already exists — usually the data steward. The data steward owns governance: data lineage, access control, the data dictionary. Assigning data product ownership to the data steward puts a governance role in a product accountability position. The title changes. The gap stays.

The second most common response is to assign it to a senior domain expert — someone who knows what "correct" means for a specific business use case. A subject matter expert brings the domain knowledge to define correctness, but typically lacks the technical interface to work with engineering and the organisational mandate to enforce SLAs. Without both, the role becomes an informal coordinator: someone who knows what should be true but cannot make it so.

A data product owner without authority to define SLAs and escalate data quality decisions is accountability without power. Creating the role deliberately requires more than a job description — it requires the CTO or executive sponsor to define the remit, establish a reporting line, and give the person the authority to make commitments on behalf of the data platform.

The leadership mandate

The structural reason this role does not exist in most data platforms is that it falls between two functions. Engineering owns delivery. The business owns the decisions that depend on the data. Nobody owns the bridge between them, and in the absence of an explicit decision to create that role, both sides assume the other is handling it. The assumption holds, quietly, until a data quality failure forces the question.

At that point, the investigation finds not a failure of execution but a failure of design. Three people did their jobs correctly. The data product had no owner.

The path forward

The question worth asking now — before the next data quality incident rather than after it — is not which monitoring threshold needs adjusting. It is: for each data product that a business decision depends on, who is accountable if the data is wrong? Not who built the data pipeline. Not who uses the output. Who owns the data product.

In most organisations, that question does not have a clean answer. That is the gap.