Today I’m wrapping up my observations from the CDOIQ Symposium and sharing what’s new in the world of data. I was only able to attend a handful of sessions, but they were primarily ones tied to the topic of data products, which, of course, brings us to “What’s a data product?” During this episode, I cover some of what I’ve been hearing about the definition of this word, and I also share my revised v2 definition. I also walk through some of the questions that CDOs and fellow attendees were asking at the sessions I went to and a few reactions to those questions. Finally, I announce an exciting development on the launch of the Data Product Leadership Community.

Highlights/ Skip to

• Brian introduces the topic for this episode, including his wrap-up of the CDOIQ Symposium (00:29)
• The general impressions Brian heard at the Symposium, including a focus on people & culture and an emphasis on data products (01:51)
• The three main areas the definition of a data product covers according to Brian’s observations (04:43)
• Brian describes how companies are looking for successful data product development models to follow and explores where new Data Product Managers are coming from (07:17)
• A methodology that Brian feels leads to a successful data product team (10:14)
• How Brian feels digital-native folks see the world of data products differently (11:29)
• The topic of Data Mesh and Human-Centered Design and how it came up in two presentations at the CDOIQ Symposium (13:24)
• The rarity of design and UX being talked about at data conferences, and why Brian feels that is the case (15:24)
• Brian’s current definition of a data product and how it’s evolved from his V1 definition (18:43)
• Brian lists the main questions that were being asked at CDOIQ sessions he attended around data products (22:19)
• Where to find answers to many of the questions being asked about data products and an update on the Data Product Leader Community that he will launch in August 2023 (24:28)

Quotes from Today’s Episode

• “I think generally what’s happening is the technology continues to evolve, I think it generally continues to get easier, and all of the people and cultural parts and the change management and all of that, that problem just persists no matter what. And so, I guess the question is, what are we going to do about it?” — Brian T. O’Neill (03:11)

• “The feeling I got from the questions [at the CDOIQ Symposium], … and particularly the ones that were talking about the role of data product management and the value of these things was, it’s like they’re looking for a recipe to follow.” — Brian T. O’Neill (07:17)

• “My guess is people are just kind of reading up about it, self-training a bit, and trying to learn how to do product on their own. I think that’s how you learn how to do stuff is largely through trial and error. You can read books, you can do all that stuff, but beginning to do it is part of it.” — Brian T. O’Neill (08:57)

• “I think the most important thing is that data is a raw ingredient here; it’s a foundation piece for the solution that we’re going to make that’s so good, someone might pay to use it or trade something of value to use it. And as long as that’s intact, I think you’re kind of checking the box as to whether it’s a data product.” — Brian T. O’Neill (12:13)

• “I also would say on the data mesh topic, the feeling I got from people who had been to this conference before was that was quite a hyped thing the last couple years. Now, it was not talked about as much, but I think now they’re actually seeing some examples of this working.” — Brian T. O’Neill (16:25)

• “My current v2 definition right now is, ‘A data product is a managed, end-to-end software solution that organizes, refines, or transforms data to solve a problem that’s so important customers would pay for it or exchange something of value to use it.’” — Brian T. O’Neill (19:47)

• “We know [the product is] of value because someone was willing to pay for it or exchange their time or switch from their old way of doing things to the new way because it has that inherent benefit baked in. That’s really the most important part here that I think any data product manager should fully be aligned with.” — Brian T. O’Neill (21:35)

Links

• Episode 67
• Episode 110
• The Definition of Data Product
• The Data Product Leadership Community
• Ask me a question (below the recent episodes)

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. I’ve got a wrap-up today of the CDOIQ Symposium held in Cambridge, Mass, in my backyard basically, back in mid-July. So, I kind of wanted to just talk through some… impressions I got there, particularly in the space of data product management and design, as well as a version two of my definition of data product, which is always evolving, and give you a little update as well on the DPLC, the Data Product Leadership Community that’s launching this month, August of 2023, if you’re listening to these episodes in real-time as they drop.

First off, it was a really great time. It was nice to see several colleagues there, sometimes for the first time in person. Juan Sequeda from the Catalogs & Cocktails podcast, Sammy Lane, I saw Doug Laney there, Kathy Koontz—who is, go back to episode one of this show, Kathy was on there; she’s now over at AWS in the consulting services arm—Malcolm Hawker, and of course, Sebastian Klapdor from Vista—the CDO at Vista—was visiting and gave an excellent presentation, which unfortunately, I had to see the recording of because I had a concert during his live presentation, but we were able to catch up at my favorite local tiki bar. Anyhow, what did I hear? What general impressions?

Again, this is always through the lens of my work in this space, which is quite niche, as many of you know. Having been to many data conferences over the years—primarily as a speaker, but I tend to wander the halls and the lunch tables and drop in on sessions—a lot of what I heard sounds to be the same things that I’ve heard at conferences for years and years, as well as what you might be reading the same articles and stuff that I read, but people and culture—and again, this conference skews heavily in the enterprise data science and analytics space, so for those of you from the software industry, you know, working in product in particular, just when I’m talking about data products here, I’m using that definition in the traditional enterprise capacity of the word—people and culture remains the hardest part. That said, the presentations tended to be largely about technology stacks and other defensive aspects of doing data stuff.

So, this theme kind of continues, and even some of the conversations that I thought would be a bit more quote, “Product-y,” they tended to dive quickly into all of the technical facets of a data product and looking at its attributes and talking largely about the output and the thing. So, it just goes to show that so much of the—I think generally what’s happening is the technology continues to evolve, I think it generally continues to get easier, and all of the people and cultural parts and the change management and all of that, that problem just persists no matter what. And so, I guess the question is, what are we going to do [laugh] about it? So, I guess that doesn’t leave you a lot of actionable takeaway here except to say that, to me, my perception is that investment at the highest levels continues to largely be in the technical space. And I’m wondering if maybe that’s because folks don’t know exactly what to do to tackle some of these non-technical challenges they have, particularly in the adoption space of data products—or whether you call them data products or whatever you call your solutions—that adoption piece continues to be a challenge for, you know, many organizations.

The concept of data products, basically, I went into the agenda, I typed in ‘data products’ and kind of filtered all the sessions that I attended by that lens. So, some of them, that was a very ancillary topic that might have just been mentioned once or twice, and other ones that was kind of the core theme of what the presentation was about. And even the definition thing which we’ve talked about on this show—and I’m going to be actually dropping my second—my V2 definition, since as I told you when I first put mine out in episode 105, that just like with product, it’s evolving; it’s a start. And I’ve already—I’ve been kind of mulling around what I didn’t like about the first one. So anyhow, we’ll get to that in a minute.

But in general, this definition of data product thing seems to cover these three main areas. For some, we’re talking about analytical and reporting applications. And this is close to what the digital native folks out there listening might just refer to as ‘our product.’ Your SaaS product. It’s a full application or suite of applications in the analytics or reporting or decision support space, but we’re talking about, you know, a fairly robust application that probably has a human interface to it. It might just be a collection of APIs or something like that. So that’s, like, kind of one… bucket, I guess you could say.

Then we have these kind of UI-free, mostly quote, “Invisible solutions.” So, think about things like a recommendation engine that goes into a website. So, it’s largely a model that recommends, you know, next best product, next best action, things like this. Or APIs. So, this is kind of this collection of products that might be consumed by a technical user, so they don’t necessarily have a GUI in that sense, but they are enabling some kind of business transformation, largely in a non-user interface kind of way.

And then we have these bundled data sets, sometimes which may or may not include some analysis there. And these might be sold or put into an internal marketplace, this data mart or marketplace concept I’ve been hearing about as well. And this is this idea that someone can either buy it from your catalog, or you know, you might be an internal developer or a team that’s looking for customer data from a certain facet because you’re building a model with it, so you go to your catalog of data products and, you know, the team that owns the customer data publishes some robust data products specifically around customer data that you can consume and then, you know, integrate into whatever the services that you’re making. So, this is kind of this, more of this idea of this traveling what I consider, like, a suitcase with some data inside it or some analysis that you can take with you and do things with it. But it’s a fully managed concept, probably owned by some business or domain team that really understands that space.

So, those kind of seem to be to me what the general definitions were that people were referring to, even though sometimes a concrete short, one to two-sentence definition was sometimes missing from the presentations, which I found challenging because I’m always kind of trying to imagine, what is their lens when they use these words? What lens are they thinking of it through? So, what to do with that, right? The feeling I got from the questions, I’m always listening to the questions that are being asked, I’m always curious about that—it’s probably my consulting ears—but the general feeling I got, and particularly the ones that were talking about the role of data product management and the value of these things was, it’s like they’re looking for a recipe to follow. And this was actually literally used as a word, this recipe cookbook concept.

But a lot of the leaders or people asking the questions in the audience are looking to copy someone who’s figured all of this out because they’re hearing that it’s apparently working. And I’m not sure if that’s hype and buzz, or just because there are a few notable examples of where value is being generated—I’m going to talk about one of those at the end here from a guest that’s been on this show—and some of the responses were there were not a lot of answers as to what to do. “Go try it,” was one of them [laugh] that I heard. And I was—you know, I had asked—I think, ThoughtWorks was presenting along with the Modern Data Company, you know, and I was trying to understand, where are these data product managers coming from? Like, were they groomed, were they hired out of software roles or some other kind of role? How did—like, at some point, someone started doing—taking ownership of this product management approach, right, and it was very vague how that was happening.

My general feeling is most people are trying to grow them and somehow train them internally. I know one firm is using—you know, is hiring outside product management help to train their organization. I don’t know if that—that sounded like it was something happening much later than when they actually started doing this, so my guess is people are just kind of reading up about it, self-training a bit, and trying to learn how to do product on their own. I think that’s how you learn how to do stuff is largely through trial and error. You can read books, you can do all that stuff, but beginning to do it is part of it.

Then again, it is a robust skill set and I do kind of wonder where they’re copying this from. I think everyone, a lot of the leaders there were also kind of wondering where [laugh] they’re coming from and what model to copy. My general response, too, is what to do about that is that, for those of us in the tech space, the software development lifecycle or just the standard way we do product stuff in the digital world provides a very solid recipe to copy from as a baseline. And you can go and steal seasoned product managers—and you might have to pay for them, but I actually think this is a place where people, early in product, like, particularly like someone that’s transitioning into product from maybe software engineering, maybe they’re not ready to run product at a tech company, but maybe they could run it in an internal capacity in an enterprise, but they have that experience from the tech space. They’ve worked with product management and designers most likely, so they’re going to be more familiar with what the trajectory looks like. I would be looking to steal people like that if it was my team.

But I think there’s proven methodology in that space and there’s already a recipe to copy in terms of staffing any product. Even the enterprise products will have designers, a product manager, a technical lead, and you know, if you’ve taken my training before, I believe in the—there’s actually a four-legged stool now, which is this data specialist. So, this is going to be your data scientist or your analytics person or someone, if the single tech person doesn’t have that knowledge, sometimes we need that fourth leg of the stool, which is that data expert. Of course, that’s obviously quite relevant here in the enterprise data space where we largely are building technical products and you almost certainly need to have one of those.

So, why they’re not copying all that, I don’t know. I understand it’s not a native space. It’s not their—where they came from, but they’re wondering sometimes why digital companies are—these smaller, more agile teams are having these big impacts, and I’m always kind of going back to well, what can you learn from that? What can you copy from that that’s working? And I don’t think it’s just luck. I think it’s that they’ve learned how to go build more human-centered solutions that actually get used.

And if you get the usage part down, you’re much more likely to get the business value, which is what everybody’s chasing. So yeah, I think digital native folks see that world we just see the world differently. I say ‘we’ because that’s what I come from originally. And this gets really interesting, too, [laugh] because it’s like, I think when you go to these conferences—I’m sure many of you have been to them—you know, there’s usually a big expo room where all the vendors are set up. And the vendors are largely consulting and software vendors.

And I have a feeling a lot of the product people in those companies would probably self-identify as, “We sell a data product.” And then you’ve got practitioners, industry people like your data scientists and analytics and architects and all of this, inside of these traditional orgs that think they’re building data products, using these vendor tools. Does it even matter? I’m not really sure it matters all of that much. I think the most important thing is that data is a raw ingredient here; it’s a foundation piece for the solution that we’re going to make that so good, someone might pay to use it or trade something of value to use it.

And as long as that’s intact, I think you’re kind of checking the box as to whether it’s a data product because it’s going to be managed as a really important solution whose quality has to stay at a certain level in order to keep those people paying for it or trading something of value to use it. Which may just be their time, but this is that idea of that innate quality dimension. The benefit has to be there for it to be a product, so in my definition, I’m basically saying, if there’s no use, it’s actually not a product. And sure there’s such thing as, like, well, that product didn’t sell very well and we would still call it a product and I understand that maybe you see that as a flaw, but I think for the purposes of the definition being helpful, I’m considering products as things that are launched in production that are getting used and someone wrote a check for it or with their time. They’re happy to have it in place in their business or to be literally using it themselves if they are the target user.

What else? Data mesh came up a few times. I’m not an expert in this space. Omar Khawaja from Roche had a presentation that talked about this, as did Sebastian Klapdor, CDO from Vista. Both of these great guys have been on this show before, so you can go back and listen to their episodes. These two presentations as well were the only two that I remember that had any mention of human-centered design, user experience, usability, anything like that, as part of their process about how they do things.

I know, I believe it was somebody from Amazon AWS who also talked about when they’re doing consulting, they start a lot of their work with some kind of workshop, usually for a couple days, which uses the Amazon design process and working backwards from that future state. So, it seems to be, like, the teams that have leaders that came out of some digital background very much see the world and how they structure their teams differently than the ones that didn’t. That’s my—the general pattern that I think I’ve seen. And this is not a quantitative study or anything like that, but as I met several different CDOs there, I would always ask them if they had DPMs and stuff like that. And the ones that felt quite confident about their results and what they were doing, those tended to have large staff.

One CDO I met, I think had 30 product managers under his team and this was—as he said it, like, “I don’t know how you do this work without it because you need to get that adoption and that value piece there and you need people who can abstract problems away, right, so you’re not building 929 point solutions for individuals in the org, but rather, you’re seeing patterns of problems and you’re abstracting away these little one-off solutions into general products that can kind of service a set of problems that different people have, or a single problem that multiple people have.” That skill set seemed to be quite important to this person. But in general, the notion of design and user experience, while adoption was talked about a lot, these words as skills that can help with the adoption piece were not largely mentioned. I’m not super surprised by this. Like, it’s been pretty rare.

For years, I’ve been going to conferences and stuff and it’s quite rare to find or hear anything about design and UX, except from a very small number of practitioners. And usually, they are the ones that already have product management function in there. And I think that’s why is because most good PMs I know that are working on any type of product that has a complex or heavy user adoption piece know that they need to have their technical and their user experience counterparts there to ensure that usability and utility part, those qualities of the product are actually met. So yeah, in general, just not a lot of talk there, except from—I remember Omar and Sebastian both mentioned this role or method within their teams as being important there.

I also would say on the data mesh topic there, the feeling I got from people who had been to this thing before was that was quite a hyped thing the last couple years. Now, it was not talked about as much, but I think now they’re actually seeing some examples of this working. What does that mean? Does that mean there’s a lot of examples of it not working that don’t get presented about? I’m not sure.

I think the idea of domain ownership following, like, a set of data products makes sense. Even if data product means something different in the data mesh definition, this idea that there’s a team that has some domain knowledge that this is, like—this is a given if you’re in the digital space, and you’re building products for, like, a specific industry or a specific demographic or psychographic or some affinity group, you need to understand the domain knowledge. So, you either bring that in as a SME, you know, Subject Matter Expert. I don’t know how you do this work effectively without that because you’re basically just running a bunch of really expensive guessing projects which can get really expensive, especially if there’s a large upfront cost to those. So, that concept makes sense to me whether you’re following the whole data mesh thing or not, but it seemed like some of the leaders were finding some good progress, having implemented that.

So, probably the most evolved explanation of building data products, specifically kick-ass data products, as Sebastian said. So, I love Sebastian Klapdor. Good guy, it was nice to get to meet him actually in person. So, he was on episode 110 of this show.

And he gave a very well-received presentation. Again, unfortunately, I had to watch the recording of it because I had a concert during that time on the last day, but he gave examples of the financial impact of his team’s entire portfolio of data products that they had shipped there. And so, that seemed to answer a lot of questions for the CDOs in the audience who were kind of wondering what does this look like if you do it successfully. I think there’s definitely some proven track record in what’s going on there. And I’m really happy that actually, we have a Vista data product manager in our Data Product Leadership Community as one of the 20 founding members, so if you’re curious to get some of that Vista perspective, you can join this DPLC when it launches. I’m going to have a little bit more update on that at the end of this episode.

So, this kind of brings me to definition of data products and my evolving definitions. So, if you want to read about this because you have absolutely nothing better to read, if you go to designingforanalytics.com/dataproduct, I put a little vanity URL in there to a post on my website that I’ll probably just keep evolving over time. But I wanted to read my version one definition, which is about eight months old now, and then give you my current version two definition.

So, until today—or yesterday, I guess it [laugh] was, when I wrote this down formally—my definition of data product was, “A data-driven, end-to-end, human-in-the-loop decision support solution that’s so valuable, users will pay to use it if they have to.” And that’s—I went into very deep definition there in episode 105 of my show, if you want to kind of hear about that or read the transcript. And I actually like a whole lot of that definition and my new definition has not changed a lot. But let me just read the new one, and then you can compare, I guess. My current definition right now is, “A data product is a managed, end-to-end software solution that organizes, refines, or transforms data to solve a problem that’s so important customers would pay for it or exchange something of value to use it.”

I’m going to read that one more time, “A data product is a managed, end-to-end software solution that organizes, refines, or transforms data to solve a problem that’s so important customers would pay for it or exchange something of value to use it.” So, I wanted to capture more things than decision support. I remember Tom Davenport had given me that feedback that he thought that was kind of limiting. I actually agree with him in hindsight about that. The human-in-the-loop part, I took that out and I focused on using the word customers here because our customers are probably going to be orgs, and orgs always have humans.

So, I see a company is still a human being because there will be a buyer at some point who is a human in that org. However, the solution may be largely invisible or it could be fully automated. So, I took that human-in-the-loop part out and the decision support aspect out because those are only two facets of it. I think there are definitely data product tools that can be for organizing data or for managing it, cleaning it up, as well as transforming it. So, when you start to think about large language models or anything that’s doing predictive analytics or AI systems and things like this, this is that act of—and I’m not talking about ETL when I talk about transform here. I’m talking about we’re taking a raw substance and refining it into something of value.

And so, by definition, it has to start with or have this raw data element to it and then we improve it in some way that we end up with a software solution that’s of value. And we know it’s of value because someone was willing to pay for it or exchange their time or switch from their old way of doing things to the new way because it has that inherent benefit baked in. That’s really the most important part here that I think any data product manager should fully be aligned with. Even if you don’t agree with the front half of my definition, it’s the value piece that’s most important. And understanding the utility and the usability and all the human factors that go into it, that is critical.

Otherwise, you’re just shipping outputs again and you’re back to doing projects. So anyhow, those are the two definitions. You can read them again at designingforanalytics.com/dataproduct and I’ll be keeping that up to date over time.

The last thing I wanted to give you—well, there’s two last things. The first one is, again, I find it fascinating, what are the questions people are asking at these conferences? And so, I wrote down, these are some of the ques—primarily the questions that were asked in the chat because CDOIQ is available as a digital experience as well, so you don’t have to attend in person, so there was almost always going to be live questions that were not written down in the chat. But some of the questions in the data product space included, what are best practices on how industry is using data as a product? Why data mesh versus other options?

What are some good examples of good data products that meet your definition? Again, I’ve shortened some of you just for clarity, but keep going here. Does your org have a centralized team or center of excellence of designers, data developers, and architects who serve many teams versus one team? Is it important to have an aligned data product definition inside an enterprise? Do you have a recipe, formula, or algorithm for use in the creation of data products, perhaps rolling up into some type of cookbook?

Do your cross-functional teams have part-time or full-time service or user experience designers? At what point in time is the concept of data product becoming overkill? Is calling a simple data API a data product always making sense, especially with the 120 data products you cite having? What are the key skills and responsibilities you want in a data product owner? How do data products aligned with the concept of semantic layer and data marts?

Is there a definition of done standard you suggest when creating a data product strategy? What minimum capabilities should I expect from data products? What resources have you leveraged to educate your business partners on examples of data products? And finally, is data domain equal to a data product?

So—wow, that’s a lot of the word ‘data’ and ‘product’ in whatever those 12 bullets were. So, hopefully, that didn’t bore the snot out of you, but just it kind of gives you an idea of what quote, “Everybody else,” is thinking about, if that’s curious. And I’m always curious, like, who else is having these questions? And I love the upvoting feature they had when they do these questions.

So, how to answer some of these questions? Well, beginning August 15th, 2023, these are exactly the kinds of questions that you can discuss and answer and get answered, perhaps with peers like you in the Data Product Leadership Community that I’m launching this summer. It’s finally moving ahead. The founding members had a chance to meet. We’ve kind of set some of our rules of the road, our kind of privacy policy, how we want things to run around here, so what the culture is going to be like.

And so, it’s time to get this thing opened up. So, space is going to be limited to a hundred people, which means because we have 20 FMs already, we’ll have about 80 slots initially. And then we’re going to—I’m just going to kind of pause it and see how things are going. I—a hundred was kind of an arbitrary number, but it felt like that was a good place to just hit pause and make sure it makes sense to keep scaling it. But the goal isn’t necessarily to cap the community at any one particular size, so long as people are still feeling like they’re having intimate conversations and able to really connect with people.

People who joined my mailing list via the community announcement page will get earlier access and a special discount for the first year of membership at launch. So, if you’re interested in that, just head over to designingforanalytics.com/thecommunity. And yeah, I hope to see you there.

Our first monthly Zoom session, which are short presentations, followed by a topical conversation kicks off August 17th, 2023, with a former Experiencing Data guest and founding member Katy Pusch on what it takes to launch a successful data product. So, you’ll get more information on upcoming sessions at that URL. We’ve got 20 months' worth of content coming up there and that doesn’t include guests’ presentations. I’ve already got one CDO who’s interested in coming and talking to the group about what’s working and what’s not with data products and data product management in his org. So, I hope you’ll come and join us. Again, that URL is designingforanalytics.com/thecommunity.

And finally, if you have a question for me, you can always leave that at designingforanalytics.com/podcast. You can record it anonymously or with your name right from my web page and I will try to answer it here on the show. All right, until next time, stay tuned for more interview episodes, so you don’t have to listen to me ramble for 30 minutes or however long it’s been. I wish you well and see you out there.