What is a Data Product?

Updated October 2026

A data product is a dataset that one team owns and publishes for others to use, with the context needed to trust it. That context includes a clear purpose, documentation, quality promises, access rules, and a stable interface. The idea comes from data mesh. Its test is simple. A consumer can find it, understand it, and rely on it without asking the producer for help.

What is a data product, in plain terms?

A data product is the smallest unit of shared data that someone is accountable for. It is not just the rows. It is the rows plus the information and guarantees that let another team use them safely.

Think of a table called orders_clean in a warehouse. On its own it is a dataset. It becomes a data product when a named team owns it, documents what each column means, and publishes it at a stable address. They also promise how fresh it will be, control who can read it, and announce changes before they ship.

Consumers can be people, dashboards, machine learning models, applications, or AI agents. The product is designed around what those consumers need. That is the shift from a pipeline mindset, where the job ends when data lands, to a product mindset, where the job is that someone can use it.

Where did the idea of a data product come from?

The modern definition comes from Zhamak Dehghani. Her May 2019 article on data mesh argued that domain teams should serve their data as products instead of handing it to a central lake. It listed the qualities a domain dataset needs to count as a product.

Her December 2020 follow up named data as a product as one of four data mesh principles. The others are domain ownership, a self serve data platform, and federated computational governance. That article also described the data product as the architectural quantum, the smallest unit you can deploy on its own.

Structurally, that article gives a data product three parts. There is code for pipelines, APIs, and policy enforcement. There is the data and its metadata. And there is the infrastructure that builds, deploys, and runs it. This framing still holds in 2026, even for teams that never adopted a full data mesh.

What characteristics make something a data product?

A data product meets a small set of usability tests. The six below are the qualities from the original data mesh article. Most teams add an explicit owner and lifecycle on top.

Why is ownership the characteristic that matters most?

Ownership is what makes the other six stick. A catalog entry with no owner goes stale. Quality targets with no owner are never enforced. Every product therefore needs one named team that answers for it and decides how it changes.

What about lifecycle and versioning?

Products change, so consumers need warning. A good product has a lifecycle stage, such as design, live, or deprecated, and a versioning rule for breaking changes. Removing a column or changing a type should come with notice and a migration window, not a surprise in a broken dashboard.

What is inside a data product?

A data product bundles five kinds of things. Some live in the warehouse, some in Git, and some in the catalog.

1. Data. One or more tables, views, files, or streams that hold the actual records.

2. Code. The transformations and tests that build the data, kept under version control.

3. Metadata. Business descriptions, column meanings, lineage, owner, domain, and sensitivity.

4. Interfaces. The ways consumers read it, such as a SQL view, an API, a file export, or a shared listing.

5. Promises and policy. Freshness and quality targets, support contacts, and access rules, often written as a data contract.

The data mesh literature calls interfaces output ports and upstream sources input ports. The terms are useful because they make dependencies explicit. If you know every product's input and output ports, you can trace lineage across the whole company at product level.

Metadata is where meaning lives. If "active customer" means one thing in the product and another in a dashboard, the product has failed even if the pipeline is green. Our guide to what a semantic layer is and how to build one covers how shared metric definitions keep products consistent.

How is a data product different from a dataset, a dashboard, or a data warehouse?

A data product differs from each of these in scope and accountability. A dataset is raw material. A dashboard is one way to view data. A warehouse is where data is stored and queried.

A warehouse can host many data products, and most do. The warehouse is the platform, and each product is a governed unit on top of it. A dashboard is often one consumer of a product rather than the product itself. That split lets the same governed data feed a dashboard, a model, and an agent.

What are some examples of data products?

Good examples have a clear consumer and a clear promise. The examples below are typical patterns, not references to any specific company.

A customer 360 product shows why identity matters. Its main promise is one row per real customer, which depends on matching records across CRM, billing, and support systems. Our explainers on master data management and entity resolution cover that matching step.

A daily revenue product shows why definitions matter. The hard part is not loading invoices. It is agreeing which invoices count, in which currency, and on which date. That agreement belongs in the product's metadata and tests.

How do data contracts, ODPS, and DPROD describe data products?

Several open standards now describe data products and their promises in machine readable form. They differ in scope and format, and many teams combine two of them.

The Open Data Contract Standard is the most common open format for data contracts. Its sections include schema, data quality, service level agreement, support channels, team, roles, and servers. Bitol publishes it next to its Open Data Product Standard, both under Apache 2.0. Its strength is a clear, Git friendly contract. Its limit is that a contract covers one output, not the product's wider context.

The Open Data Product Specification reached version 4.1 on October 24, 2025. It covers metadata, access, quality, SLA, license, pricing, and strategy. That breadth suits internal and external data marketplaces. It is a document format, though, so it does not model relationships between products as a graph.

DPROD is the Data Products Ontology. The OMG specification page lists version 1.0 beta 2, published September 2026. It extends W3C DCAT so products, ports, and policies become linked data you can query. Its strength is lineage and semantics. Its limit is beta status. Our DPROD guide covers its model and adoption steps in depth.

How are data contracts enforced?

Standards describe promises, and tooling enforces them. dbt model contracts stop a model from building if its columns or data types do not match the declared contract. The limit is that contracts check structure, not content, and most platforms only enforce not null constraints. Data tests still have to cover the values.

Do catalogs and warehouses have data product features?

Yes. In Microsoft Purview Unified Catalog, a data product groups assets under a use case with owners and an access policy. Each product belongs to a single governance domain. Snowflake's Internal Marketplace lets teams publish vetted data products as organizational listings with role based access. Both work well inside their platform, but the product definitions do not travel easily to other tools.

Why do data products matter for AI agents?

AI agents need the same things human consumers need, only stricter. An agent must find the right data, know what each field means, and know whether it is allowed to use it. A data product puts those answers in metadata a tool can read.

Without products, an agent picks between five tables called revenue and hopes. With products, it can check the owner, the definition, the freshness promise, and the access policy before it runs a query. That is a large part of making agent answers repeatable. Our piece on data governance for AI agents covers the access side in more detail.

There is also an ownership point. Product definitions, metric logic, and the meaning behind each field are institutional knowledge. When they live only inside one vendor's catalog, a migration can erase years of work. Keeping descriptors in open formats such as ODCS, ODPS, or DPROD, on infrastructure you control, keeps that knowledge yours.

Galaxy works with teams to build this kind of semantic foundation on the stack they already run, using internal tooling it plans to open source. It builds in the open, starting with Filament.

How do you build your first data product?

Start with one product that several teams already depend on. Then make its promises explicit before adding new features.

1. Pick a high demand dataset. Choose one that at least three teams or systems already query.

2. Name an owner. Assign one team that will answer for quality and changes.

3. Write the purpose and definitions. Document what the product is for and what every important field means.

4. Define the output ports. Publish one stable SQL view or API and retire the ad hoc copies.

5. Write a contract. Capture schema, freshness, and quality targets in ODCS or a similar format, and enforce schema in CI.

6. Register it. List it in your catalog with owner, lineage, sensitivity, and access policy.

7. Measure use. Track consumers, incidents, and time to access, then improve the product from that feedback.

Avoid two common traps. The first is renaming every table a data product without adding owners or promises. The second is building a large platform before shipping a single product. One well run product teaches more than a framework document.

For how catalogs, governance, and lineage tools divide this work, see our comparison of data catalogs, data governance, and data lineage.

Frequently asked questions

What is a data product in simple terms?

A data product is a set of data that one team owns and publishes for other people or systems to use. It comes with a clear purpose, documentation, quality promises, access rules, and a stable way to reach it. The difference from a plain table is accountability. Someone answers for it, and consumers know what they can rely on.

What is the difference between a data product and a dataset?

A dataset is just data, such as a table or a file. A data product wraps one or more datasets with an owner, metadata, a stable interface, quality targets, and access policy. You can usually use a data product without asking anyone questions first. A dataset often needs a conversation with whoever built it before you can trust it.

What is the difference between data as a product and a data product?

Data as a product is the principle. It says domain teams should treat the data they share the way a product team treats its users. A data product is the thing that principle produces, a concrete unit with an owner, interfaces, and promises. Zhamak Dehghani described both ideas in her 2019 and 2020 data mesh articles.

What are the main characteristics of a data product?

The common list comes from the original data mesh article. A data product should be discoverable, addressable, trustworthy, self describing, interoperable through shared standards, and secured by a global access control. Most teams add a named owner and a lifecycle. If a dataset is missing several of these, it is a dataset with good intentions rather than a product.

Is a dashboard a data product?

Sometimes. A dashboard counts when it has an owner, a defined purpose, documented metrics, and a promise about freshness that consumers rely on. Many teams treat the curated dataset behind the dashboard as the product and the dashboard as one output. That split is cleaner, because other tools and agents can then reuse the same governed data.

Do I need a data mesh to build data products?

No. Data products came out of data mesh thinking, but a central data team can build and run them too. What matters is that each product has a clear owner, a stable interface, and documented promises. Many companies start with a few products owned centrally and only move ownership to domain teams once the pattern works.

What is a data contract and how does it relate to a data product?

A data contract is a machine readable agreement about a dataset, covering its schema, quality rules, service levels, and support. It is one part of a data product, usually attached to an output. The Open Data Contract Standard from Bitol is the most common open format. Tools such as dbt can enforce the schema part when a model builds.

Which standards describe data products in 2026?

Three open options lead. The Linux Foundation Open Data Product Specification is at version 4.1. Bitol publishes the Open Data Product Standard at version 1.1.0 next to its contract standard. DPROD, an RDF ontology at the Object Management Group, reached 1.0 beta 2 in September 2026. Catalogs such as Microsoft Purview also ship their own product objects.

How do you measure whether a data product is working?

Track who uses it and whether it keeps its promises. Useful signals are the number of consuming teams and systems, freshness and quality checks met, incidents caused by breaking changes, and time for a new consumer to get access. Usage that grows without new support tickets is the clearest sign the product is doing its job.

Why do data products matter for AI?

AI agents need data they can find, understand, and are allowed to use. A data product supplies those answers in metadata an agent can read, such as owner, purpose, schema, sensitivity, and access policy. Without that, an agent has to guess which table holds the right number, which is where wrong and unsafe answers usually start.