What is the purpose of a Data Product?

A data product makes a dataset reusable and trustworthy across teams, so consumers can rely on it without understanding its underlying implementation. The team that generates the data is accountable for serving it well to consumers it may never meet.

How do you use a Data Product in product management?

Design data products with: clear ownership (a team that is responsible for quality), a schema contract (stable API for consumers), quality SLOs (freshness, completeness), and documentation (what it contains, how to use it). Treat breaking schema changes like breaking API changes.

Where does the concept of a Data Product come from?

Data products as a concept emerged from the Data Mesh architecture, introduced by Zhamak Dehghani in her influential 2019 ThoughtWorks article "How to Move Beyond a Monolithic Data Lake." Data products apply product thinking (ownership, SLOs, discoverability) to data artefacts, treating them as first-class products with consumers and quality guarantees.

What are common mistakes with a Data Product?

Relabelling an existing table a data product without adding ownership, SLAs, documentation and a consumer feedback loop is branding, not product thinking. Building data products no one asked for repeats the build-it-and-they-will-come mistake in a new medium. Optimising purely for the producing team's convenience rather than consumer ergonomics defeats the reusability premise. Treating a data product as finished at launch, with no roadmap or deprecation policy, leaves consumers stranded when it inevitably changes.

🎁

Data Product

Q: What is a Data Product?

A dataset treated with product discipline: it has an owner, documented quality and freshness guarantees, and is discoverable by those who need it.

Q: What is an example of a Data Product?

User Activation Data Product: Owner: Growth team. Contents: user signup, activation events, cohort assignments. Schema: users (user_id, signup_date, plan), activations (user_id, activation_date, days_to_activate). SLO: 99% completeness. Consumers: Growth, Product, Finance. API: Snowflake schema + dbt exposure.

A curated, reusable data asset

Data & AnalyticsAnalytics & Datatype: 'data_product'interface: BaseNode

View in Graph

▼On this page

Description Properties Lifecycle Relationships Graph Position Related Entities

Description

A data product is a dataset treated with the same discipline as a shipped product: it has an owner, documented quality and freshness guarantees, and is discoverable by the people who need it. The team that generates the data is accountable for serving it to consumers it may never meet.

See moreSee less

Origin & evolution

The term comes from Zhamak Dehghani, who defined data mesh in 2019 while a principal consultant at Thoughtworks and developed its principles through 2020. "Data as a product" is one of the four principles, alongside domain ownership, a self-serve platform, and federated computational governance. The argument is that applying product thinking to analytical data, with owners and consumers and quality bars, fixes the neglect that central data lakes tend to breed. She set it out in full in Data Mesh (O'Reilly, 2022). Practice since has tempered the more ambitious org-restructuring claims, while the data-product unit itself has stuck.

How it works in practice

A logistics company's fulfilment domain owns a delivery_performance data product. It publishes a documented table updated hourly, with a stated freshness SLA and a named owner. A finance dashboard and a customer-facing tracking service both consume it. When finance needs a new field, it files a request against the product's owner rather than reverse-engineering a raw warehouse table. The fulfilment team treats those consumers as customers: a breaking change goes through deprecation, not a surprise.

Data product vs. its neighbours

Data source is raw input, the system of record a pipeline reads. A data product is a curated, owned output built to be consumed, often assembled from several sources.
Data domain is the organisational boundary that owns products. The domain is the team and its remit; the product is the specific asset it ships.
Dashboard is one way to consume a data product. A dashboard presents; a data product is the governed dataset behind it that many dashboards and services can share.

In the graph

In the Unified Product Graph, a data product anchors part of the data and analytics region exactly as data mesh frames it. A domain produces it (data_domain_produces_data_product), a pipeline feeds it (data_pipeline_feeds_data_product), it serves dashboards (data_product_serves_dashboard), and services consume it (data_product_consumed_by_service). Those edges encode the contract Dehghani describes: every data product has a clear producer, a feeding pipeline, and named consumers, so an orphaned product with no consumer is visible at a glance.

Worked example: Trellis

Trellis packages a curated view of approved-versus-reverted agent changes as a reusable data product so a director like Nora or the gatekeeper Sam can inspect how the agent has behaved over any time window. It draws on the event schema and glossary term definitions so the counts are unambiguous and the same report means the same thing to both personas.

Preview

Presets

title

data_product_type

sla_freshness

Data Product

Workspace Activation Dataset

Data product typedataset

Sla freshness< 6 hours

Properties

Type-specific fields on BaseNode

data_product_typeenum

Classification of the data product (UPG-579 Option B).

reportdatasetstreamapiml_featureother

sla_freshnessstring

Freshness SLA commitment (e.g. "< 1 hour")

Inherited from BaseNode (6 fields)

idstringrequired

Unique identifier (UUID)

typeNodeTyperequired

Discriminator for the entity type

titlestringrequired

Display name

descriptionstring

Optional detailed description

statusstring

Lifecycle status

tagsstring[]

Freeform tags for filtering

Lifecycle

4 phases, initial: alpha · template: MATURITY

All lifecycles

Relationships

4 edge types connected to this entity.

Parents

Entities that can contain this type

Data Domaindata_domain_produces_data_product

Cross-References

Contextual links across the graph

Dashboarddata_product_serves_dashboard

Data Pipelinedata_pipeline_feeds_data_product

Servicedata_product_consumed_by_service

Graph Position

1parent

🎁Data Product

3cross-ref

Definition

A data product is a curated, documented dataset with a named owner and quality guarantees, reusable by other teams without knowing its implementation. It connects data pipelines to the business domains that consume it.

Usage Guidance

Design data products with: clear ownership (a team that is responsible for quality), a schema contract (stable API for consumers), quality SLOs (freshness, completeness), and documentation (what it contains, how to use it).
Treat breaking schema changes like breaking API changes.

Anti-Patterns

Relabelling an existing table a data product without adding ownership, SLAs, documentation and a consumer feedback loop is branding, not product thinking.
Building data products no one asked for repeats the build-it-and-they-will-come mistake in a new medium.
Optimising purely for the producing team's convenience rather than consumer ergonomics defeats the reusability premise.
Treating a data product as finished at launch, with no roadmap or deprecation policy, leaves consumers stranded when it inevitably changes.

Examples

User Activation Data Product

Owner: Growth team. Contents: user signup, activation events, cohort assignments. Schema: users (user_id, signup_date, plan), activations (user_id, activation_date, days_to_activate). SLO: <24h freshness, >99% completeness. Consumers: Growth, Product, Finance. API: Snowflake schema + dbt exposure.

Data Product

A curated, reusable data asset

Data & AnalyticsAnalytics & Datatype: 'data_product'interface: BaseNode

View in Graph

▼On this page

Description Properties Lifecycle Relationships Graph Position Related Entities

Description

See moreSee less

Origin & evolution

How it works in practice

Data product vs. its neighbours

Data source is raw input, the system of record a pipeline reads. A data product is a curated, owned output built to be consumed, often assembled from several sources.
Data domain is the organisational boundary that owns products. The domain is the team and its remit; the product is the specific asset it ships.
Dashboard is one way to consume a data product. A dashboard presents; a data product is the governed dataset behind it that many dashboards and services can share.

In the graph

Worked example: Trellis

Preview

Presets

title

data_product_type

sla_freshness

Data Product

Workspace Activation Dataset

Data product typedataset

Sla freshness< 6 hours

Properties

Type-specific fields on BaseNode

data_product_typeenum

Classification of the data product (UPG-579 Option B).

reportdatasetstreamapiml_featureother

sla_freshnessstring

Freshness SLA commitment (e.g. "< 1 hour")

Inherited from BaseNode (6 fields)

idstringrequired

Unique identifier (UUID)

typeNodeTyperequired

Discriminator for the entity type

titlestringrequired

Display name

descriptionstring

Optional detailed description

statusstring

Lifecycle status

tagsstring[]

Freeform tags for filtering

Lifecycle

4 phases, initial: alpha · template: MATURITY

All lifecycles

Relationships

4 edge types connected to this entity.

Parents

Entities that can contain this type

Data Domaindata_domain_produces_data_product

Cross-References

Contextual links across the graph

Dashboarddata_product_serves_dashboard

Data Pipelinedata_pipeline_feeds_data_product

Servicedata_product_consumed_by_service

Graph Position

1parent

🎁Data Product

3cross-ref

Definition

Usage Guidance

Design data products with: clear ownership (a team that is responsible for quality), a schema contract (stable API for consumers), quality SLOs (freshness, completeness), and documentation (what it contains, how to use it).
Treat breaking schema changes like breaking API changes.

Anti-Patterns

Relabelling an existing table a data product without adding ownership, SLAs, documentation and a consumer feedback loop is branding, not product thinking.
Building data products no one asked for repeats the build-it-and-they-will-come mistake in a new medium.
Optimising purely for the producing team's convenience rather than consumer ergonomics defeats the reusability premise.
Treating a data product as finished at launch, with no roadmap or deprecation policy, leaves consumers stranded when it inevitably changes.

Examples

User Activation Data Product