Data product
Also: Data product, Data-as-a-product, DaaP, Produit de donnees, Produit data
A data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.
What it is
A data product is a reusable data asset that is designed, delivered, and maintained like a real product rather than a one-off report or an ad hoc extract. It has an accountable owner, a known set of consumers, an explicit quality contract, and a clear link to business value.
Unlike a raw table sitting in a warehouse, a data product is packaged for consumption. It typically bundles:
- The data itself (a curated dataset, metric, feature set, or API).
- Metadata and documentation (schema, definitions, lineage, ownership).
- Service guarantees (freshness, completeness, accuracy, availability).
- Access and interfaces (SQL table, API endpoint, dashboard, or feed).
Why it matters
Most organizations drown in datasets nobody trusts and cannot find. Treating data as a product fixes the incentives:
- Accountability: someone is responsible for keeping it correct and useful.
- Trust: consumers get documented, guaranteed quality instead of guessing.
- Reuse: one well-built product serves many teams, reducing duplicated pipelines.
- Value tracking: usage and outcomes are measured, so low-value products can be retired.
This mindset underpins modern approaches like data mesh, where domain teams own and publish their own data products.
How it is used in practice
Building and running a data product usually involves:
1. Define the consumer and use case. Who needs this, and to decide what?
2. Assign an owner. A product owner (often in a business domain) is accountable.
3. Set a data contract. Agree on schema, freshness, and quality thresholds (a service level agreement, or SLA).
4. Build and publish. Expose it through a stable interface with documentation in a catalog.
5. Monitor and iterate. Track usage, quality, and value; version changes carefully.
A concrete worked example
A retailer creates a "Customer 360" data product.
- Owner: the Customer Analytics domain lead.
- Consumers: marketing (segmentation), finance (lifetime value), and an AI team (churn model features).
- Contract: refreshed daily by 6 a.m., 99 percent identity match rate, GDPR compliant fields only.
- Interface: a governed table plus a documented API.
- Value: measured by campaign lift, model accuracy, and hours saved versus rebuilding joins each time.
Because it is a product, the marketing team no longer stitches together spreadsheets, the AI team gets stable features, and finance uses the same customer definitions everyone else does. When the schema must change, the owner versions it and notifies consumers instead of silently breaking downstream work.
Frequently asked questions
What is a data product?
A data product is a reusable data asset managed like a real product rather than a one-off report: it has an accountable owner, an identified set of consumers, an explicit quality contract, and a measurable link to business value. In practice it bundles the data (dataset, metric, feature set or API), its metadata and documentation, service guarantees on freshness and accuracy, and a stable access interface.
What is the difference between a data product and a table in the warehouse?
A raw table is stored; a data product is packaged for consumption. The table exists without documented ownership, quality commitment or known consumers, so nobody knows whether to trust it. A data product adds an owner, a documented schema with lineage, an SLA on freshness and completeness, and a stable interface, which is what makes it reusable by several teams.
Why should a CMO or CFO care about data products, not just the data team?
Because the owner of a data product usually sits in a business domain, not in IT, and the consumers are marketing, finance and AI teams. A shared "Customer 360" product means marketing segments, finance computes lifetime value and the churn model all use the same customer definitions instead of three divergent spreadsheets. The value is also tracked on business terms: campaign lift, model accuracy, hours saved.
What goes into a data contract?
A data contract sets what consumers can rely on: the schema, the refresh frequency, and quality thresholds expressed as an SLA. For a "Customer 360" product it could be a daily refresh by 6 a.m., a 99 percent identity match rate, and GDPR compliant fields only. The point is that any change to these terms is versioned and announced to consumers instead of silently breaking downstream work.
Where do you start when creating a first data product?
Start with the consumer and the decision, not with the pipeline: who needs this data, and to decide what? Then assign an accountable owner, agree the data contract on schema, freshness and quality, publish through a stable interface documented in a catalog, and monitor usage, quality and value so low-value products can be retired. Skipping the first step is how organizations end up with datasets nobody uses.