Data Products are currently experiencing a rise in prominence largely due to the work of Zhamak Dehghani and the release of her 2022 book Data Mesh.
You may or may not be a fan of the overall concept of Data Mesh. For what it’s worth, I think it’s a great idea in theory, but as famous New York Yankee Yogi Berra once said, “In theory there’s no difference between practice and theory, but in practice there is”.
But setting aside my overall views on the approach, one element of Data Mesh that intrigues me is the second principle; Treat Data as a Product. This means taking a Product Thinking approach.
Product thinking in and of itself is not a new or revolutionary concept. Marty Cagan one of the pioneers of product thinking has written and presented extensively on the subject. Also cited by Dehghani, he lists four characteristics of a good product as being; Valuable, Usable, Feasible and Viable.
Being Valuable means that the product is wanted and needed by someone. This draws parallels with some of the things I recently wrote about when discussing Data Demoralisation, and the need to make sure your analytics initiatives have purpose.
Usable means a product is intuitive and easy to figure out how to use.
Feasibility is about the technical aspect. Is the product achievable with the current technology and skills available?
And Viability is about the economic aspect. Does investing time and money in developing the product make sense? Will there be a return on investment? Viability may also consider legal, ethical and reputational constraints.
These all feel like very sensible ideas to apply to our data.
Dehghani when more specifically describing Data Products adds her own additional characteristics, which she describes as being the baseline attributes of a data product. These are:
Discoverable – i.e. people know it exists – think Data Catalogs etc…
Addressable – offers a permanent and unique address, stays in the same place and doesn’t get superseded by something different.
Understandable – this plays into the usability element. A Data Product should be intuitive but also have accompanying documentation (like formalised descriptions of the data… think data dictionaries)
Trustworthy – data quality metrics should be in place but you should also consider timeliness, completeness and performance
Natively Accessible – The Data Product should can be accessible for a range of users using their preferred tooling. e.g. SQL/Excel/Power BI
Interoperable – Data Products should used common data and metadata fields, across products and domains, allowing them to talk to each other and or be consolidated.
Value on it’s own – a single table with no context is no good… there should be wider context and value using a curated set of data
Secure – Well duh!
Again, these all sound like sensible and admirable ideas to be applied to your data. So what exactly IS my beef with Data Products?
Mainly the godawful name!
Here’s a quote directly from Data Mesh:
“The Data as a product principle defines a new concept, called data product, that embodies standardised characteristics to make data valuable and usable.”
This is an outright lie.
Or at least the name Data Product is not new.
If you go back to 2012 and the publication of Data Jujitsu: The Art of Turning Data into Product by former United States Chief Data Scientist DJ Patil, you will also find reference to the idea of Data Products. It’s just that he’s not necessarily talking about the same thing as Deghani.
Which ultimately leads to the fact the term Data Product is now ambiguous. When someone uses the term, what do they actually mean? Deghani even hints at the ambiguity herself in the opening chapters of her book:
“The term data in this book, if not qualified, refers to analytical data. Analytical data serves reporting and machine learning use cases.”
Reporting and machine learning use cases are the bread and butter of most organisations, and the idea of a Data Product in this context makes great sense.
So why not remove that ambiguity? At work, we’ve been referring to the idea of Analytical Data Products when talking with clients who want to start applying Data as a Product principles. I personally would like to take that a step further and just call them “Analytics Products” though that idea seems to have been vetoed by my overlords (…though if anyone else wants to help me start this as a new trend, I’m here for it).
Anyways, regardless of what we end up calling it, the principles of Data as a Product are certainly appealing. Applying Product Thinking to your data as well as accompanying your data service offerings with the governance wrapper provided by the data product baseline attributes are sensible ideas, and the Data Product hype train certainly feels like a journey worth jumping on.
0 Comments