Data Products: why are they redefining data strategy?

I have lost count of how many times I’ve heard executives say that “data is the new oil.” The analogy became famous, but it overlooked the most important part: crude oil, without refinement, is useless. 

With data, the logic is exactly the same. And this is where most organizations stumble.

What changed with the Data Product logic applied to data

The idea of a Data Product is not new, but it gained traction when companies began to realize that the centralized data model, with an engineering team serving the entire company, does not scale. And it does not scale because the demand for data grows at a speed that no center of excellence can keep up with alone.

Data Mesh, the architectural model that popularized the concept of Data Product, proposes an inversion: business domains become owners of their own data and are responsible for providing it with quality, documentation, and clear contracts for those who need to consume it. The “sales” team knows more about sales data than any platform engineer. It makes sense that this team is also responsible for the data product that exposes this information.

This changes a company’s data strategy because it places accountability where business knowledge exists. It is no longer an infrastructure problem. It becomes a product, process, and culture problem.

The strategic turnaround is in treating data as something that has ownership, measurable quality, SLAs, users, and purpose. 

Why data initiatives fail, and what Data Product has to do with it?

There is a pattern of failure that repeats itself regularly. The project begins with enthusiasm, receives funding, creates a specialized team, and sets ambitious goals. In the first six months, there is visible progress. A year later, the project is technically alive, but operationally irrelevant. The business areas have returned to using spreadsheets.

The problem almost always is that no one felt ownership of the data. Engineering built the pipeline. The BI team set up the dashboard. The business received the report. But when the number was wrong, outdated, or simply didn’t make sense for those who needed to make a decision, the conversation about accountability became circular. Engineering blamed the source data. The business blamed engineering. BI was caught in the middle.

Data Product resolves this issue. By defining that a dataset is a product, with a product owner, published quality criteria, and a managed evolution process, the organization ceases to live with ambiguous accountability. The data has an owner. The owner is responsible for quality. Consumers have a place to complain and know what to expect.

Another factor that undermines data initiatives is the distance between those who produce the data and those who make decisions with it. In a well-structured Data Product model, business domains build the data products they consume. This shortens the feedback cycle. A financial analyst who is also responsible for the revenue data product will notice inconsistencies sooner, will correct them with more context, and will evolve the product according to the real needs of the business, not with what engineering imagined the business would need.

What does a company need for Data Product to work for real?

Here I will be more direct, because this is where I see well-intentioned projects sink the most.

Culture first, technology later

There is no platform, tool, or framework that solves a cultural problem. If business teams do not feel responsible for the data they produce, if leadership does not demand data quality with the same vigor as they demand product delivery quality, the model will fail. Data Product requires teams that have never thought about data to start thinking.

Governance that enables, not controls

There is a common trap here. When the conversation about data governance begins, there is a natural tendency to create committees, approval processes, and layers of control that end up stifling operations. Good governance in Data Product works like an API: it defines the contract, guarantees what is being promised, but does not interfere in the implementation details of each domain.

Technology that serves the model

This point deserves special attention. Technology needs to be at the service of the model. This means a data platform with self-service capability, data catalogs that business teams can use without needing constant support, and quality observability integrated into the product lifecycle. 

Get in touch with our experts and find out how we can help you. 

Frequently Asked Questions on the topic