Productness and Lack Thereof - an Opinion(*) on Data Products

(*)that I would really like to call a TRUTH, but this time I dare not (but honestly I think it makes sense)

“What is a Data Product” - yes we are doing this now on Common Sense Data! But not necessarily the way you’d expect.

I want to focus on an interesting problem that seems to plague most organizations working with Data Products today: there’s a lot of Data, but very little Product.

Okay so what is it then?

A lot of digital ink has been spilled over various definitions of “Data Products” ever since the term gained popularity a few years back, riding the wave of Data Mesh. Many people far more erudite, eloquent, and experienced than I have offered their definitions, and many of those are really good!¹

I do a lot of work with Data Products in my consulting engagements, and over time I too have formed Opinions. Some of those opinions relate to the definition of “Data Product”, yes. Some of that I have written down in the past², and indeed my only claim to any hint of authority on the topic comes from being possibly the first person to create a publicly available (though paid-for) Finnish-language training on Data Products together with my friends at Creatido³.

Which is to say, I’m no authority at all, and these are just my opinions. Also, I don’t want to get stuck in the Pedantic Layer with this, so I will skip most of the definition part and simply point you all to Anna Bergevin’s excellent article on her Substack, When Data Met Product (which I heartily recommend - nay, insist - you immediately subscribe to):

Data Products as Modular Components - A Flexible Framework

Basically, what she says there in the very beginning about Data Products is also how I think. At the very basic ground level, it’s a collection of stuff that stores and processes some set of data, and in the end there are some user (or application) interfaces from which data comes out.

That, however, is neither the interesting nor the critical part of what Data Products really are about.

The “Productness” of Products

It was Nick Zervoudis (a brilliant and practical data product thinker and educator, and an all-around cool guy) whose LinkedIn post originally introduced me to the concept of “Productness” in the context of Data Products. Now, I can’t for the life of me find the original post anymore⁴, but the point was that there are dimensions of “productness” - Opportunity Discovery, Solution Design, Solution Delivery, and Value Realization. In the other end you have actual products with actual product management, and in the other end it’s basically just doing things like you always did but calling them products; i.e. products in name only⁵.

See, Product Management is an actual honest-to-god discipline, with all sorts of books and courses and everything around it, and has been for decades! It was not invented by a bunch of data techies five years ago!

A product is actively managed throughout its lifecycle. For a product, we know who the users are, what the use cases are, what value the users are getting out of it, we have success metrics, we have lifecycle management (incl. sunsetting!), we have Go-To-Market activities and user interviews and usability research…

Here’s my thesis, or, well, an opinion, based on lots of discussions and reading and some real work in the trenches:

Most organizations who claim to do Data Products hardly do any Product Management.

Most of the Data Products we see today are lacking in productness. They’re PINO⁶ - and that means that the big value promise of Data Products is not being realized at all. But to understand this thesis better, we have to look at the big picture.

The holistic Data Product approach

This is how I see Data Products as a whole - it’s a layered thing, like an onion⁷, and we need to consider all these layers to build a successful Data Product approach for any given organization:

The three layers of the Data Product approach

Layer one: Technology

The innermost layer is the obvious one: technology. While I personally believe that you could turn absolutely any technological solution into a Data Product if you just keep the other layers in good order, it is certainly necessary to consider how Data Products are built, stored, and served from a technological standpoint.

A lot of the Data Mesh literature, for example, goes rather deeply into the various platforms and platform services you need to scale your organization’s Data Product approach without turning it all into an unholy mess of silos. And there’s the whole topic of Data Contracts to discuss, ensuring trust and connectivity between technical interfaces of different Data Products.

But:

• A lot has been written about this already, and I don’t have much to add.

• In my very humble and very personal opinion, this is not the interesting nor the critical layer, and because it’s my Substack I can decide when to move on!

Layer two: Metadata

The Metadata layer is getting strongly into the interesting territory. At this layer, we need to consider two big topics:

1. The metadata “wrapper” around our Products: what metadata we need to gather and maintain about our Data Products?⁸

2. How is that metadata going to be exposed to data consumers (humans and machines alike) so that our Products become discoverable and understandable?

These topics I want to write much more about, as I do think this is very very important. This also has a lot to do with semantics! But we must resist this rabbit hole for now, as we are about to get to…

Layer three: Product management

This is where the productness comes into play. It’s all about operating models, roles & responsibilities, processes, change management, understanding the business problem, stakeholder collaboration, market research… All the things that real products need.

These sorts of things are not some unattainable mystery magic, they’re par for the course when you want to seriously build successful products. Ask any company that makes, I dunno, shoes or something!

Product management is the work we do to ensure that we build the right thing for the right problem, that we understand the problem, and that we understand how we create value by solving the problem with the product we’re building.

This is the interesting and critical part of Data Products: I strongly believe that the vast majority of the actual value of this whole approach is in the productness of the Data Products, not in their technical encapsulation or technology interfaces or anything like that. And the productness of Data Products is entirely dependent on whether or not actual honest-to-god Product Management is applied.

Originally, I was considering writing a loooong rant here about how important Data Product Managers (or Owners, whichever term you like more) are, but then I read Anna’s piece on that and I will once again just point you to her article instead:

Data Product Managers Bridge the Gap

The thing about this third layer is that it’s very much a “soft” layer, in the traditional sense of the word. It’s about people and ways of working… and that, perhaps, is why it’s considered difficult or unimportant by most IT organizations. Which leads us to a rather blunt conclusion, I’m afraid.

Reality check

This is the world we live in.

The most valuable part of the whole Data Product approach is the Product management layer.

In the initiatives I’ve seen, experienced, read about, and heard about, the most focus is put in the Technology layer.

This means that despite the hype and the promises in PowerPoint strategy decks, most organizations have failed and will continue to fail to realize much value from Data Products.

Why is this?

It’s the same “why” we always ask in this business, no matter if it’s Data Products or data modeling or semantics or UX or value creation overall: why do we constantly and consistenly emphasize technology over everything else?

There are many answers: a large culprit is the fact that these kinds of initiatives are generally considered to be technological by their nature (mainly due to overall lack of understanding), and are thus pushed to the IT department. And IT focuses on what it does best: technology.

It’s also about the fact that most organization aren’t FAANG⁹: your average data team operates in an organization where Product Management, especially of digital products, is not a “native” competency like it generally is in born-digital businesses. There simply aren’t any Data Product Managers available! We can reuse Joe Reis’s “Enterpriseland & Productland” comparison, which he made regarding data modeling, in the Data Product context. Trying to introduce Product Management into data & analytics work in, say, a mid-sized manufacturing company is a whole different ballgame than in a software company.

So what now?

So: I have argued that right now, most organizations won’t be able to deliver most of the value potential from their Data Product initiatives. This is mainly due to the fact that they do not focus enough on Product Management, which would involve roles and operating models many organizations would find unfamiliar.

But: this is also where there is light at the end of the tunnel. Those of us who believe what I wrote above to be true can make a difference: we can and we should add focus on the most valuable third layer in the initiatives we’re involved in.

Even though not every organization has the existing know-how to deal with digital products, the discipline overall is nothing new. The real promise of Data Products is precisely there, in applying good old-fashioned Product Management work, and the value potential is HUGE. If we are able to turn the ship (slowly as it might turn), the Data Product approach offers us a unique opportunity to start solving the value-creation problems the whole data & analytics industry has been plagued with forever.

It’s (almost) never been about technology. Applying real Product Management to data can be the magic sauce. We just have to focus on the right things, and to understand that what really matters is not the exact definition of a Data Product, but what we do with the Product part.

Read Anna’s Substack, follow all the other’s I’ve mentioned (and if you speak Finnish, maybe check the training course I made), and together we will rule the galaxy make a difference!

Thank you for reading - if you enjoyed this and would like more of this kind of thing, please consider subscribing to Common Sense Data. And perhaps even share this with your friends and family!

Until next time - cheerio!

1. If you’re interested in these, you should follow people like Zhamak Dehghani, Anna Bergevin, Nick Zervoudis, Jon Cooke, Andrea Gioia, and Benny Benford, amongst many others.

2. And some of those opinions are also on video: some time ago I did a debate with Malcolm Chisholm on this, and his marketing team came up with this delightfully odd format for the discussion, for which I needed to procure and set up a green screen in my living room!

3. By the way, this is not a paid advertisement - I just wanted to mention them because we’re pals and I couldn’t have done the training course without their help.

4. I tried! Sorry Nick! If you point me to it I’ll update this later! Or if someone else finds it, let me know in the comments.

5. I like to think I had an original thought for once and came up with the initialism PINO for Products-In-Name-Only, but because I’m sure someone else has had the same brain-fart already, I don’t dare to claim it publicly.

6. See? It works! By the way, “pino” is also Finnish for a “stack”. I’m not sure yet if I can one day utilize this coincidence to construct a pun of some sort, but if it proves impossible it won’t be due to lack of trying.

7. Or, if you’re so inclined, like an ogre.

8. Think of how physical products are wrapped into some packaging, and that packaging has lots of crucial information like “Do Not Eat” or “Contains traces of nuts, milk, and radioactive polonium”.

9. MAANG? MAANA? Well you get the point.