Data product thinking has spread unevenly across organisations over the past five years. The conceptual framework — treating internal data sets as products with owners, consumers, SLAs, and lifecycle management — has been broadly adopted in vocabulary. The actual operational practice has been adopted in much fewer places, and the gap between vocabulary adoption and operational reality is one of the consistent themes of data leadership conversations in 2026.

This is a working view of where data product thinking actually lives in mid-2026, what’s making it work in those organisations, and where the practice is mostly performative.

What data product thinking is

Data product thinking emerged from the broader product thinking discipline applied to internal data assets. The core ideas are:

Data sets have owners who are accountable for them. Not just stewards or custodians — actual product owners with decision rights and responsibilities.

Data sets have consumers whose needs the product is designed to meet. The consumer-first orientation is what distinguishes product thinking from supply-driven data engineering.

Data products have SLAs and quality contracts that the owners commit to and the consumers can rely on. Without enforceable contracts, the product abstraction is decorative.

Data products have lifecycles that are managed deliberately. Versioning, deprecation, replacement — these are explicit decisions rather than emergent outcomes.

Data products are discoverable and self-serviceable. The consumer can find them, understand them, and use them without extensive intervention from the producer.

These ideas are not new. The implementation has been the harder part.

Where it actually works

The organisations where data product thinking actually works in 2026 share specific features.

A meaningful internal market for data products. Multiple consumer teams that are willing to pay (in funding, in priority allocation, or in attention) for high-quality data products. Without a market, the producers don’t get the signal about what to build and the consumers don’t have the standing to insist on quality.

Executive sponsorship that lasts beyond the initial enthusiasm. Data product transformations are multi-year endeavours. The organisations that succeed have leadership that stays committed through the early years when the visible benefits are limited and the costs are high.

Investment in the platform that enables data products. Cataloguing, observability, lineage, governance, self-service tooling — these need to actually exist and be usable. Without the platform, the product abstraction is hard to maintain.

Real organisational changes that match the practice. Data product owner roles with the authority to make decisions. Funding mechanisms that flow to producers. Career paths for the people doing the work. Without these structural changes, the practice is just a layer of vocabulary over the previous operating model.

A culture that values craft and ownership over throughput. Data product thinking produces fewer, better data assets rather than more, faster ones. The organisations that reward throughput over craft don’t sustain the practice.

These features tend to be present in organisations where the data product thinking is real, and absent in organisations where it’s performative.

Where it’s mostly performative

The performative version of data product thinking is widespread. The signs are recognisable.

Vocabulary without practice. Teams call their data sets “data products” without changing how they’re produced, owned, or consumed. The terminology has changed; the operating reality hasn’t.

Catalogues without curation. The catalogue exists. The entries are out of date or incomplete. The information consumers need to actually use the products is missing or wrong.

Owners without authority. Someone is named as the “data product owner” but doesn’t have the authority to make the decisions the role implies. Resource allocation, lifecycle decisions, and quality investments are all made elsewhere.

SLAs without enforcement. The data products advertise SLAs that aren’t actually met and aren’t enforced. Consumers either work around the unreliability or escalate when it costs them something significant.

Self-service that isn’t. The platform claims self-service capability that requires extensive intervention to actually use. The “self-service” is reduced to “ticket-driven service that uses self-service vocabulary.”

These patterns are consistent enough across organisations that they’re recognisable in the first conversation about how data product thinking is going.

Why the gap exists

The gap between vocabulary and practice has structural reasons.

Real data product thinking requires changes to organisational structure, funding mechanisms, career incentives, and cultural norms. These changes are hard. Adopting the vocabulary is much easier than making the structural changes that the vocabulary implies.

The benefits of real data product thinking accrue over years. The costs are upfront. Organisations under quarterly pressure tend to invest in the visible aspects (vocabulary, tooling) without committing to the harder structural changes that would deliver the actual benefits.

The producers and consumers of data have different power dynamics in different organisations. The producer-driven culture (where data engineers and architects make the decisions) doesn’t naturally evolve toward consumer-orientation without explicit intervention. The consumer-driven culture has its own pathologies.

The platform investment required is substantial. The build-versus-buy questions for catalogue, observability, lineage, governance, and self-service tooling produce uneven outcomes. The organisations with strong platform engineering can build credible foundations. The organisations without it struggle.

What’s worth doing

For organisations trying to actually implement data product thinking rather than just adopt the vocabulary, several patterns are working.

Start small with one or two genuine data products. Build them properly, with real owners, real SLAs, real consumer engagement, real quality. Demonstrate the difference. Use the demonstration to argue for broader investment.

Focus on the pain points consumers actually have. The data products that justify the work are the ones that solve real problems for real consumers. Building products because the methodology says to, without specific consumer demand, produces shelfware.

Invest in the platform foundations before trying to scale. The catalogue that’s not maintained, the observability that’s not actionable, the self-service that’s not usable — none of these support data product practice. Get them right at small scale before extending.

Hire and develop product-oriented data engineers. The skill set for data product work is different from traditional data engineering. The product mindset, the consumer engagement, the lifecycle thinking — these can be developed but need explicit attention.

Build the organisational structures that the practice requires. Data product owner roles with authority. Funding mechanisms that flow appropriately. Career paths for the work. The structural changes are not optional if the practice is going to be real.

Some organisations have engaged outside specialists for the platform foundations and the methodology development. The pattern that works is using the external partner for capability transfer, not just delivery. Engaging an external consultancy for platform thinking and capability uplift, while building the internal team that will operate the platform, has been the most successful pattern in the implementations I’ve seen.

The AI dimension

The AI conversation has interacted with data product thinking in interesting ways.

AI applications need high-quality, well-governed, reliably-available data. The investments that are needed for AI are largely the investments that data product thinking has been advocating for years. Organisations that have done the data product work are better positioned for AI than organisations that haven’t.

The AI demand has been a forcing function for data product investment in some organisations that had been slow to adopt the practice. The leadership argument “we need this for AI” has unlocked investment that wasn’t supported by the data product argument alone.

The AI tooling itself has started to incorporate data product concepts in some places. AI agents that consume data products with formal contracts, AI evaluation frameworks that depend on well-curated reference data sets — these are starting to make data product practice more concrete.

The effect of this through the rest of 2026 is likely to be continued spreading of data product thinking, partly driven by AI demand. Whether the spreading is to real practice or to more vocabulary adoption depends on the organisational dynamics in each case.

Where this goes

The data product thinking story for 2026-27 is one of continued uneven adoption.

The organisations that are doing it well will continue to extend their lead. The compounding benefits of well-managed data products produce capability that’s hard for organisations without that foundation to match.

The organisations that have adopted vocabulary without practice will face increasing pressure as the gap between their advertised capability and their actual capability becomes more visible.

The middle group will mostly continue muddling along, with periodic attempts at the harder structural changes producing limited progress.

The honest advice for organisations trying to assess their own state is to look at the indicators of real practice rather than the indicators of vocabulary adoption. The catalogue health, the SLA enforcement, the consumer satisfaction, the owner authority — these tell the real story. The vocabulary tells the cover story.

The work continues. The practice spreads, slowly and unevenly. The organisations that take it seriously are doing real work and getting real results. The ones that don’t are mostly accumulating vocabulary debt that will need to be paid down later.