Data products: value, necessity and how DAMA helps

The term data products has been drifting through boardrooms and architecture notes for a few years now. Sometimes as fashion, sometimes as a real organising principle. Across client engagements over the past 18 months we see something shifting: organisations that take the concept seriously make genuine progress on data delivery, while organisations that treat it as a sticker get more tangled up. This piece tries to make the distinction concrete, from a consultant’s perspective.

What a data product actually is

A data product is a reusable data delivery with four characteristics: an owner (one person or team, not a committee), a contract (what you deliver, in what form, how often, with what quality guarantee), discoverability (a consumer can find it without knowing somebody), and a lifecycle (versions, deprecation, change management).

That sounds simpler than it is. Most organisations deliver data today in a blend: a few central reports, a few shared tables on a lakehouse, a handful of email exports, and a great many copies in Excel. A data product pulls one of those deliveries out of the shadow and turns it into a product. With the discipline that requires.

Why it is worth the effort

Three reasons we consistently see across engagements.

Scaling demand. Central data teams become a bottleneck as the number of consumers grows. Data products place responsibility where the knowledge sits, in the source domain, while consumers connect through a stable contract. The data engineer at the centre becomes an enabler, not a passthrough.

Demonstrable reliability. A consumer using a data product knows what they are getting: defined semantics, quality metrics, freshness guarantee. The difference between “I think this table is fine” and “this product has an SLA” is precisely what AI use cases need today to be production-ready. Not coincidentally this overlaps with the data requirements the EU AI Act places on high-risk systems.

Pace for new use cases. Once three to five well-maintained data products exist, build time for a new analysis or AI model drops from weeks to days. The gain is not in the first consumer but in the tenth.

What makes it hard in practice

An honest note for anyone starting this:

• Ownership is not an org-chart question. A product without an owner who also holds decision authority dies within a year. Lip-service ownership (“we are all in it together”) does not produce a product.
• A contract is not a JSON schema. A contract describes semantics, quality metrics, refresh frequency, breaking-change policy. A JSON schema is one component, not a substitute.
• The first product is expensive. Expect 6 to 10 weeks for a first product on existing data. It speeds up after that, but no one should hide the learning curve.
• Tooling will not solve it. A data catalogue, a lineage tool and a quality tool are useful but they do not produce a product without the governance discipline beneath them.

How DAMA makes this workable

The DAMA DMBoK framework has no chapter called “data products”, but it does contain every building block you need for them. Five knowledge areas in particular.

Data Governance provides structure for ownership, decision authority and escalation. Who signs off? Who approves a breaking change? Who retires a product?

Data Quality provides the framework for the quality metrics that belong in every product contract. Not a question of “is this good enough” but of “what is good enough given the intended use”.

Metadata Management enables discoverability and traceability. Without a catalogue and lineage a data product does not exist for its potential consumers.

Data Architecture connects individual products to the broader architecture, so each product does not become an island.

Data Modeling and Design safeguards semantic consistency across products that need to interoperate within the same organisation.

Using DAMA as an instrument does not mean “start with a 600-page policy document”. It means: use DMBoK as a checklist to verify the foundations under your data product before rolling it out. See also the broader cimt approach based on DAMA.

Do’s and don’ts

Based on what we see working with clients:

Do

• Start with one concrete data product with a real consumer and a real producer. Preferably with measurable business pain as the driver.
• Write a one-page product contract, not seven. Version 1 may be unfinished; getting the product live matters more than getting it perfect.
• Make ownership explicit and give the owner time and decision authority. Ownership on paper alone does not work.
• Tie the first product to an initiative already in motion: an AI use case, a reporting project, a new application that needs data.
• Treat quality as a parameter, not as a goal: “sufficient for this use” is a better measure than “flawless”.

Don’t

• Don’t start with an organisation-wide data mesh roll-out. Starting at the architecture level almost always delivers delay without a single product reaching production.
• Don’t turn a dashboard into a data product. A dashboard consumes data; it is not itself a data product.
• Don’t expect a data catalogue to solve the problem. A catalogue without ownership is a dead register.
• Don’t adopt the term “data product” without changing anything about process and responsibilities. Otherwise it is rebranding.
• Don’t underestimate the consumer side. Product thinking only works when there are users willing to consume it as a product, with the discipline that requires (no shadow copies, bug reports through the owner’s channel, breaking changes accepted).

Our role in this

At cimt this is rarely a large standalone engagement. It usually emerges as part of a broader data governance request, an analytics project or an AI Readiness assessment. The role we then take is structural: helping decide which first product is worth it, drafting a product contract together with owner and consumer, agreeing quality metrics, and anchoring governance through DAMA knowledge areas rather than standalone policy documents.

What we do not do is deliver a slide deck about data products and then leave. The work lies in the agreements between producer and consumer; that is where lead time goes and where the pattern is learned.

When is a conversation worth it?

If one of these three sounds familiar:

• “We have ten data tables everyone uses, but nobody can explain them to me.”
• “Our AI and analytics teams spend more time finding data than analysing it.”
• “We have a data mesh ambition but no idea how to start without it becoming a reorganisation.”

Then a short conversation is useful. Schedule a call or look at the broader DAMA-based approach. Both cost nothing and yield a first direction in 30 to 45 minutes.