Data products did not disappear. The hype around data mesh cooled because changing an organisation is harder than changing a data architecture. But the business problem remains: people and systems still need data they can find, trust, understand, and use for a clear purpose.

The useful question is not whether data products won. It is whether organisations can turn important data into accountable, reusable offers that support decisions, workflows, and AI. The evidence points to a more practical phase. Data product thinking is moving into existing platforms, marketplaces, catalogs, and governance work rather than demanding a full enterprise-wide data-mesh programme.

Data mesh was a demanding operating model

Data mesh linked four ideas: domain ownership, data as a product, self-service data infrastructure, and federated computational governance. That is a large change. It asks business domains to own the meaning, quality, and lifecycle of data used by others, while a central team provides shared services, standards, and controls.

That combination is difficult to fund and operate. The 2024 BARC study surveyed 197 data and analytics professionals. It reported that 20% had data mesh underway and 24% planned it, down from 35% planning it in 2023. Those figures describe the study sample, not an enterprise-wide adoption rate, but they show how hard it is to move from interest to an operating model. BARC's study also makes clear that data products remain a central part of the conversation.

The difficulty does not remove the need for trusted profitability data in finance, approved customer views for commercial teams, or reliable performance data in operations. It means many organisations are addressing those needs without trying to decentralise every part of data management at once.

Data products moved beyond the architecture debate

A data product is not a table, dashboard, API, or model with a new label. Those assets can be part of a product. The product exists when a known consumer can use a governed output for a stated purpose, an accountable owner stands behind it, and the result can be assessed over time.

This is now a practical delivery discipline, not a demand to choose between data mesh and a lakehouse. Gartner listed highly consumable data products among its 2025 data and analytics trends. Its advice is direct: begin with business-critical use cases, build reusable and composable minimum viable products, and agree KPIs between producing and consuming teams. Gartner's 2025 trend guidance supports that use-case-first approach.

The distinction matters. A catalog can describe the estate. A marketplace presents a curated offering for a consumer need. Both are useful, but neither replaces product management: deciding what to invest in, who owns it, what it promises, and when it should change, merge, or retire.

Demand is established; delivery discipline is not

KPMG's 2025 survey of 250 executives found a sharp gap between belief and realised value. Ninety-two percent said well-constructed data products were critical to organisational success, and 96% said they were moving from legacy assets toward modern data products. Yet only 35% reported extensive value from their initiatives. KPMG's survey is not a universal adoption measure, but it is strong evidence that intent is ahead of execution in its respondent group.

That gap usually appears before the technology fails. Teams document assets, build taxonomies, or publish datasets, but leave basic questions unresolved. Which decision or workflow does this product support? Who owns the outcome? What quality, access, and service conditions apply? How will the organisation know the product is being used and creating value?

The better starting point is narrower: which consumer needs which governed data offer to complete an important task? From there, a team can define the output, owner, quality expectations, access model, and measures of use. The work becomes smaller, testable, and easier to improve.

AI makes the missing context visible

AI agents create a new kind of consumer. An experienced analyst may recognise an odd metric, investigate a table, or ask a colleague for context. An agent works quickly and at scale. If meaning, ownership, quality, or permitted use are unclear, it will make weak decisions faster.

An agent needs more than a connection to a warehouse. It needs to know which source is authoritative, what a measure means, who owns the product, how current it is, what quality it meets, and what it is allowed to do. A governed data product can package that context around a defined business purpose.

This is not just a future idea. The 2026 Data Product MCP research paper describes a marketplace where an agent can discover, request, and query data products while contracts enforce access and policy rules. Its qualitative assessment involved 16 data-governance experts, so it is early design evidence rather than proof of broad adoption. The direction is still important: agentic data access needs structured products and enforceable controls.

Platform roadmaps show the same shift. Internal marketplaces and governed product views are now visible across major data platforms. The value is not another catalog screen. It is a way for a consumer to discover a trusted offer, assess its meaning and conditions, and use it through an approved path.

The product layer needs to be portable

Most organisations already have warehouses, lakehouses, pipelines, APIs, catalogs, data-quality tools, and access controls. The harder management problem is connecting those tools to business intent and keeping a product understandable when it moves across platforms.

This is where an open, machine-readable product definition matters. The Open Data Product Specification gives a data product a portable description of its purpose, owner, access, quality, governance, and other operating conditions. It does not replace a catalog, marketplace, or cloud platform. It gives them a shared product definition to work with.

Portability makes a real difference when an organisation operates across several clouds, catalogs, and AI environments. The product should not lose its business definition, contract, or accountability because a team changes tools. It should also not rely on a model's temporary interpretation of a document as its source of truth.

What to do next

Do not start by declaring a data-mesh transformation or turning every asset into a data product. Start with one important decision, workflow, or AI use case. Identify the consumer, the accountable owner, the governed output, and the evidence that will show whether it is useful. Then make the product's meaning, quality, access, and permitted use clear enough for both people and machines.

Data products have not gone away. They have become more concrete. The organisations that make trusted context and accountability visible will be better placed for self-service analytics and responsible AI.