What is a data product?

Definition and examples of data products – and what is merely a component.

A definition (and what it is not)

According to Gartner, data products are defined as follows:

“A Data Product is an integrated and self-contained combination of data, metadata, semantics and templates. It includes access and logic-certified implementation for tackling specific data and analytics (D&A) scenarios and reuse. A Data Product must be consumption-ready (trusted by consumers), up to date (by engineering teams) and approved for use (governed). Data Products enable various D&A use cases, such as data sharing, data monetization, analytics and application integration.”

My simpler take is that a data product is a data deliverable you treat as a product.

That means four things in practice:

1. Customers: named customer groups, not “everyone”
2. Ownership: a team with the mandate to make decisions and bear the consequences
3. A promise: expectations regarding access, refresh, documentation, quality and change
4. Value: verifiable (preferably measurable), tied to actual usage

When these are in place, you get repeatability as a side effect: multiple teams can use the same deliverable over time without each team having to create its own variant.

If you cannot point to who uses it and what you promise when it changes, it is rarely a data product. It is often just an important table.

Examples: what data products look like

In practice, a data product is often a managed deliverable that multiple teams build on, with clear usage, contract and ownership.

Examples that often deserve product status:

• Orders/order lines with standardised event logic: one status model and one time logic for orders, returns and cancellations.
• Metrics layer for financial KPIs: definitions and calculations that multiple reports build on.
• Customer 360 – core: stable customer definition, history and join keys across surfaces.
• Consent and opt-out foundation: managed, audited foundation for contactability.
• Product catalogue for analytics: consistent attributes (category, brand, margin, season) with a clear lifecycle.

And these are usually not data products: staging/intermediate layers (stg_*, “cleaned_v17”), internal helper tables and one-off artefacts without named customers, a promise or governance.

How many data products can we have?

As many as you can actually manage with quality — with customers, a promise and a team that responds.

The number of data products should not be driven by the number of tables, but by the number of product surfaces you have the capacity to keep stable over time.

• Too few –> monolith: one large deliverable nobody dares to change
• Too many –> low signal value: hard to find “the recommended one”

For example, you might decide on three categories of data:

• Data product: managed product surface with a promise
• Component: useful building block without a product promise
• Candidate: could become a data product with increased usage or higher risk

Usage must be visible

For data products, usage must be visible. Choose 1-2 usage signals and start simply:

• consumption in BI/semantic layer
• query/access logs on product surfaces
• number of named consumer environments in the catalogue/README
• upstream/downstream in pipelines

What types of data products exist?

A typology makes it easier to choose the right level of expectations. Here is a suggestion: