TL;DR
A data product is a productised, well-documented, SLA-backed dataset (or data interface) treated as a product with explicit consumers, ownership, and quality standards. The data-product concept emerged 2020–22 as a response to data-stack chaos: instead of treating analytical datasets as ephemeral by-products of pipelines, treat them as managed products with users, lifecycle, and accountability. Data products are the central concept in <a href="/glossary/data-mesh" class="text-brand-600 underline decoration-brand-200 underline-offset-2 hover:text-brand-700">data mesh</a> architecture but are widely useful even in centralised data teams.
What is a data product?
A data product is a managed, productised dataset or data interface — treated with the same product-management discipline as a software product. It has explicit consumers, documented purpose, defined SLAs (freshness, accuracy, availability), versioning, and an owner who is accountable for quality.
The pattern emerged in response to the recognition that analytical-data assets had become critical operational dependencies for many teams (BI dashboards, ML models, customer-facing analytics, operational tools) — but were being managed with the discipline of one-off SQL transformations rather than the discipline of products.
Properties of a data product
- Discoverable: documented in a catalog with clear purpose, owner, and access process
- Addressable: a stable, well-known location (table name, API endpoint, semantic-layer metric)
- Trustworthy: documented data-quality checks running continuously
- Self-describing: schemas, semantics, and refresh cadences documented inline
- Interoperable: conforms to organisation-wide standards for naming and joining
- Secure: access controlled per data-classification policy
- SLA-backed: documented promises about freshness, completeness, and uptime
Examples of data products
| Type | Example |
|---|---|
| Curated dimensional model | A star-schema sales mart with 24-hour refresh SLA |
| Reverse-ETL output | Customer-segment data piped to Salesforce, refreshed hourly |
| Embedded analytics dataset | Pre-aggregated metrics powering customer-facing dashboards |
| ML feature store | Production feature definitions with consistent training/serving values |
| Operational metric layer | Headless BI metrics consumed by AI tools and dashboards |
| Streaming topic | Kafka stream of order events with documented schema evolution |
Why data products matter
Without product discipline, analytical datasets accumulate as a tangled web of dependencies. Pipelines break silently; downstream consumers discover the breakage when their dashboards go blank; ownership is unclear; the cost of any change becomes prohibitive because the consumer graph is unknowable.
Treating critical datasets as products inverts this: each product has an owner accountable for quality, documented consumers for impact assessment, SLAs for trust, and a deprecation process for change. Companies that adopt the data-product pattern report dramatically faster downstream-tool development because consumers can rely on data products rather than hand-rolling integrations against raw data.
Common pitfalls
- 1. Calling everything a data product. Not every dataset needs product discipline. Apply the pattern to datasets with multiple consumers and operational criticality; ad-hoc analyst tables don't need SLAs.
- 2. Skipping consumer involvement. Data products have users; users have requirements. Building data products without consumer input produces shelfware. Treat data-product development as product-managed work, not engineering-only.
- 3. Treating data products as static. Data products evolve as consumers' needs change. Versioning, deprecation, and roadmap discipline matter the same way they do for software products.
Related concepts
Data mesh is the broader architectural pattern centred on data products. Data marts are a precursor concept; data products extend marts with stronger product discipline. Data governance is the policy framework that data products operate within. Headless BI and metric stores produce metric-level data products.
At a glance
- Category
- Business Intelligence
- Related
- 5 terms
Frequently asked questions
What's the difference between a data product and a dataset?
A dataset is data; a data product is data managed with product discipline — explicit owner, documented consumers, defined SLAs, lifecycle management. Many datasets aren't data products and don't need to be. Reserve the data-product label for assets that meet the discipline bar.
Do you need data mesh to have data products?
No — data products are useful in any organisational structure, including centralised data teams. Data mesh extends the concept to decentralised domain ownership. The data-product pattern is broadly applicable; the data-mesh organisational pattern is one specific application.
Who owns a data product?
Ideally a domain team that owns both the source data and the product (the data-mesh pattern). In centralised data teams, ownership often sits with a data-engineering or analytics-engineering team. The non-negotiable is that ownership is explicit and accountable, not diffuse across multiple teams.
Sources
- Zhamak Dehghani, Data Mesh (2022)
- Thoughtworks data-product publications
- Modern Data Stack reports (2024–25)
Fairview is an operating intelligence platform that consumes data products directly — using documented schemas, SLAs, and ownership boundaries rather than treating analytical data as raw warehouse tables to be re-modelled per consumer. Start your free trial →
Siddharth Gangal is the founder of Fairview. He built the data-product-aware ingestion layer after watching companies invest in dbt and data-product discipline only to have new BI and operating tools force them to expose raw warehouse tables anyway — defeating the entire point of the productisation work. The right operating tool consumes the products you've already built.
See it in Fairview
Track Data Product automatically.
14-day free trial. No credit card. First data source connected in 5 minutes.