What is a data product? Definition, examples and ownership

Most organisations have tables that everyone uses and nobody owns. The finance team takes revenue from one table, the sales team takes it from another, and the two figures disagree at the board meeting. When someone asks which figure is correct, no one has the job of answering. The idea of a data product exists to close that gap.

A data product is a dataset that a named person owns, documents and keeps fit for a defined use. It comes with a contract that says what it contains, quality targets that say how good it must be, and documentation that says what each field means. A table that exists, with none of these, is not a data product.

This guide is for heads of data, analytics leads and anyone asked to make reporting and AI dependable. We build data foundations and AI systems for clients, and the same question comes up early in most engagements: which datasets can people rely on, and who answers for them. The guide defines the term and gives plain examples. It explains how data product management works through ownership, contracts and quality targets, and it shows how to start without reorganising your teams.

What a data product is

The term comes from product management. A product has a user, a purpose and someone responsible for it. It is maintained, improved and eventually retired. A data product applies the same discipline to a dataset. It is built for a known set of consumers, it has a stated purpose, and a named owner keeps it working as the business changes.

IBM describes a data product as a reusable, self-contained package that combines data, metadata, semantics and templates to support different business uses. That description is useful because it shows that a data product is more than the rows in a table. The data travels with its description, its meaning and the rules for using it. A consumer can find the product, understand it and use it without asking the person who built it.

What a data product is not

The term is often used loosely, so it helps to separate it from the things it is confused with.

• A dataset is any collection of records. It becomes a data product only when someone owns it, describes it and commits to its quality.
• A dashboard is a view built for people to read. It usually consumes one or more data products rather than being one itself, although the governed reporting model behind a dashboard can be a data product.
• A data warehouse is where data products are built and stored. It is infrastructure, not a product.
• A one-off extract built for a single analysis has no ongoing users and no owner, so it is not a product.

A table that exists is not a product. A table someone answers for is.

Data product examples

Data products are easiest to understand through examples. Each of the following has a defined set of users, a named owner and a stated level of quality.

• A customer table. One cleaned, deduplicated record per customer, used by marketing for campaigns and by finance for revenue forecasting. It often depends on the work described in our guide to master data management.
• Monthly recognised revenue. Revenue by product, region and month, calculated under the finance team's agreed rules and reconciled to the ledger each month.
• An inventory position. Stock on hand by site and item, refreshed every hour, used by planners and by a forecasting model.
• A support ticket history. Tickets with categories, resolution times and product references, used to train a classification model and to report on service levels.
• A risk or fraud score. A score for each transaction, produced by a model and passed to an application through an interface, with stated targets for speed and accuracy.
• A reporting model. A curated set of measures and dimensions behind an executive dashboard, with each measure defined once.

What these examples share is not their format. Some are tables, some are scores and some are models behind a dashboard. What they share is that a person can say what the product is for, who uses it, how fresh it is and what happens when it breaks.

Data products and product data

Product data is a different term. It means information about the goods a business sells: names, descriptions, prices, dimensions and images. A product catalogue can become a data product if someone owns it and keeps it to agreed standards, but the two terms are not interchangeable.

What makes a dataset a product

Four things turn a dataset into a data product. If one is missing, the dataset may still be useful, but nobody can rely on it in the same way.

An owner

The owner is a named person, usually in the business area closest to the data, who is accountable for the product being correct and useful. The owner decides what the product contains, agrees changes with its consumers and makes the decision when quality falls short. The owner does not need to write the pipelines. An engineer or a central data team can build and run them, while the owner answers for what the data means.

A contract

A contract sets out what the product promises: the schema, the meaning of each field, how often it refreshes and the rules for changing it. Consumers build against the contract rather than against whatever the table looks like today. When the producer needs to change something, the contract says how much notice consumers get. Our guide to how data contracts work covers the format and the agreement between producers and consumers in more detail.

Quality targets

Quality targets turn "good data" into checks that pass or fail. A target might say that the customer table has no duplicate identifiers, that revenue reconciles to the ledger within an agreed tolerance, or that the inventory position is never more than an hour old. The checks run automatically on every refresh, and the owner is told when one fails. Without targets, quality is a matter of opinion, and every disagreement turns into a debate about whose spreadsheet is right.

Documentation

Documentation tells a new user what the product is for, where its data comes from, what each field means and who to ask. Field definitions usually live in a data dictionary, and lineage shows which sources and transformations feed the product. Good documentation is short and current. A long document that nobody updates does more harm than a short one that is kept accurate, because people trust it and it is wrong.

Data product management in practice

Data product management is the ongoing work of keeping data products useful after they are first built. It treats each product as something with users and a life cycle, rather than as a delivery that ends at go-live. Most of the work is routine: reviewing quality results, agreeing changes, answering questions and deciding what to build next.

What a data product owner does

• Agrees the purpose of the product and the users it serves.
• Sets and reviews the quality targets with those users.
• Approves changes to the contract and gives consumers notice before any change that would break their work.
• Decides what happens when a target fails: fix the data, pause the refresh or tell consumers.
• Retires the product when it is no longer used, so that old tables do not linger and mislead.

The life cycle of a data product

Most data products follow the same stages. They are proposed for a specific use and designed with their first consumers. They are built and tested against their contract, then published with documentation. Once live, they are monitored against their targets, changed under version control as needs change, and retired when nobody uses them. Each stage has an owner decision attached to it. That is what separates product management from ad hoc maintenance.

How it fits with data governance

Data product management is one practical form of data governance. Governance sets the policies: who may see personal data, how long records are kept and which definitions are official. Data products are where those policies are applied to a specific dataset with a specific owner. That gives governance a unit it can check, rather than a policy that applies to everything and is tested against nothing.

Data products and the semantic layer

In a medallion architecture, data moves through three stages. The bronze layer holds raw data as it arrives from source systems. The silver layer holds data that has been cleaned, standardised and joined. The gold layer holds datasets shaped for a specific business use. Gold-layer datasets are the natural home for data products, because the gold layer is where data is built for a consumer rather than for the next processing step.

A semantic layer sits above the gold layer and holds one governed definition of each business term, such as revenue, active customer or gross margin. When data products and the semantic layer agree, a measure means the same thing in the finance dashboard, the sales forecast and the answer an AI assistant gives. When they do not agree, each tool calculates its own version, and the disagreements return.

Why this matters for AI

AI systems read whatever data they are given and answer with confidence. If a model or an assistant draws on a table with no owner, no contract and no quality targets, it repeats that table's errors at scale, and nobody is responsible for the result. Gold-layer data products with clear owners give AI a source that someone has checked and will keep checking. Our guide to what AI-ready data means sets out how to test this.

AI amplifies whatever it sits on. Give it data that someone owns.

Data products without a data mesh

The term became widely used through data mesh, an approach in which each business domain owns and publishes its own data products. An article on Martin Fowler's site describes data products as the building blocks of a data mesh. The two ideas are connected, but they are not the same thing.

Data mesh is an organisational model. It moves ownership of data from a central team out to the business domains, with shared platform and governance standards. Data products are a way of managing individual datasets. You can run data products with a central data team, with a mesh, or with something in between. Many organisations start with a central team building data products for a few domains, and move ownership out only where a domain has the people and the need.

Getting started without a reorganisation

You do not need new job titles or a restructure to begin. Starting small also tests whether the approach suits your organisation before you commit to more. The following steps work for a first product.

• Pick one dataset that matters and causes arguments. Revenue, customers and stock levels are common choices because several teams already depend on them.
• Name an owner. Choose the person who already answers questions about the data, and agree that the role is part of their job.
• List the consumers. Write down who uses the dataset, for what purpose, and how fresh it needs to be.
• Write the contract and the targets. Keep the first version short: the schema, the field meanings, the refresh schedule and a few quality checks.
• Automate the checks. Run them on every refresh and send failures to the owner.
• Publish the documentation where people already look, and point existing reports at the product.
• Review after a few months. Note the questions and disagreements that no longer happen, then choose the next product.

A first data product that ends a recurring argument about a number pays for the second. It also shows you where the foundation is weak: missing sources, unclear definitions, or a warehouse that cannot support the checks. Those gaps are worth knowing about before you build anything on top. If the source data is not ready, fixing it comes first. The AI readiness assessment is a quick way to see where your data stands.

Where this leaves you

A data product is a dataset with an owner, a contract, quality targets and documentation, kept fit for a defined use. The examples are ordinary: customers, revenue, stock and support tickets. What makes them products is that someone answers for them. Gold-layer data products with clear owners are what make reporting and AI dependable, because every figure has a source that someone has checked.

You can start with one dataset and one owner, without a reorganisation or a data mesh. Choose the dataset that causes the most disagreement, write down what it promises and test it on every refresh. Then use what you learn to decide the next one.

If you want help building data products on a governed foundation, our data consultancy work covers ownership, governance and the data engineering behind them, and the data foundation covers the warehouse, the medallion architecture and the semantic layer they sit on. We scope honestly, and we will tell you plainly if the foundation needs work first. Talk to us to choose your first data product.

Frequently asked questions