The Data Product Playbook From Data Assets to Real Business Impact with Willem Koenders

What is the Need for Data Products?

Organisations currently possess a critical two- to three-year window to achieve minimal maturity in their data foundations to capitalise on artificial intelligence and agentic capabilities. It is imperative that data functions effectively; otherwise, strategic AI readiness cannot be attained.

Implementing data products offers a highly effective methodology for accelerating this foundational maturity by identifying and leveraging the most impactful data for key use cases. Establishing an asset as a data product necessitates adherence to specific certification criteria, which often include formal data contracts governing data sourcing, constraints, and operational utilisation.

Figure 1 What are we going to talk about?

Why Define Data Products, and What is the Kitchen Analogy?

Fundamentally, a data product aggregates information from one or multiple sources and delivers it to targeted consumers. However, classifying an asset as a true data product requires explicit management. This concept is elucidated through a culinary analogy: chefs require prepared, high-quality ingredients rather than unrefined produce to efficiently create exceptional dishes.

Similarly, data products must exhibit nine core properties to ensure optimal consumer enablement. These properties dictate that the data must be valuable, discoverable, addressable, understandable, interoperable, and trusted in terms of its quality. Furthermore, the data must be rigorously secured and strictly managed as a product with a designated pipeline and owner.

Figure 2 What is a Data Product?

Figure 3 The 9 Defining Properties of Data Products

What are the Types of Data Products (Source vs. Use-Oriented)?

Data products are systematically categorised into source-oriented and use-oriented typologies. Source-oriented data products remain closely aligned with foundational operational platforms and include stable reference data, master data configurations such as Customer 360 views, and transactional data that encompasses repetitive organisational events. Conversely, use-oriented data products integrate source assets and transform them for highly specific business applications.

This category incorporates analytical data products, which facilitate insights such as sales dashboards, and model-driven data products, which integrate artificial intelligence algorithms. For instance, a churn calculation model operates within a data product framework, processing master and transactional data to generate a new predictive attribute. Experience-oriented dashboards may also be classified under this taxonomy.

Figure 4 Types of Data Products

What is the Data Product Lifecycle?

The creation and maintenance of a data product requires implementing a comprehensive lifecycle framework. This process commences with a planning phase dedicated to ideation, business casing, funding, and crucial consultations with privacy teams. Subsequently, the design and build phases involve ingesting, integrating, and enriching data, as well as establishing essential metadata and the structural architecture.

Post-development, the product enters the deployment and usage phases, where it must be published in a catalogue to facilitate discoverability, access control, and value tracking. Finally, the lifecycle mandates continuous maintenance to ensure operational integrity and requires a formal demise phase. Retiring unused data products is critical for rationalising infrastructure and achieving genuine cost efficiency.

Figure 5 Data Product Lifecycle

How to Build the Business Case, and Why Quantify Value?

A data product holds no intrinsic value independent of the business processes it supports. Consequently, robust business cases are paramount, demanding the quantification of benefits through explicit operational use cases. This valuation generally falls into four categories: revenue generation, cost reduction, experiential improvements, or risk mitigation. As a practical example, consider a financial reconciliation engine that merges transactional records from enterprise resource planning systems and financial ledgers.

By establishing a trusted, unified dataset, organisations can automate manual month-end processes, yielding substantial operational cost savings. Additionally, it prevents revenue leakage associated with uncollected cash applications. Constructing these explicit financial models over multi-year horizons is essential for justifying the total cost of ownership associated with product development.

Figure 6 Data Product Business Case Framework

Figure 7 Business Case Example: Finance Reconciliation Engine

What are Architectural Blueprints and Tech-Agnostic Design?

Scaling data product initiatives requires a standardised, technology-agnostic architectural blueprint to ensure consistent organisational implementation. A foundational pipeline dictates that internal and external data are ingested in raw form, then curated for quality and integrity, and potentially augmented with calculated features before consumption. This structural flow is underpinned by critical data management practices, orchestrational compute capabilities, and data science integrations.

While the conceptual blueprint provides a universal framework, it can be mapped precisely to specific vendor technologies to standardise enterprise architecture. Furthermore, artificial intelligence assistants are increasingly instrumental in automating the generation of metadata, quality rules, and orchestration workflows within this pipeline.

Figure 8 Data Product Blueprint

Figure 9 Data Product Blueprint (example)

What are Architectural Guidelines and Design Principles?

To guarantee structural integrity, data product development must adhere to stringent architectural guidelines across five primary domains. First, products require precise specifications to ensure they remain atomic, canonical, and firmly bounded. Second, automation should be maximised by defining the architecture as code. Third, robust metadata management and observability are essential for monitoring data lineage, freshness, and anomalies.

Fourth, rigorous protocols must govern data quality and integrity, necessitating active validation for consistency and completeness. Finally, access and sharing protocols must be strictly enforced through API-first methodologies, least-privilege security models, and explicit data contracts that govern cross-organisational distribution.

Figure 10 5 Categories of Architectural Guidelines

What is the People Side: Core and Supporting Team Roles?

The successful operationalisation of data products is fundamentally dependent on personnel and change management frameworks. The structural team model positions the Data Product Owner at the core, serving as the primary authority accountable for the product’s pipeline, costs, and value delivery. This central role is directly supported by data engineers, domain stewards, and solution architects.

Beyond the core team, a supporting tier involves enterprise architects and data governance specialists who enforce overarching metadata protocols and standardisation. Furthermore, executive advocacy from an outer ring of sponsors—such as the Chief Data Officer and Chief Privacy Officer—is critical for embedding regulatory compliance and confirming strategic alignment.

Figure 11 Data Product Teams

Why to develop Portfolios, Maturity Assessments, and Drive Organisational Change?

To elevate the strategic narrative beyond technical expenditure, data leaders must manage products akin to a real estate portfolio. By tracking certified data products against quantified operational use cases, organisations can empirically demonstrate substantial revenue generation and risk mitigation. Portfolio maintenance is facilitated by continuous maturity assessments, which evaluate products across dimensions such as awareness, understandability, interoperability, and trust.

This granular measurement allows leadership to detect systemic deficiencies and deploy targeted governance interventions. Ultimately, driving widespread organisational adoption requires proven change management frameworks, an acute sense of urgency around foundational data readiness, and rapid, high-impact operational victories.

Figure 12 Data Products Dashboard

Figure 13 Maturity Assessment: Inventory & Stock Movement

Figure 14 Maturity Assessment: Sales Orders & Returns

Figure 15 Driving Lasting Organisation AI Change