Designing data products

What are data products?

Before we begin designing data products, let’s first establish a shared
understanding of what they are and what they aren’t.

Data products are the building blocks
of a data mesh, they serve analytical data, and must exhibit the
eight characteristics outlined by Zhamak in her book
Data Mesh: Delivering Data-Driven Value
at Scale.

Simply put, it’s a
self-contained, deployable, and valuable way to work with data. The
concept applies the proven mindset and methodologies of software product
development to the data space.

In modern software development, we decompose software systems into
easily composable units, ensuring they are discoverable, maintainable, and
have committed service level objectives (SLOs).
Similarly, a data product
is the smallest valuable unit of analytical data, sourced from data
streams, operational systems, or other external sources and also other
data products, packaged specifically in a way to deliver meaningful
business value. It includes all the necessary machinery to efficiently
achieve its stated goal using automation.

Data products package structured, semi-structured or unstructured
analytical data for effective consumption and data driven decision making,
keeping in mind specific user groups and their consumption pattern for
these analytical data.

What they are not

I believe a good definition not only specifies what something is, but
also clarifies what it isn’t.

Since data products are the foundational building blocks of your
data mesh, a narrower and more specific definition makes them more
valuable to your organization. A well-defined scope simplifies the
creation of reusable blueprints and facilitates the development of
“paved paths” for building and managing data products efficiently.

Conflating data product with too many different concepts not only creates
confusion among teams but also makes it significantly harder to develop
reusable blueprints.

With data products, we apply many
effective software engineering practices to analytical data to address
common ownership and quality issues. These issues, however, aren’t limited
to analytical data—they exist across software engineering. There’s often a
tendency to tackle all ownership and quality problems in the enterprise by
riding on the coattails of data mesh and data products. While the
intentions are good, we’ve found that this approach can undermine broader
data mesh transformation efforts by diluting the language and focus.

One of the most prevalent misunderstandings is conflating data
products with data-driven applications. Data products are natively
designed for programmatic access and composability, whereas
data-driven applications are primarily intended for human interaction
and are not inherently composable.

Here are some common misrepresentations that I’ve observed and the
reasoning behind it :

Working backwards from a use case

Working backwards from the end goal is a core principle of software
development,
and we’ve found it to be highly effective
in modelling data products as well. This approach forces us to focus on
end users and systems, considering how they prefer to consume data
products (through natively accessible output ports). It provides the data
product team with a clear objective to work towards, while also
introducing constraints that prevent over-design and minimise wasted time
and effort.

It may seem like a minor detail, but we can’t stress this enough:
there’s a common tendency to start with the data sources and define data
products. Without the constraints of a tangible use case, you won’t know
when your design is good enough to move forward with implementation, which
often leads to analysis paralysis and lots of wasted effort.

How to do it?

The setup

This process is typically conducted through a series of short workshops. Participants
should include potential users of the data
product, domain experts, and the team responsible for building and
maintaining it. A white-boarding tool and a dedicated facilitator
are essential to ensure a smooth workflow.

The process

Let’s take a common use case we find in fashion retail.

Use case:

As a customer relationship manager, I need timely reports that
provide insights into our most valuable and least valuable customers.
This will help me take action to retain high-value customers and
improve the experience of low-value customers.

To address this use case, let’s define a data product called
“Customer Lifetime Value” (CLV). This product will assign each
registered customer a score that represents their value to the
business, along with recommendations for the next best action that a
customer relationship manager can take based on the predicted
score.

Figure 1: The Customer Relations team
uses the Customer Lifetime Value data product through a weekly
report to guide their engagement strategies with high-value customers.

Working backwards from CLV, we should consider what additional
data products are needed to calculate it. These would include a basic
customer profile (name, age, email, etc.) and their purchase
history.

Figure 2: Additional source data
products are required to calculate Customer Lifetime Values

If you find it difficult to describe a data product in one
or two simple sentences, it’s likely not well-defined

The key question we need to ask, where domain expertise is
crucial, is whether each proposed data product represents a cohesive
information concept. Are they valuable on their own? A useful test is
to define a job description for each data product. If you find it
difficult to do so concisely in one or two simple sentences, or if
the description becomes too long, it’s likely not a well-defined data
product.

Let’s apply this test to above data products

Customer Lifetime Value (CLV) :

Delivers a predicted customer lifetime value as a score along
with a suggested next best action for customer representatives.

Customer-marketing 360 :

Offers a comprehensive view of the
customer from a marketing perspective.

Historical Purchases:

Provides a list of historical purchases
(SKUs) for each customer.

Returns :

List of customer-initiated returns.

By working backwards from the “Customer – Marketing 360”,
“Historical Purchases”, and “Returns” data
products, we should identify the system
of records for this data. This will lead us to the relevant
transactional systems that we need to integrate with in order to
ingest the necessary data.

Figure 3: System of records
or transactional systems that expose source data products

Overlay additional use cases and generalise

Now, let’s explore another use case that can be addressed using the
same data products. We’ll apply the same method of working backwards, but
this time we’ll first attempt to generalise the existing data products
to fit the new use case. If that approach isn’t sufficient, we’ll then
consider developing new data products. This way we’ll ensure that we are
not overfitting our data products just one specific use case and they are
mostly reusable.

To address this use case, let’s create a data product called
“Product Recommendations” which will generate a list of suggested
products for each customer based on their purchase history.

While we can reuse most of the existing data products, we’ll need to
introduce a new data product called “Products” containing details about
all the items we sell. Additionally, we need to expand the
“Customer-Marketing 360” data product to include gender
information.

Figure 4: Overlaying Product
Recommendations use case while generalizing existing
data products

So far, we’ve been incrementally building a portfolio (interaction map) of
data products to address two use cases. We recommend continuing this exercise up
to five use cases; beyond that, the marginal value decreases, as most of the
essential data products within a given domain should be mapped out by then.

Assigning domain ownership

After identifying the data products, the next step is to determine the
Bounded Context or
domains they logically belong to.

This is done by consulting domain experts and discussing each data
product in detail. Key factors include who owns the source systems that
contribute to the data product, which domain has the greatest need for it,
and who is best positioned to build and manage it. In most cases, if the
data product is well defined and cohesive, i.e. “valuable on its own”, the
ownership will be clear. When there are multiple contenders, it’s more
important to assign a single owner and move forward—usually, this should
be the domain with the most pressing need. A key principle is that no
single data product should be owned by multiple domains, as this can
lead to confusion and finger-pointing over quality issues.

Figure 5: Mapping data products to their
respective domains.

The process of identifying the set of domains in
your organization is beyond the scope of this article. For that, I
recommend referring to Eric Evans’ canonical book on Domain-Driven Design and the Event Storming technique.

While it’s important to consider domain ownership early, it’s
often more efficient to have a single team develop all the necessary data
products to realise the use case at the start of your data mesh journey.
Splitting the work among multiple teams too early can increase
coordination overhead, which is best delayed. Our recommendation is to
begin with a small, cohesive team that handles all data products for the
use case. As you progress, use “team cognitive
load” as a guide for when to split into specific domain teams.

Having a consistent blueprints for all data products will make this
transition of ownership easier when the time comes. The new team can
focus solely on the business logic encapsulated within the data
products, while the organization-wide knowledge of how data products are
built and operated is carried forward.

Defining service level objectives (SLOs)

The next step is to define service level objectives (SLOs) for the
identified data products. This process involves asking several key
questions, outlined below. It is crucial to perform this exercise,
particularly for consumer-oriented data products, as the desired SLOs for
source-oriented products can often be inferred from these. The defined
SLOs will guide the architecture, solution design and implementation of
the data product, such as whether to implement a batch or real-time
processing pipeline, and will also shape the initial platform capabilities
needed to support it

Figure 6: Guiding questions to help define
Service level objectives for data products

During implementation, measurable Service Level Indicators (SLIs) are
derived from the defined SLOs, and platform capabilities are utilized to
automatically measure and publish the results to a central dashboard or a
catalog. This approach enhances transparency for data product consumers
and helps build trust. Here are some excellent resources on how to
achieve this:
A step-by-step guide and
Building An “Amazon.com” For Your Data Products.

How big should data products be?

This is a common question during the design phase and will sound
familiar to those with experience in microservices. A data product should
be just large enough to represent a cohesive information concept within
its domain. For structured data, this usually means a single
denormalized table, and for semi-structured or unstructured data, a single
dataset. Anything larger is likely trying to do too much, making it
harder to explain its purpose in a clear, concise sentence and reducing
its composability and reusability.

While additional tables or interim datasets may exist within a data
product’s pipeline, these are implementation details, similar to private
methods in a class. What truly matters is the dataset or table the data
product exposes for broader consumption, where aspects like SLOs, backward
compatibility, and data quality come into play

We’ve designed data products – what next?

So far, we’ve established the logical boundaries of data products,
defined their purpose, set their service level objectives (SLOs) and
identified the domains they’d belong to. This foundation sets us up well
for implementation.

Although a complete implementation approach could warrant its own
article (Implementing Data Products), I’ll highlight some key points to
consider that build directly on the design work we’ve done so far.

Provide a seamless developer experience

Once the common shared patterns are identified, it is the platform’s
responsibility to provide a “paved road” — an easy, compliant and
self-service way to build and operate data products.

Figure 7: Clear separation of responsibilities
between the platform team and the data product team.

In our implementations, this has been achieved through a
specification-driven developer experience. The platform offers
blueprints and capabilities that data product developers can leverage
using declarative specifications, enabling them to assemble data
products based on predefined blueprints and patterns.

This approach allows developers to focus on delivering
business value while the platform abstracts away common engineering
concerns shared across all data products.

Conclusion

Since data mesh came to the fore half a decade ago, we’ve seen many
organisations embrace its vision but struggle to operationalise it effectively.
This series of articles on data products aims to provide practical,
experience-based guidance to help organisations get started. I often
advise my clients that if they need to prioritise one aspect of data
mesh, it should be “data as a product”. Focusing on getting
that right establishes a strong foundation, enabling the other
pillars to follow naturally. Hopefully, the techniques outlined in this
article will help you design better data products and set you
up for success in your data mesh journey.

Let us know how it goes!