Designing data products

Data products: what the term really covers

Before you can decide which data products to build, it pays to agree on what a data product actually is. In a data mesh, data products are the deployable building blocks that serve analytical data. They should be discoverable, addressable at a permanent URL or URI, self-describing through documentation, and trustworthy enough that consumers can rely on them for their own use cases.

A data product should feel natively accessible to different personas — a canned report for a manager, an SQL connection for an analyst, an API for a backend service. It should compose cleanly with other data products via standard business keys and access patterns. It has to deliver value on its own, as a cohesive information concept within its domain, and it must be secure, with access controls and encryption where needed.

In short, a data product is the smallest valuable unit of analytical data, sourced from operational systems, streams, or other data products, and packaged specifically for meaningful business use. It carries all the machinery needed to achieve that goal automatically. This definition aligns closely with the idea of an architectural quantum in software: a self-contained unit with its own SLOs that can be deployed and evolved independently.

You can package structured, semi-structured, or unstructured analytical data into a data product, as long as you keep a specific user group and its consumption pattern in mind. For example, a data product might serve a weekly customer report to one team and a programmatic API to another.

What data products are not

Good definitions also state what something isn’t. A tighter scope makes data products more useful in practice: it simplifies drafting reusable blueprints and building "paved paths" for data mesh teams. The most common misunderstanding we see is treating data-driven applications as data products. Data products are designed for programmatic access and composability; applications are built for human interaction and are inherently less composable.

Keep in mind that some people conflate other ownership and quality problems with data mesh efforts, hoping the framework will solve all enterprise data issues at once. This habit tends to dilute the language and the focus of a data mesh transformation.

Working backwards from a use case

Working backwards from the end goal is a core principle in software development, and it works just as well when modelling data products. This approach forces you to think first about how end users and systems want to consume the data, and it gives the team a clear objective. It also imposes useful constraints that prevent overdesign and wasted effort.

It sounds like a small shift, but starting from data sources rather than a use case often leads to analysis paralysis. Without a concrete use case in mind, you have no way to judge when your design is complete enough to begin implementation.

Running the design workshop

The process typically takes place in short, focused workshops. Participants should include the people who will actually use the data product, domain experts, and the team who will build and maintain it, with a facilitator and a shared whiteboard. To see how it works in practice, we will use the example of a fashion retailer.

The use case: As a customer relationship manager, I need timely reports showing our most and least valuable customers, so I can take steps to retain the high-value ones and improve the experience of the low-value ones.

Starting from this goal, one data product jumps out — we will call it Customer Lifetime Value (CLV). The CLV data product assigns each registered customer a score representing their value to the business, along with a recommended next best action for the customer relationship manager.

To calculate that score, we need more foundational data products below it:

• A customer profile with basic attributes such as name, age, email.
• A history of purchases, itemised by SKU.
• A record of customer-initiated returns.

Each of these additional data products should itself stand on its own. A quick test: can you write a job description for the data product in one or two plain sentences? If you stumble or need paragraphs, the boundary is likely wrong. These pass the test:

• CLV: Delivers a predicted customer lifetime value as a score, along with a suggested next best action for customer relationship 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: Lists customer-initiated returns.

Only after agreeing on the product-level names do you work further backwards. From Customer-Marketing 360, Historical Purchases, and Returns, you ask: what systems hold the source data that feeds them? That takes you to the relevant transactional system-of-record domains in your architecture, which will expose their own source data products for integration.

Generalising the Data Product Portfolio

To avoid overfitting data products to a single use case, we deliberately test them against other scenarios. Working backwards again from a new business goal—say, generating upsell and cross-sell recommendations—we first try to extend the existing products. In this example, most of the current portfolio can be reused, but we must introduce a new product, “Products.” We additionally expand “Customer-Marketing 360” with gender data, resulting in a new product called “Product Recommendations.”

Regardless of the specific scenario, the goal is to put each product through this test multiple times. In practice, repeating the exercise with up to five different use cases is sufficient. Beyond that, marginal value drops, as by then the essential products in a domain are usually mapped.

Resolving Domain Ownership

Once this portfolio is mapped, we need to settle which Bounded Context or domain owns each item. The decision hinges on which domain runs the contributing source systems, has the greatest operational need, or is best positioned to build and maintain the product. In most cases, a cohesive data product will naturally point toward a clear owner. When contenders exist, pick the domain with the most pressing need and move on.

Never assign a data product to multiple domains. Shared ownership invites confusion and finger-pointing over quality. At the start of the data mesh journey, delay splitting the work. A small, cohesive team should build all the products for a use case first. Use team cognitive load as the trigger to cut over to domain-specific teams. Consistent blueprints make this transition cheaper, allowing new teams to focus on business logic while the platform carries organisation-wide engineering conventions.

Defining Service Level Objectives

SLO decisions must precede architecture. Defined objectives steer whether pipelines are batch or real-time, dictate platform capabilities, and determine solution design. There are a few high-level requirements to consider: freshness, consumption patterns, and required data quality. Consumer-oriented products drive these decisions, and the SLOs for source-oriented products typically follow from them.

Measurable Service Level Indicators derive from the SLOs at implementation time. Platform capabilities measure and publish those outputs to a central dashboard or catalog, making the product’s health visible and trustworthy for consumers. Target SLOs also shape the associated data quality strategy.

Sizing the Product

Keeping data products small matters. A data product should encode a single, cohesive concept. For structured data, that means one denormalized table. For unstructured or semi-structured data, that's a single dataset. Anything larger obscures the purpose and reduces composability and reusability.

Pipeline internals can still hold extra tables or interim datasets; treat these as implementation details, akin to private methods in a class. Only the exposed, well-documented table or dataset counts as the product.

Positioning for Implementation

With logical boundaries, SLOs, and ownership determined, we can move toward building. The foundational design work makes implementation systematic, guided by four principles.

Patterns and Paved Roads

Cohesive, simple products expose common patterns. Analyse input and output shapes, transformation workloads, data quality checks, service levels, and access control. Develop reusable blueprints and enforce them across the slate of defined data products.

The Developer Experience

The platform team should use these patterns to create a spec-driven “paved road.” Declarative specifications, blueprints, and capabilities let developers assemble data products without reinventing governance or infrastructure. This clear separation of responsibilities allows the data product team to focus entirely on business value.

Independent Repositories and Pipelines

Treat each data product as independently deployable. Give it its own source control repository, deployment pipeline, and lifecycle. The repo should contain all structural elements required to operate the product, for example: infrastructure provisioning code, data ingestion and transformation logic, access policies defined as code, and the code used to measure data quality and SLO compliance.

Automated Governance

Because independent teams build and own the products in a mesh, governance cannot rely on manual consistency. The platform implements fitness functions centred on these rules and publishes results to dashboards, making compliance visible. Automation gives teams freedom while keeping them accountable to standards.

Design is the First Step

Operationalising data mesh remains hard. But the “data as a product” pillar offers the highest return on effort; if it fails, the other pillars fail. Working backwards from concrete use cases and designing intentionally from the outset are the tools we’ve used repeatedly to set organisations up for success.