Data products help standardize how raw data sets, data warehouse views, and data lake logical views are combined and used to deliver analytics and AI capabilities. By developing data products, teams can streamline much of the upfront data pipelines, governance, and management needed to deliver trusted data assets that people, tools, and AI can then use for different purposes.
The way you cook a meal can serve as a helpful analogy. You can choose to purchase only raw ingredients like tomatoes, wheat flour, eggs, and fresh herbs to make a favorite pasta dish. The approach works well when you have the time and skills to cook from scratch or want to prepare a nice meal for a small family. Otherwise, you may want to buy canned tomatoes, your favorite box of pasta, and a spice mix to cook the same meal, especially if you are time-constrained, are cooking for many people, or want a consistent finished product.
Like the not-from-scratch pasta meal, data products provide a similar level of time-saving effort, so that analytics and AI capabilities start with consistent, streamlined ingredients. Here are five questions teams should consider as they develop data products and their standards.
Most organizations can’t afford to develop data products as intermediaries for every data visualization, machine learning model, or AI agent. There’s cost and time to develop data products, and once they’re deployed or “on the shelves,” their product managers must oversee their ongoing support and life-cycle management. So when should agile data teams develop data products, and how should they prioritize which ones are more important? One starting point is to consider data products built from a single data set and what it means to productize them.
“A data set should really become a data product when multiple teams start relying on it to make decisions or to power applications,” says Danielle Ben-Gera, vice president of engineering at Crunchbase. “Developing proper governance, clear ownership, versioning, and a managed life cycle for changes becomes important, or you’ll just be shipping fragile pipelines that break downstream work.”
A second consideration is treating the use of ungoverned data sets as a form of data debt. Establishing a data product can be a tactical approach to standardize usage and address risks.
“Organizations should build a data product when data sets are being used across teams without strong governance, well-defined processes, or clear ownership,” says Yaad Oren, managing director at SAP Labs US and global head of research and innovation at SAP. “When anchored in a unified data foundation, data products eliminate silos, create shared understanding, and establish secure, standardized access that enables teams to leverage the same assets with confidence.”
A third consideration is to apply manufacturing principles by building data products for defined customers, driving reuse, and creating efficiencies. Drafting the data product’s vision statement and qualifying its business value is particularly important when a data product requires combining multiple data sources. It raises the question of how standardization delivers efficiencies, improves quality, reduces data security risks, and provides other benefits.
Christopher Zangrilli, vice president of technology strategy at Vertex, says, “Leaders should ask whether the data will reduce cycle time, improve decision accuracy, or mitigate compliance risk as a lens on the business impact. When governance, change management for adoption, quality, and value measurement are embedded from the start, data products transform from experimental tools to strategic assets.”
The products at the grocery store have packaging with a detailed list of ingredients, an expiration date, and a price. Data governance leaders should also standardize how data products are defined, cataloged, and managed.
“Any modern data product should answer four questions clearly: where the data originates, how it transforms across systems, who or what is consuming it, and what governance obligations apply at every step,” says Abhi Sharma, cofounder and CEO at Relyance AI. “Without that end-to-end context, teams are building features on top of data they don’t fully understand.”
Although food products publish their ingredients and label them for dietary restrictions, few document the sourcing of raw ingredients and the logistics of the path from farm to grocer. But when building data products, capturing data lineage may be required in regulated industries and is particularly important when standardizing data sources for AI applications.
“Without lineage, teams operate blind, and governance becomes reactive cleanup,” says Carter Page, executive vice president of research and development at Astronomer. “When teams can see where data originated, how it was transformed, and every system that relies on it, updates become predictable, the right pipelines get tested, the target stakeholders are notified, and breaking changes are documented before they cause incidents.”
Life-cycle management of an API, application, or AI model requires defining a release schedule for delivering improvements, fixes, and other required upgrades. Data product life-cycle management involves several similar disciplines. Ulf Viney, executive vice president of engineering, support, and operations at Precisely, says, “Life-cycle management must include versioning, testing, structured deployment, and stakeholder communication.”
One fundamental difference with data products is that their life-cycle management is closely linked to how their underlying data sets grow or undergo structural changes. Having a data product that works today but isn’t resilient to changes or doesn’t generate alerts when fixes are necessary can break downstream use cases and erode stakeholders’ and users’ trust in the data.
“Managing data as a product means that data consumers can trust the data from the outset, which requires a sustainable and scalable governance framework that ensures data is easy to find, understand, and use,” says Bethany Sehon, senior director of enterprise data at Capital One. “By embedding observability, quality checks, and interoperability from day one, you can manage the full data life cycle from versioning and testing to measuring adoption and performance.”
Teams managing mission-critical, real-time data products that feed multiple downstream analytics and AI use cases should consider the following devops and data governance practices.
Unfortunately, building a data product doesn’t guarantee adoption. Think back to the challenges of getting code reuse, API adoption, or standardizing in-house-developed devops tools. These are all examples of intermediary products aimed at reducing developer toil and improving quality, yet many teams adopted “not-invented-here” postures and do-it-yourself practices rather than learning and adopting standards developed by other teams.
Data products face even greater challenges, especially when they aim to consolidate data silos or eliminate spreadsheets. Product managers overseeing data products must develop a change management program to grow adoption and gather feedback.
“A data product earns its place when it drives a real business decision and can be trusted at scale,” says Quais Taraki, CTO at EnterpriseDB. “Treat data products like software, with versioning, testing, and controlled releases, not one-off pipelines. That discipline securely delivers the right data to the right place and turns data into measurable value through adoption, speed, and risk reduction.”
Product managers can accelerate adoption by communicating how a data product aligns with the business’s AI strategy and culture transformation. For example, show how the data product improves AI literacy, democratizes AI through the right business use cases, or prepares the workforce to use AI agents.
The value delivered by a customer-facing product is often measured through revenue impact, usage metrics, and customer satisfaction (CSat). Internal, employee-facing products can be measured in terms of workflow efficiency, productivity improvement, and employee satisfaction (ESat). Data products are intermediaries, so quantifying their value can be more challenging.
“Too many organizations still treat data products as technical outputs instead of strategic assets,” says Daniel Ziv, global vice president of AI and analytics at Verint. “Their true value becomes clear when assessing how uniquely the data is generated, how much measurable impact it can drive across decisions, and how you can safely extract insight while managing risk. When every organization has access to the same AI models, competitive advantage comes from your unique data and how quickly you turn it into action.”
Sunil Kalra, head of the Databricks center of excellence at LatentView Analytics, adds, “Value should be measured through adoption, usage, and outcomes such as faster insights, reduced manual work, and improved revenue or cost performance.”
A best practice is to use digital transformation velocity metrics such as time to data, time to decision, time to innovation, and time to value. As more organizations seek to deliver business value from AI agents, creating data products will be seen as a path to accelerate delivery, reuse data assets, reduce risks, and manage costs.