Data Products in Data Mesh Infrastructure
Data products are the central unit of value in a Data Mesh — not tables, not pipelines, not warehouses. Here's what they are, what makes a good one, and how they work in practice.
Definition
A data product is a curated, governed, and user-oriented data asset — produced by a domain team, designed for external consumption, and managed like a software product with quality standards, documentation, and versioning.
The shift from "data asset" to "data product" is more than semantic. Traditional data assets are byproducts of operational processes — stored because they exist, not because they've been designed for use. Data products are intentionally built for their consumers: with known schemas, quality guarantees, and interface contracts.
In a Data Mesh, data products are what domain teams expose to the rest of the organisation. The self-serve infrastructure makes them discoverable. Federated governance keeps them trustworthy. Domain ownership keeps them accurate.
What makes a good data product?
Discoverable
Every data product is registered in a catalog and can be found by any authorised consumer across the organisation, with clear metadata and descriptions.
Secure & governed
Access is controlled, usage is audited, and privacy policies are enforced — automatically and programmatically, not through manual review.
High quality
Quality SLAs are defined and monitored. Consumers know what freshness, completeness, and accuracy they can expect.
Self-describing
Schema, lineage, ownership, update frequency, and examples are all part of the data product interface — not tribal knowledge held by one person.
Reusable
Designed for multiple consumers with different needs. The same customer data product might serve marketing, finance, and operations teams.
Interoperable
Follows organisation-wide standards for format, naming, and access — so it can be joined with data products from other domains without transformation gymnastics.
Data products vs. traditional data assets
Aspect
Traditional asset
Data product
Ownership
Centralised data team
Domain team that produces the data
Quality
Best effort, often unknown
Explicit SLAs with monitoring
Discoverability
Tribal knowledge / documentation by exception
Catalog-registered with metadata
Interface
SQL tables and ad-hoc schemas
Versioned, documented APIs and datasets
Consumer view
Raw tables requiring downstream cleaning
Curated, validated, consumer-ready
The data product lifecycle
Creation
Domain team identifies a dataset that other teams need, defines its schema, quality standards, and access model.
Publication
The product is registered in the data catalog, documentation is written, and access policies are applied.
Maintenance
The domain team monitors pipeline health, responds to consumer feedback, and evolves the schema with backward compatibility.
Monitoring
Quality metrics, freshness, and consumer usage are tracked continuously. Alerts fire when SLAs are breached.
Iteration
New versions are released based on evolving consumer needs, with deprecation policies for old versions.
Technology ecosystem
Data catalogs
Datahub, Amundsen, Atlan, dbt docs
Data platforms
Snowflake, BigQuery, Databricks, DeltaLake
Quality & governance
Great Expectations, Soda, Monte Carlo
Pipelines
dbt, Airflow, Spark, Fivetran
Ready to start?
Let's build something exceptional
Tell us about your data challenge and we'll find the right solution together — fast, practical, and ROI-focused.