What is a Data Product?
A practical definition for engineers and product managers
The term “data product” has become increasingly common in enterprise discussions, but its meaning is often ambiguous. This post offers a practical definition I've found helpful when implementing data products within large organizations.
Let me be upfront: this is a simplified take. Authors like DJ Patil and Zhamak Dehghani have explored the concept in far greater depth. Their work is essential reading if you're looking for a comprehensive framework. What follows here is the perspective of a data engineer, grounded in practical experience.
First, a data product is data with a customer. Without a clear consumer in mind, you’re not building a product—you’re embarking on an exploratory project. A customer might be internal or external, and they don’t have to be paying or even consciously aware of the product’s existence. But if no one is deriving value from it, then it isn’t a product.
Second, a data product adds value. Raw data is processed, refined, or transformed into something more useful. A backup file, while important, doesn’t count as a data product unless it has been shaped into something consumable and beneficial.
Still, having a consumer and some transformation isn’t enough. Those elements make it a deliverable. What makes it a product is how it's built and delivered.
To explain, let me offer a metaphor.
Recently, our neighbor Jim grilled some excellent burgers at a backyard BBQ. We also occasionally grab a burger from McDonald's. Both are tasty. Both meet a need. But only one is a product—and not because of the ingredients.
The distinction lies in process and delivery. McDonald’s burgers are standardized, repeatable, and delivered under specific guarantees. Let’s explore the traits that make “enriched data delivered to customer” a “product”.
Consistent Quality
A true data product delivers the same value every time. That requires systematic quality controls: automated test cases, CI/CD (Continuous Integration and Continuous Deployment) pipelines, and monitoring that ensures repeatable results regardless of who’s operating the pipeline.
You shouldn’t need to manually guide or debug every downstream use case. If your product requires constant engineering oversight to function correctly, it’s not a product—it’s a support burden.
Just like McDonald’s enforces quality across franchises through standardized cooking and assembly processes, a data product must provide consistency, even when deployed across different teams or systems.
Reliable SLAs
A product implies a contract. That contract—implicit or explicit—must define what the consumer can expect in terms of availability, freshness, latency, and throughput.
Can users access the data in real time? Through an API? What guarantees exist around update frequency or concurrent usage? Without documented and enforced SLAs (Service Level Agreements), your data product is unreliable, regardless of how useful it might be in theory.
Returning to our burger analogy: McDonald’s commits to delivering your Big Mac in minutes, at a predictable temperature and packaging. Your neighbor Bob? He might bring one over eventually. That unpredictability doesn’t cut it for data consumers.
Easy Access and Consumption
A data product must be straightforward to locate, access, and understand. This means reliable interfaces, discoverable documentation, and intuitive schemas.
Whether it’s via API, dashboard, or data catalog, access must be well-defined and dependable. And the data must be structured for its intended use. Consumers shouldn’t have to reverse-engineer meaning from raw tables.
If the only delivery mechanism is a Parquet file tucked away in an obscure S3 bucket with no context, you haven’t shipped a product. You’ve delivered a mystery.
Profitable
A final but critical point: your data product must deliver more value than it costs to maintain.
That doesn’t necessarily mean revenue generation. But the operational cost—engineering time, infrastructure, support overhead—must be justifiable relative to the value it provides.
Too often, data teams build sophisticated products that delight a small set of stakeholders at disproportionate expense. If a weekly dashboard requires heroic effort and expensive compute to serve a consumer who could easily work with a monthly report in Excel, the unit economics don’t work.
Products must be sustainable. Projects can be valuable experiments, but without cost discipline, they fail to scale. Understanding unit economics from the outset helps avoid delivering more than the business can afford.
Summary
A data product isn’t just refined data with a user. It’s a systematized, reliable, accessible, and economically viable offering.
Think of it this way:
A data product is to data what a service is to code.
Anyone can write some code. Building a service requires thinking about reliability, performance, cost, and customer experience.
Same with data. If you want to move from data projects to data products, you need to deliver consistent quality, establish clear SLAs, provide easy access, and ensure sustainable value.
Because Bob’s burgers may be delicious, but they don’t scale.