Introduction

Since Dehghani (2019) articulated the principles of Data Mesh four years ago, the framework has been heralded as a new paradigm that overcomes many of the challenges data teams and organizations face. The cornerstone – Treating Data as a Product, more commonly referred to as "Data Products" – has received widespread attention (see What Exactly is a Data Product? by Sanjeev Mohan 2023).

However, confusion and even misconceptions surround the concept, as we discuss in 12 Misconceptions about Data Products… and Counting. In this post, we highlight and correct three of the most significant misconceptions that derail Data Products.

The #1 Misconception – Beware the False Equivalence 

For many years, data teams have been sourcing data, building data pipelines, and producing datasets, tables, and other data assets to support a wide range of users. More recently, data teams have begun to contract with users, internal and external, stipulating and agreeing on quality, latency and other specifications for the data assets they produce. These practices are required for Data Products as well as data assets, so it’s natural for data professionals to ask “is a Data Product simply a data asset we’re already producing, with just a different name?” Data users may also wonder why so much attention is being given to Data Products and what’s in it for them.

This apparent overlap and confusion lead us to the first and most dangerous misconception.

If in fact, data assets aren’t synonymous with Data Products, then what distinguishes a Data Product? This definition clarifies the distinction. 

A Data Product is a data asset that’s purposefully designed and produced to enable specific users to make decisions and take actions that achieve explicit goals beneficial to customers, users or other stakeholders. Much like products in general, the “specs” for data products are also made explicit and codified in data contracts.

Data Products transform how data teams operate, bringing their work and the products they produce into close alignment with their customers and the goals they’re responsible for achieving, making it clear how data teams create value.

For more insights about Data Products, watch for upcoming posts on Data Products and our forthcoming whitepaper on Value Driven Data Teams.

The #2 Misconception – “Whataboutary” Confuses the Issue

Discoverability and Observability (D&O) are two key elements of a robust data ecosystem. Users, of course, must be able to find and establish the quality of both data assets as well as Data Products. In this respect, Data Products are much like any other product that customers might consider, choose to purchase and consume. Likewise, the ability to uncover problems with data and, even more importantly, determine and correct the root cause, are also critical. And yet simply bolting D&O onto data or a data pipeline doesn’t magically yield a Data Product. 

As we note in Misconceptions about Data Products:

Just to reiterate, discoverability – or more generally, findability – is a critical requirement, especially in large enterprises. Moreover, it becomes even more important as more and more Data Products are produced and consumed by business and “citizen” analysts and, ideally, shared with other users. Similarly, metadata – especially active metadata, which includes usage and other metrics – is equally important. Finally, observability, as a part of a larger system for monitoring, detecting and correcting issues as they arise is critical. And yet, none of these, alone or in combination, magically transforms a data asset into a Data Product.

The #3 Misconception – Business as Usual

In many organizations, data pipelines are owned, built and maintained by data engineers who reside within a centralized IT organization. In many instances, centralized data teams have limited, if any, visibility into how or perhaps even whether data assets they produce are used, much less if they create value and delight users. In organizations with traditional data cultures, CDOs tend to focus on “defense,” prioritizing protection of the organization’s data assets. In all organizations, but especially these, embracing Data Products will require a significant change in the orientation, roles and responsibilities of data teams and their leaders. 

Whether data teams are centralized or embedded, equipping data professional to produce data products represents a key JTBD (Job to Be Done) for Data Leaders, especially CDOs. As I discuss in Value-driven Data Teams, skills in collaboration, UX (user experience) and Design Thinking are needed to uncover and prioritize users’ needs and design data products that support those needs. These skills are often lacking in data teams though they may be present in other parts of the organization. To support adoption and guide implementation, CDOs must also embrace their role as business partner, facilitator and champion, focusing on growth, customer retention and other key outcomes.  

It’s also important to assess users’ readiness to embrace and fully utilize Data Products. While training can be helpful, some organizations, recognizing the gaps in knowledge and skills as well as the importance of the job, are hiring dedicated Data Product managers (Davenport et al, 2022). Others, like LinkedIn (Leung 2022), are developing their own playbooks to guide data teams and users as they develop Data Products. 

For additional discussion of the above as well as other Misconceptions, download a copy of 12 Misconceptions about Data Products… and Counting.

‍