A data product is a self-contained package of data with a clear purpose, a named owner, and a defined way to consume it. It belongs to exactly one domain, a business area such as Sales or Finance. It exists to be discovered and reused across teams, not locked inside the team that built it.
In the Data Product Standard application, the data product is the unit that everything else describes: ports, contracts, quality, and ownership all attach to it. This page covers what separates a data product from a raw data asset, how domains organize products, and the Data Mesh model and ownership roles behind them.
Data product vs. data asset
The difference between a data product and a data asset is accountability and interface, not size or technology. A data product has a consumer it serves, a named owner, and a consumption interface. When the data matters to others, it also has a data contract and a Service Level Agreement (SLA). A raw data asset, such as a single table, file, or dashboard, has none of these on its own.
| Dimension | Data product | Data asset |
|---|---|---|
| Purpose | A stated use case and known consumers | A byproduct of some system |
| Owner | A single accountable owner | Often none, or a shared service account |
| Consumption interface | A typed output port others consume through | Direct table or file access, if any |
| Guarantees | A data contract and SLA when the data matters | No formal guarantees |
| Discoverable | Published for the organization to find | Hidden in a schema or on a drive |
The interface and contract are not paperwork. They let another team find the product, understand its terms, and depend on it — and they let you trace the impact of a change before you make it. A raw asset gives you none of that.
Watch for assets pretending to be products. Common signs: an empty or generic use case, a service account listed as the owner, no output port to consume through, or a single table renamed as a “product.” Each one removes the accountability or interface that makes a data product usable.
Domains organize data products
A domain is a business area that owns a set of related data products, such as Sales, Marketing, or Finance. Each data product belongs to exactly one domain, so there is never a question of which team owns it. Domains can nest into sub-domains that mirror how the organization is structured. Sales might split into EMEA Sales and North America Sales, while each product still sits in exactly one of them.
Domains exist because data ownership has moved out of the center. In traditional data governance, one central team manages all data in a single warehouse and handles standardized reporting. Organizations at scale cannot always work this way: teams need autonomy and speed, so they manage their own data.
Marketing, product, analytics, and engineering each produce and consume their own data products — datasets, APIs, reports, or streaming outputs — shared and reused across the organization. Without structure, ownership, and visibility, this decentralized model turns into chaos. Domains restore that structure by giving every product one accountable home.
A data product can take many forms, depending on your technology stack:
- A Snowflake view that combines sales and customer data.
- A Kafka stream of real-time clickstream data.
- A Power BI dashboard for operational reporting.
- A REST API that exposes reference data to other systems.
- A Google BigQuery dataset for campaign analytics.
- A Python-generated file feed consumed by another team.
The Data Mesh model
The application is built on Data Mesh, an approach that treats data as a product owned by the teams closest to it. Four principles shape how the application works.
| Principle | What it means |
|---|---|
| Domain ownership | Each domain owns its data and answers for it, instead of a central team owning everything. |
| Data as a product | Data is built and maintained as a product, with consumers, a defined interface, and quality rules. |
| Self-serve data platform | Teams share tooling to build and publish products without waiting on a central team for each step. |
| Federated governance | Standards and policies are set centrally but applied by each domain, so products stay interoperable. |
Of these, ownership matters most in practice. A named owner is the biggest predictor of whether a catalog gets used, because people trust and reuse data that someone is accountable for. Without an owner, “data as a product” collapses into yet another shared dataset that no one maintains.
Ownership roles
Ownership of a data product means accountability, not access. A role records who answers for the product’s meaning, quality, and operation. It does not grant anyone the right to read the underlying data.
| Role | Responsibility |
|---|---|
| Owner | The single point of accountability for the product. Required before it reaches production. |
| Steward | Owns the product’s meaning and quality, and approves its data contract. |
| Custodian | Runs the technical side — the pipelines and systems that produce the data. |
| SME | The subject matter expert consulted for domain context; not accountable for delivery. |
| Producer | The producing team or on-call group that owns the pipeline’s output, not its operation. |
Access to the underlying data is governed separately, through the data contract. For what each role is accountable for and when to assign it, see Ownership.
The data product lifecycle
A data product moves through a sequence of workflow states, from first idea to retirement. The current state tells consumers how far they can rely on the product. Only a product in production is safe to build on. For what each state means and the rules for moving between them, see The data product lifecycle.
| Workflow state | Meaning |
|---|---|
| Announcement | The product is proposed, so consumers know it is coming. |
| Draft | The definition is being written — purpose, ports, and owner. |
| Development | The product is being built and connected to its sources. |
| Testing | The product is validated against its data contract and quality rules. |
| Acceptance | Stakeholders review and sign off before release. |
| Production | The product is live and safe for others to depend on. |
| Sunset | The product is being retired; consumers should migrate off it. |
| Retired | The product is no longer available. |
A product cannot enter production without an owner. Until an owner is named, no one is accountable, and consumers have no one to hold to the contract.
Next steps
A data product delivers value only when others can consume it, so its interface comes next. To see how products expose data and consume each other through typed ports, see Data product ports. To create a domain, add the application, and publish your first product, see The Data Product Wizard.
A data product with no output port and no owner is invisible and unaccountable. It stays a private asset, whatever the catalog calls it. For the characteristics that make a product genuinely usable, see What makes a good data product, and for the patterns that undermine them, see Data product anti-patterns.