Member-only story
Data Architecture Trends Part 2; How to Demonstrate Data Value by Productising
Treating Data as a Valuable Product in Modern Data Stack
For as long as I can remember, we have been talking about "data as an asset".
It's an asset for an organisation; we should treat it as such. However, it is impossible to get buy-in for this approach. If data truly is an asset, why do companies fail to invest in it? You wouldn't let your company's offices (an asset on the balance sheet) become derelict by not keeping up with repairs and maintenance, right?
The implementation of this approach has been littered with challenges. How do you quantify an asset? i.e. in a physical reality, what does it mean? If you can't explain that to a stakeholder, you can't reasonably expect them to own that asset.
Introducing Data Products; bridging the gap between loosely defined data assets and clearly defined physical outcomes with a business context.
So — What Is Data Productisation?
When Wozniak built the Apple I, he initially wanted to give away the design for free to other engineers.
Jobs saw this piece of kit as a "product", something that is real, tangible, valuable, sellable & usable. Similarly to Wozniak, in the data world, we have been busy building big data infrastructures, scaling large pipelines, and tinkering with different ETL tools — none of which the business cares about.
Linking data to value has been a fundamental challenge, and Data Productisation is here to solve this problem.
Data Products are a piece of information that addresses a fundamental business need. They directly link to a business outcome, which in turn drives a key business metric, like revenue generation (makes you more money), risk mitigation (mitigates risks, regulatory, reputation, etc.), and operational efficiency (makes your job easier/better).
Examples of Data Products are your C-suite dashboards, a model that helps you predict when a customer will churn, data for sales leads that allows your team to sell more services, etc.
But that's just the Data Products part; what about "treating as a product"…
