What is a data product?
Tags: #data products, #data mesh, #data governance
Definition and examples of data products – and what is merely a component.
What makes a deliverable a data product?
A definition (and what it is not)
According to Gartner, data products are defined as follows:
“A Data Product is an integrated and self-contained combination of data, metadata, semantics and templates. It includes access and logic-certified implementation for tackling specific data and analytics (D&A) scenarios and reuse. A Data Product must be consumption-ready (trusted by consumers), up to date (by engineering teams) and approved for use (governed). Data Products enable various D&A use cases, such as data sharing, data monetization, analytics and application integration.”
The short version: a data product is a data deliverable you treat as a product.
Four things must be in place:
- Customers: named customer groups, not “everyone”
- Ownership: a team with the mandate to make decisions and bear the consequences
- A promise: expectations regarding access, refresh, documentation, quality and change
- Value: verifiable, tied to real usage
When these are in place, you get repeatability as a side effect. Multiple teams can use the same deliverable over time, without everyone having to create their own variant.
If you cannot point to who uses it and what you promise when it changes, it is rarely a data product. It is an important table.
Is this a data product?
- Can you point to named customers (teams or roles that use this)?
- Does someone have an explicit promise to these customers regarding access, refresh and notification of change?
- Is the cost of errors high enough that it is worth governing over time?
Three yeses → data product candidate. Otherwise: component for now.
Examples
Deliverables that often deserve product status:
- Orders/order lines with standardised event logic: one status model and one time logic for orders, returns and cancellations
- Metrics layer for financial KPIs: definitions and calculations that multiple reports build on
- Customer 360 – core: stable customer definition, history and join keys across surfaces
- Consent and opt-out foundation: managed, audited foundation for contactability
- Product catalogue for analytics: consistent attributes (category, brand, margin, season) with a documented lifecycle
These are not data products: staging/intermediate layers (stg_*, cleaned_v17), internal helper tables and one-off artefacts. None of these have named customers, a promise or governance.
What separates a product from a component in practice, and how to govern an entire portfolio, is the topic of the next chapter.
