Data Products: Turning Shared Data Into Reusable Business Assets

Most "data products" are datasets with a new name

"Data product" has become the default vocabulary of enterprise data teams. In April 2025 Thoughtworks moved data product thinking to Adopt on its Technology Radar, its strongest recommendation, and described it as applicable whether an organization runs a data mesh or a lakehouse. Consultancies make the economic case: McKinsey has reported that managing data as products can deliver new use cases up to 90% faster and cut total cost of ownership by up to 30%. Those are consultancy estimates, not audited results, but the direction is widely accepted.

The problem is what happens next. An interview study of data mesh practitioners found organizations relabeling existing centralized stores as "mesh" and every dataset as a "product". The symptoms are easy to recognize: catalog entries tagged as products with no named owner, no published freshness target and no record of who consumes them.

This article argues a simple test. A dataset becomes a data product when a consumer can find it, understand it and depend on it without talking to the team that built it, and will be told before it changes or breaks. Everything else, from the platform to the catalog tool, exists to make that promise cheap to keep.

Our comparison of warehouse, lake, lakehouse and mesh explains why data products outlived the wider data mesh debate. This article is about the practical part: how to define, build and run them.

What a data product contains

Zhamak Dehghani's original data mesh article set out six qualities a domain dataset needs before it can be treated as a product: discoverable, addressable, trustworthy, self-describing, interoperable under global standards, and secure under global access control. Her later article went further and described the data product as an "architectural quantum": the smallest unit that can be deployed independently, bundling code (pipelines, APIs, policy enforcement), data and metadata (including semantics and quality metrics) and the infrastructure to run it.

That definition is useful because it rules things out. A table without its pipeline is not a product. A pipeline whose output nobody has described is not a product. A well-documented dataset that consumers cannot request access to is not a product.

The Open Data Product Standard (ODPS), published by the Bitol project under the Linux Foundation, turns this into a machine-readable description. A product declares its input ports (where data comes from), output ports (what consumers use), management ports, the owning team and support channels. Version 1.1, released in September 2026, adds a type classifier with three values, source-aligned, aggregate and consumer-aligned, which matches the way most enterprises end up layering products in practice.

JPMorgan Chase, in a 2021 article co-authored with AWS, described its data products as broad but cohesive collections of related data from the systems that run the business, each in its own physically separate lake, owned by a team with domain expertise that makes risk-based decisions about permissible use. Consumers query the data in place, find it through an enterprise catalog, and receive column- and record-level access that matches their need. That is the pattern in miniature: ownership, discoverability and access control designed together.

The contract is the product

If a data product is a promise, the data contract is where the promise is written down. A contract states what the product provides (schema and semantics), how good it will be (quality rules), how reliably it will arrive (service levels), who stands behind it (team and support) and under what terms consumers may use it.

The most widely adopted open format is the Open Data Contract Standard (ODCS). It began as the data contract template used inside PayPal, moved to the Bitol project, which joined the Linux Foundation AI & Data foundation in 2023, and has evolved quickly since.

As of 17 September 2026, ODCS is at version 3.2.0 (8 September 2026) and ODPS at 1.1.0. Bitol graduated within LF AI & Data in July 2026, and states that Unity Catalog and Egeria embed ODCS natively. Version 3.2 is notable for AI: it adds a section for context aimed at AI agents (how data may be used, what is verified, what must never be done), vector and map types for embeddings, synonyms, and deprecation flags for retiring fields without breaking consumers.

An ODCS contract is a YAML file with sections for fundamentals, schema, data quality, support channels, pricing, team, roles, service levels and servers. Its service-level section uses named properties such as latency, frequency, retention, availability and error rate, each with a value, unit and the element it applies to.

The format matters less than the discipline. Three practices separate contracts that work from contracts that are filed:

1. Contracts live in version control next to the pipeline code. A pull request that changes the schema also changes the contract, and both are reviewed together.
2. Breaking changes are detected automatically. Removing a field, narrowing a type or changing a meaning fails the build unless the version number changes and consumers have been notified.
3. Quality rules in the contract are the rules that run. If the contract says a column is never null, a scheduled check enforces it and publishes the result. A contract nobody tests is documentation.

Ownership: one name, three jobs

Every data product needs one accountable owner. In practice the role covers three jobs that are often split badly:

Dehghani framed the data product owner's success in consumer terms: data quality, shorter lead time for consumers to use data, and user satisfaction measured like a net promoter score. That is a sharper test than most organizations apply. If you cannot name a product's consumers, you cannot say whether it is succeeding.

Funding follows ownership. Products that are built as one-off projects decay as soon as the project closes. Products funded as a running service, with a small standing capacity for fixes and changes, keep their promises. The governance model that supports this should be lightweight: central standards for contracts, classification and security, local decisions on everything else.

Service levels consumers can see

Thoughtworks' Adopt entry calls for publishing quality and service-level indicators such as freshness, completeness and consistency for each product. The point is not the dashboard. It is that consumers can decide for themselves whether a product is fit for their use.

A practical service-level set for a typical product looks like this. The targets are illustrative; each product sets its own.

Two rules keep this honest. Publish the actual measurement next to the target, including misses. And alert consumers, not only producers, when a target is breached. A product that fails quietly is worse than a dataset nobody trusted in the first place, because people relied on it.

Discoverability and access are one design problem

A catalog entry is only half of discoverability. The other half is what a consumer does next. If finding a product takes minutes but getting access takes six weeks of email, consumers will copy data instead, and the product loses control of its own use.

Design them together:

• Register every product in one catalog with its contract, owner, service-level history and known consumers.
• Make access requestable from the catalog, with approval routed to the product owner and decisions based on classification and purpose.
• Prefer in-place access to copies. Sharing views or governed tables keeps one copy, one set of controls and one audit trail.
• Record consumers as they are granted access. The consumer list is what makes change notification and retirement possible.

In Saudi Arabia, this design is already part of how government entities are measured. SDAIA's National Data Index includes an Operational Excellence component that uses data from national platforms, including the National Data Catalog and the Data Marketplace. One of its metrics is the time taken to process data-sharing agreements. Entities that treat their shareable datasets as products, with contracts, classifications and owners ready in advance, can answer sharing requests faster and with less risk. Our NDMO implementation guide covers the wider standards.

The lifecycle includes retirement

Most data product programs plan how products are born and ignore how they end. The result is the swamp the product approach was meant to prevent. Thoughtworks explicitly includes retirement in data product lifecycle management, and ODCS 3.2 added deprecation flags for exactly this reason.

Each stage has a gate, and the gates are cheap if the evidence is a by-product of doing the work. The most important is the first: no product without a named consumer and a use. The second most important is the last: a product with no consumers for two review cycles is deprecated, its consumers notified through the contract, and its storage released.

A readiness scorecard

Use this grid to assess an existing "product" in an hour. Score each line as met only when the evidence exists.

Products that meet six or more criteria are products. Products that meet fewer than four are datasets, and should be labeled honestly until they improve.

What to do in the next 90 days

1. Run the scorecard on your ten most-used datasets. Label each honestly as a product or a dataset.
2. Pick three candidate products with named consumers and a business owner willing to be accountable.
3. Adopt one contract format, ODCS or a documented internal equivalent, and store contracts with the pipeline code.
4. Automate breaking-change detection in the deployment pipeline for those three products.
5. Publish freshness and completeness for each product next to its catalog entry, including misses.
6. Connect access requests to the catalog so owners approve use and the consumer list builds itself.
7. Set a retirement rule for products with no consumers, and apply it once.

Frequently asked questions

What is a data product?

A data product is a dataset, or a set of related data, packaged for reuse with a named owner, a contract describing its schema, meaning, quality and service levels, discoverable access, and a managed lifecycle. Consumers can use it without asking the producing team how it works.

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

The data product is the thing consumers use: data, code, metadata and infrastructure. The data contract is the written agreement about it: schema, quality rules, service levels, support and terms of use. A product usually has one contract per output port.

Do we need a data mesh to have data products?

No. Thoughtworks recommends data product thinking whether you run a data mesh or a lakehouse. Many enterprises run data products on a central platform, with ownership in a small number of business domains.

What is the Open Data Contract Standard?

ODCS is an open, YAML-based standard for data contracts maintained by the Bitol project at the Linux Foundation AI & Data foundation. It originated as PayPal's data contract template. Version 3.2.0 was released in September 2026.

Sources and further reading

• Technology Radar: Data product thinking, Thoughtworks, April 2025.
• How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh, Zhamak Dehghani, 20 May 2019; Data Mesh Principles and Logical Architecture, 3 December 2020.
• Open Data Contract Standard releases and service-level agreement specification, Bitol.
• Announcing ODPS v1.0.0, Bitol, 24 September 2025; ODCS v3.2.0 and ODPS v1.1.0 released, Entropy Data (vendor news), 8 September 2026.
• Bitol graduates, Bitol, July 2026; Bitol joins LF AI & Data, LF AI & Data, 30 November 2023.
• How JPMorgan Chase built a data mesh architecture, AWS Big Data Blog, co-authored with JPMorgan Chase, 2021.
• How to unlock the full value of data? Manage it like a product, McKinsey & Company, 2022.
• Towards Avoiding the Data Mess, Bode et al., 2023.
• National Data Index, Version 1.1, SDAIA, November 2024.