Data Products as a Lever to Quantify Data Value

Being able to quantify the value of data is essential for any data leader. Where in the past this might have been something extra, it is rapidly becoming a hard requirement for a couple of key reasons:

1. Create urgency for a Data Office and to tell a convincing story to executive and business leadership on the critical need for data capabilities and foundations.
2. Drive prioritization and ensure that investments are made where the expected ROI is the highest, with explicitly articulated impact on business use cases.
3. Drive continued improvement by tracking the implementation and operation of data assets to ensure that value is continuously created and to identify where enhancements are needed.
4. Ensure impact as the average tenure of data leaders is less than 2.5 years, making it critical to focus on value creation, ensure business outcomes, and extend the careers of data leaders.

Data Products

A Data Product is a governed data asset that is curated and prepared for specific use cases. Depending on the needs of consumers, it is enriched with AI and analytics-driven data features. It also typically has many and/or highly important consumers.

The nature of Data Products makes them ideal focus points for value creation. They are specifically created and maintained to enable business use cases, which by definition drives value. There is no limitation on these use cases — they can appear in any functional area and can drive value in a variety of ways:

Additionally, Data Products help to streamline data governance and lower the associated implementation costs. Finally, as use cases are starting to use a smaller set of strategic distribution points (the Data Products), legacy systems and application can be demised, and data can be deduplicated.

But that Data Products drive value is perhaps not really questioned — but what is questioned, is exactly how much?

Data Product properties that enable measurement of value

There happen to be a few properties that distinguish Data Products from “mere” Data Assets, and it is these exact properties that enable the quantification of value. Let’s take a look at a few of them.

• Actionability: Data Products must be directly applicable (hence without a lot of additional interpretation and transformation) for well-understood use cases with precise input needs.
• Business Impact: Closely related to the previous property of actionability, Data Products must have demonstrable impact through specified use cases. It’s part of the definition of a Data Product that it is designed with use cases in mind, which should enable you to provide precise impact statements.
• Interoperability: Interoperability standards ensure that consumers can readily discover, access, ingest, and use the Data Product. But when properly defined, for example through a rationalized of tools and technologies (or even better, with an API-first design principle), it also enables precise monitoring of the frequency and intensity of usage.
• Addressability: A Data Product should have a unique address that help consumers access it in line with the interoperability standards outlined above. It should therefore be associated with a clearly and uniquely identified object and system, which in turn should have easily identified storage, processing, and maintenance costs — all critical cost inputs into the value equation for the respective Data Product.
• Product Orientation: As implied by the term Data Product, its lifecycle should be managed with a focus on customers and their needs. Just like any other product, its profitability should be evaluated, both during design and following its launch. This is not an afterthought — this should be ingrained in how the asset is managed, and should start with a business case at its genesis. Later on, it should be a matter of updating the business case based on the observed results, not of creating one from scratch.

Next Step: Assessing your Data Products

If you are struggling to quantify the value of a given (prospective) Data Product, the above-listed properties are a good starting point. If all of the properties are true in practice, then value quantification is a straightforward exercise.

If, however, the properties are not true in practice, then there is still good news, because this gives you a very tactical recommendation for remediation. For example, if a Data Product is not addressable, then this can be resolved by ensuring that going forward it does have a unique location. Or if use cases are not identified, then you can initiate a rapid exercise to identify the use cases that are currently using the asset as well as those that could possible use it in the future.

And while you ensure that your Data Products are in fact abiding by the outlined properties, you’re doing more than just quantifying the value it is creating — you are enhancing it.

References and Recommended Further Reading:

• https://hbr.org/2020/05/approach-your-data-with-a-product-mindset
• https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/cloud-scale-analytics/architectures/what-is-data-mesh
• https://terminusdb.com/blog/what-is-a-data-product/
• https://martinfowler.com/articles/data-monolith-to-mesh.html
• https://towardsdatascience.com/data-as-a-product-vs-data-products-what-are-the-differences-b43ddbb0f123