“Data as a product” has been absorbed into the bloodstream of every data org over $100M in revenue. The phrase is everywhere. The discipline almost nowhere. What most teams call a data product is a renamed table with a Confluence page taped to it.
The slogan only earns its keep when four conditions hold simultaneously. Drop any one and you have a dataset with marketing.
A named owner with budget authority. Not a steward. Not a DRI on a wiki. A person whose comp plan moves with the product’s outcomes, who can hire, who can deprecate, who can say no to a stakeholder. If the owner cannot kill a downstream consumer’s request without escalation, they are not an owner. The most common failure: making a senior analytics engineer the “owner” while the actual roadmap is set by whichever VP shouts loudest in the quarterly review. That’s stewardship with extra steps.
A contract, in code, that breaks builds when violated. Schema, semantics, freshness, completeness, and lineage — all expressed as machine-checkable assertions that run on every change to the producing pipeline. The contract is not a markdown file. It is dbt tests, Great Expectations suites, schema registries, or whatever your stack supports — but it executes, and a violation prevents deployment. If your “contract” lives in a doc that gets updated after the breakage is reported by a consumer, you have a postmortem template, not a contract.
An SLA the owner is on the hook for. Freshness, availability, accuracy. Published, monitored, paged on. The SLA must be tight enough that downstream consumers can plan against it and loose enough that the owner can actually hit it on a bad day. The honest version of an SLA includes the consequence of a miss — a credit, a postmortem requirement, a visible scorecard. Without consequence, the SLA is decoration.
Discoverability and self-service that work for someone who has never met the owner. A new analyst on a different team should be able to find the product, understand its semantics, query it, and get an answer to “is this the right thing for my question?” without booking a meeting. If the answer to that question routinely requires a Slack DM, the product is not productized — it’s tribal knowledge with a URL.
The fifth thing, which separates the orgs that get value from this from the ones running performance theater: deprecation works. Real products have a lifecycle. Real owners sunset things. If your data org has never killed a “data product” because consumers had migrated off it or because it was redundant, you don’t have products. You have an accumulating inventory.
The economics shift when these conditions hold. Consumer teams stop building shadow pipelines because the canonical product is reliable enough to bet on. Producing teams stop firefighting because contracts catch issues at the source. Platform investments stop being justified by abstract “data quality” metrics and start being justified by the cost of incidents the contracts prevented.
Here is the test we use when auditing a data org claiming to run on data products: pick three products at random from their catalog. For each, ask:
- Who is the owner, and what specifically happens to their compensation if the SLA is missed for a quarter?
- Show me the contract, in code, in the repo. Show me a recent CI run where a proposed change was blocked because it would have violated the contract.
- Show me the last time this product was deprecated, version-bumped with a breaking change, or had a consumer migrated off of it on a published timeline.
If they cannot answer all three concretely, what they have is a data warehouse with better naming conventions. That is not nothing — naming matters — but it is not what the slogan promises. And the gap between the slogan and the discipline is exactly the gap between the data orgs that get budget renewed and the ones that get restructured every eighteen months.
The discipline is unsexy. Owners. Contracts. SLAs. Deprecation. None of it photographs well in a strategy deck. All of it is what makes the slogan true.