Data product thinking is gaining momentum in the data world right now so we recently organised a live online learning session for Conveyor Data, where we had Pascal Knapen, CTO of Dataminded and Conveyor Data, interview Kristof Martens, senior data consultant and Product Lead of the Data Product Portal, to explore the concept and discuss what it means in practice.

They discussed how this approach can change the way organizations handle data, helping us move from constant firefighting to strategic data management.

I was especially curious to learn if this was just another catch-all phrase for whatever problems we have in data at any given moment in time, or if it’s a specific approach that, like all things specific, only works in certain specific cases.

Read on to learn what I learned.

What is Data Product Thinking?

As Kristof explained:

“You can consider it the art of treating data as a product where producers of data focus primarily on who will be using your data. This means that one has to focus on the usability, quality and constant improvement of the data assets you produce for others.”

It’s useful to make the analogy to prescriptive medicines, which are far more than just chemical compounds:

• They require a prescription from a doctor

• Include medication guides explaining usage

• Undergo rigorous quality control

• Contain detailed production information

• Have clear expiration dates and ingredient lists

• Explain potential side effects

Similarly, data products should come with comprehensive metadata, quality assurances, and clear usage guidelines.

The Common Data Quality Challenge

Organizations frequently struggle with an undefined concept of “data quality,” which manifests in various ways:

• Changing data layouts

• Missing data descriptions

• Difficulty finding or accessing data

• Freshness issues

• Empty or inconsistent fields

• Referential integrity problems

The traditional organizational setup often exacerbates these issues:

“The usual way of doing things we see very often in organisations, is that you have application teams building stuff in their own domain silo, storing data in their own operational databases only focussing on the scope of what they are building. Next to that you usually have central data teams without domain knowledge that extract data from these operational databases on a random schedule and make it available in a data warehouse or data lake for consumption by others.”This setup creates a disconnect where application teams don’t care about downstream users, while central data teams without domain knowledge are constantly firefighting between data consumers and producers.

Why Traditional Solutions Fall Short

Organizations have tried various approaches to address data quality issues:

• Installing data catalogs and “forcing people to use them”

• Building cleaning pipelines

• Implementing data quality tests and tooling

• Using tools like DBT to extract lineage

• Increasing ingestion schedules

• Setting up automatic reruns of failed pipelines

However, these solutions typically address symptoms rather than root causes. As Kristof noted:

“In the end the perceived quality of data does not really increase, because there’s always something new that pops up.”

The fundamental issue is that people are made responsible for something they have no control over.

The Data Product Thinking Approach

Data Product Thinking addresses these challenges by placing responsibilities where they belong, as Kristof likes to highlight, and enabliong a shared responsibility model:

Data Product Teams

• Take responsibility for all aspects of their data products

• Focus on the data consumer’s needs

• Negotiate with data consumers about expectations

• Embrace product thinking (outcomes and user experience) rather than project thinking (timeline and budget)

Data Platform Teams

• Provide capabilities and paved roads for data product teams

• Enable re-use of tooling across different data product teams

• Organize processes for data product creation

• Help data product teams access data

• Leverage automation to speed up creation and scaling

This approach is all about changing how organizations structure collaboration between domain-oriented data teams and central IT departments. It enbales shared responsibiliyt and is ultimately a process-driven effort.

Is Data Product Thinking Right for Your Organization?

Yes! Data product thinking is particularly valuable for:

• Larger organizations with multiple data initiatives running in parallel

• Organizations where data is shared across different departments or domains

• Companies looking to scale their data operations efficiently

No! It may be less critical for:

• Smaller organizations with only a few data products

• Organizations not planning to scale data operations

• Highly segregated organizations with little need for data exchange between domains

Implementation Roadmap

To implement Data Product Thinking, follow these steps:

1. Change management: Explain to the organization how they could work differently with data

2. Define roles and responsibilities: Clarify interactions between domain teams and platform teams

3. Identify valuable first use cases: Support teams in building these in a self-service manner

4. Build a “Minimum Viable Platform” (Kristof’s term): Based on core technologies chosen by the organization

As new data products are built, common capabilities will emerge. The data platform team should work with use case teams to provide paved roads for efficient implementation, avoiding the need for teams to “reinvent the wheel” for common tasks like:

Sharing data across the organization

• Ingesting data from databases

• Building scheduled data pipelines

• Building and sharing dashboards

• Training machine learning models

Overcoming Implementation Challenges

The primary challenges in implementing Data Product Thinking are organizational, Kristof says (and I and many others agree), not technical:

“Many organisations are currently in a model where they outsource all their IT and data troubles to a central IT team and if something goes wrong, they just point to them to fix it for them. Getting the business teams to take responsibility and ownership themselves for the data products they are producing and properly staffing them and paying the bills is where we usually get the most friction.”

Business teams often want fast initiatives but can’t execute due to bottlenecks in central IT. Data Product Thinking empowers business teams to set their own priorities and take control of their data initiatives.

How Tools Like Data Product Portal Help

The Data Product Portal helps companies manage the processes and interactions between stakeholders that come with Data Product Thinking. Meanwhile, Conveyor helps data platform teams provide paved roads for use case teams to build data products efficiently.

These tools support the organizational changes needed to implement Data Product Thinking successfully.

Key Takeaways

Data Product Thinking is about putting responsibilities where they belong, not about technology.

1. Treat data as a product placing the focus on the product’s consumers

2. Empower data product teams to take responsibility for all aspects of building data products

3. Enable data platform teams to provide capabilities and paved roads for data product teams

4. Focus on organizational change rather than technical solutions to address data quality issues

Final Thoughts

Data Product Thinking represents an important shift in how organizations approach data management. By treating data as a product and placing responsibilities with those who have the knowledge and control to fulfill them, organizations can break the cycle of constant firefighting and move toward strategic, scalable data operations that truly deliver value.

—

At Conveyor Data, we are building the fully open source Data Product Portal to give teams an easy framework to start with data product thinking.

Get involved as an independent contributor to the open source repo or reach out to us if your organisation is interested in joining our free design parter program.