Approaching Data Product Thinking

Latest insights from the field

This article collect different insights for Data Product Thinking and reflecting some of my latest experiences in this field. The content:

• Telling the Data Product Story

• The Two Ways of Data Product Thinking

• Data Products – Domain-oriented vs. Process-oriented

• Data Products - From IT to the Domain

---

The idea of Data Product or applying product-princpiples to data or information is not new. A currently discussed and very explaining definition of Data Product can be found at Bitol:

A data product is a reusable, active, and standardized data asset designed to deliver measurable value to its users — whether internal or external — by applying the rigorous principles of product thinking and management. It comprises one or more data artifacts (e.g., datasets, models, pipelines) and is enriched with metadata, including governance policies, data quality rules, data contracts, and, where applicable, a Software Bill of Materials (SBOM) to document its dependencies and components. Ownership of a data product is aligned to a specific domain or use case, ensuring accountability, stewardship, and its continuous evolution throughout its lifecycle. Adhering to the FAIR principles — Findable, Accessible, Interoperable, and Reusable — a data product is designed to be discoverable, scalable, reusable, and aligned with both business and regulatory standards, driving innovation and efficiency in modern data ecosystems. 

Telling the Data Product Story

How do you make the idea of data products and data product thinking understandable for non-technical user groups? This week I tried different approaches for a data literacy training:

• From ocean (raw data) to a bucket of water (curated data) to bottled water (data products) – this idea comes from the data lake idea and James Dixons “If you think of a datamart as a store of bottled water – cleansed and packaged and structured for easy consumption – the data lake is a large body of water in a more natural state.”-thought.

  

  Fig.1: Storytelling for Data Product - From Data Lake to Data Product

• Several times I have seen a box as a symbol where everything can be included and a lot of properties can be described as a data product like the FAIR-Principles (Findable, Accessible, Interoperable, Reusable)

• A cake described by Alation showing that Ingredients (data assets), processed through a preparation process (data pipelines) result into a cake (data product)

Personally I think many ways are possible. Often every common and understandable “products” can be taken to showcase what a product should be and can be related to the data product idea and show principles of data product thinking like ownership, business value and long-term orientation.

What is a form or visualization for data products you have already seen or used?

---

The Two Ways of Data Product Thinking

I heard this more than one time this week - “No one is implementing Data Products the same way”.

On a quick check I would say, there are two main philosophies.

• The Data Mesh-Way – You building data products with a highly automated approach considering the 4 pillars (Domain Ownership, Data-as-a-Product, Selfe-Serving Data Platform, Federated Computational Governance) to great value from data at scale

• The Apply Product Thinking to Data-Way – You change the mindset of your business and IT to handle data in a product way, which can mean many things.

I consider the first as a very sophisticated approach to Data Products, not seen very often this way in practice. While the second gives a lot of freedom to those applying it. But don’t think Product Thinking is easy. This article, one of my customers highlighted, following rather the second way, give us the following concepts to get an idea what is important:

• Product Culture – it determines, how you really live data product through what data means to your company

• Product Strategy – What problems should Data Products solve to achieve business goals and the vision

• Product Teams – Creating cross-functional, empowered and outcome-driven teams and a clear ownership

• Product Discovery – Creating data products which are valuable, usable, feasible and viable – what is not as easy as you would think

• Product Delivery – Find your way to build, test and deploy data products in a reliable, accurate, performant, scalable way.

On which option do you see your approach and if the second, which product concepts do you already apply?

---

Data Products – Domain-oriented vs. Process-oriented

I had several discussions about a rather domain-oriented or process-oriented approach for Data Products. From what I see process-thinking is much easier for organizations and sometimes they are not comfortable with domain-thinking, so they try to fit the data product idea with their process approach.

Should a process owner and the data product owner one persons responsibility. On the one hand the process owner understand the data very well. On the other hand process owners focus on efficiency and quality of operational processes where data is typically just the by-product, what is exactly we don’t want with data products. This can result in conflict of objectives.

In some areas like finance I can see, that analytical data and operational processes can be very near to each other but don’t see, that this is always the case.

Another perspective, rather organizational than personal discussion in this context, is where a data product lives should be a business domain (e. g. Sales, Finance, Procurement, …) or again an end-to-end process. The process would go typically over multiple domains. Here again, analytical data products can be very different to operational processes. But on the other side, strong support of processes and analyzing them to define data products can be an indicator for a process-oriented ownership.

While often there is not the one truth, as always it depends a little bit, e. g. on resources, complexity, focus, business model, organizational structure and former experience with certain concepts. While a process-oriented ownership is very untypical from data products so far, from the discussions I also see that it is very important to understand, what a data product really mean for the organization.

---

Data Products - From IT to the Domain

Two customers started from the IT-side with a business-oriented concept and than going out to the domains. For a concept like Data Products we would hope for other ways like crafting it together with the business, but there are many reasons why this is not possible or happening. Over the last years we had many learnings here like:

• Improve communication through ownership and domain-aligned teams is a early realized benefit, what don't necessarily mean realizing a higher utilization or value of data

• Data Product ownership should be appropriately located - not business leaders, who are responsible for everything anyway, but has no idea about the technology

• Possible separation of functional and technical Data Product ownership can make sense

• Central monolithic data platform team can quickly become a bottleneck again (which you may have wanted to prevent)

• Technical governance is crucial for domain orientation - clear standards regarding data product framework and conventions

• Communities of practice help to establish best practices

• Ensure cross-knowledge exchange in small domain teams to compensate for failures or vacations

Just some learnings from the field. Don't reinvent the wheel and think about what already worked.

---

What do you think about Data Product Thinking? Do you have some experiences here?

This article is a fusion from different insights I share weekly on LinkedIn.