Data product

What is a data product?

A data product is a set of data that a team designs, owns, and supports for other people to use, the same way a software team owns an API or an internal service. It can be a table, a view, a semantic model, an API, a stream, or a curated reporting layer. What separates it from a raw extract is the wrapper around the data: a named owner, a defined consumer, a documented interface, quality guarantees, and a lifecycle that includes retiring the thing when nobody needs it any more.

The term comes from the data mesh work of Zhamak Dehghani, who argued that each domain should treat the analytical data it publishes as a product, and treat the people who consume it as customers. The word product is doing real work. It forces you to think about who uses the data, how they find it, what happens when it changes, and who answers the phone when a number looks wrong.

Data that nobody owns and nobody documents is not a product, even when it sits tidily in a warehouse. A product implies a promise, and a promise implies someone accountable for keeping it.

The characteristics Dehghani defined

In her data mesh writing and the O'Reilly book that followed, Dehghani set out a short list of traits that turn a dataset into something other teams can safely reuse. They read best as design requirements, not as marketing adjectives.

• Discoverable. A consumer can find the data product without asking around, usually because it is registered in a data catalog with a description, an owner, and usage information.

• Addressable. It has one stable address that does not move, whether that is a table name, an endpoint, or a stream, so consumers can point at it and keep pointing at it even as the internals change.

• Trustworthy. It publishes where the data came from, when it was last updated, and how good it is, the kind of promise captured in a service level objective. Data lineage and a clear owner are part of earning that trust.

• Self-describing. The schema, the meaning of each field, and an example of how to use it travel with the product, so a new consumer does not have to reverse-engineer what status or revenue actually means.

• Interoperable. It follows shared conventions, common identifiers, agreed formats, and standard field names, so it can be joined to other data products without a custom translation layer for every pair.

• Secure. Access is controlled at the product itself and follows organisation-wide rules, rather than being bolted on afterwards by whoever last copied the data.

Taken together, the six describe the gap between data you can technically query and data another team can rely on without booking a meeting first.

How a data product differs from a plain dataset

A dataset is a collection of rows and columns. A data product is that collection plus the ownership, documentation, guarantees, and support that let other teams build on it. The dataset is the content. The data product is the content plus the promise.

The difference shows up most clearly when something changes. If a column disappears from an ordinary dataset, the consumer usually finds out when their report breaks. With a data product, a change runs through a process: it is announced, its impact on consumers is assessed, and a data contract spells out what may change quietly and what needs notice. The contract is the written form of the promise; the data product is the thing being promised.

Two neighbours are easy to confuse with it. A data catalog is the shop window that helps people find and understand data products, not the product itself. Data governance sets the organisation-wide rules, on naming, privacy, and access, that every data product has to follow. A data product is where those rules meet an actual deliverable that someone consumes. When a product is shared beyond the team that owns it, or outside the organisation, a data sharing agreement records who may use it and on what terms.

A worked example

A company decides to publish "Active customers" as a data product. It carries one row per customer, with customer number, name, segment, country, account manager, revenue over the last twelve months, and last purchase date. Sales uses it for follow-up, finance for revenue analysis, and marketing for segmentation.

What makes it a product rather than a query someone saved:

• A definition that travels with it. A customer counts as active when they placed at least one paid order in the last twelve months. Test orders, cancelled orders, and internal accounts are excluded. That rule is written down, not carried in one analyst's head.

• An owner. Finance owns the revenue definition and signs off on changes to it. When two departments disagree about what revenue means, a named team decides.

• A stated guarantee. The product refreshes every night and is expected to be complete by 07:00. That freshness target is the service level objective consumers plan around.

• A defined consumer. The owner knows that sales, finance, and marketing depend on it, so a breaking change becomes a conversation with named teams instead of a surprise.

Take those four things away and you are left with a nightly export of a customer table. Useful, but nobody promised you anything about it.

Lifecycle, versions, and deprecation

Products have a lifecycle, and so do data products. A good one is versioned, and it is retired on purpose instead of being left to rot. When the shape of a data product has to change in a way that breaks consumers, the owner publishes a new version next to the old one, gives consumers a window to migrate, and only then removes the old version. Announcing that a product is deprecated, with a date, is part of treating consumers as customers.

A logistics team, for example, runs a "Shipment events" product as a stream with a published availability target. When the event format has to change, they release version two, keep version one running for a fixed migration period, and mark version one as deprecated in the catalog so no new consumer builds on it. Nobody wakes up to a feed that changed underneath them.

Platforms increasingly build this in. In Microsoft Fabric, teams group their data into domains, publish items through the OneLake catalog, and use endorsement, promoting or certifying an item, to signal which data products are trusted and ready for reuse. The catalog carries the owner, description, lineage, and refresh time that make a product discoverable and trustworthy in Dehghani's sense.

What to watch out for with data products

Renaming without funding. The most common failure is cosmetic. A team relabels its existing tables as data products, updates a slide, and changes nothing about ownership or support. A data product without a funded owner, someone with the time and the mandate to maintain it, is just a dataset with a nicer name. If no budget line pays for keeping the promise, there is no promise.

Productising everything. Not every table earns the overhead. A one-off extract with a single consumer does not need a contract, a service level objective, and a catalog entry. Reserve the product treatment for data that several teams depend on, or that feeds decisions and customer-facing systems.

Schema without meaning. A tidy schema is not the same as agreement about what the fields mean. If revenue is gross for one consumer and net for another, a clean table still produces reports that contradict each other. This is why consistent definitions, often held in a business glossary, matter as much as the columns do.

No consumer, no product. A data product exists for someone. If you cannot name the consumer, you have built something speculative. Start from a real consumer and a real question, then work back to the data.