Update: Looking for my definition of data product?

Like a product, my definition of "data product" is also evolving. Listen to this episode #105 to understand the key points in my definition. Then check out my latest definition here.

Today I’m discussing something we’ve been talking about a lot on the podcast recently - the definition of a “data product.” While my definition is still a work in progress, I think it’s worth putting out into the world at this point to get more feedback. In addition to sharing my definition of data products (as defined the “producty way”), on today’s episode definition, I also discuss some of the non-technical skills that data product managers (DPMs) in the ML and AI space need if they want to achieve good user adoption of their solutions. I’ll also share my thoughts on whether data scientists can make good data product managers, what a DPM can do to better understand your users and stakeholders, and how product and UX design factors into this role. 

Highlights/ Skip to:

• I introduce my reasons for sharing my definition of a data product (0:46)
• My definition of data product (7:26)
• Thinking the “producty” way (8:14)
• My thoughts on necessary skills for data PMs (in particular, AI & machine learning product management) (12:21)
• How data scientists can become good data product managers (DPMs) by taking off the data science hat (13:42)
• Understanding the role of UX design within the context of DPM (16:37)
• Crafting your sales and marketing strategies to emphasize the value of your product to the people who can use or purchase it (23:07)
• How to build a team that will help you increase adoption of your data product (30:01)
• How to build relationships with stakeholders/customers that allow you to find the right solutions for them (33:47)
• Letting go of a technical identity to develop a new identity as a DPM who can lead a team to build a product that actually gets used (36:32)

Quotes from Today’s Episode

• “This is what’s missing in some of the other definitions that I see around data products  [...] they’re not talking about it from the customer of the data product lens. And that orientation sums up all of the work that I’m doing and trying to get you to do as well, which is to put the people at the center of the work that you’re doing and not the data science, engineering, tech, or design. I want you to put the people at the center.” (6:12)
• “A data product is a data-driven, end-to-end, human-in-the-loop decision support solution that’s so valuable, users would potentially pay to use it.” (7:26)
• “I want to plunge all the way in and say, ‘if you want to do this kind of work, then you need to be thinking the product-y way.’ And this means inherently letting go of some of the data science-y way of thinking and the data-first kinds of ways of thinking.” (11:46)
• “I’ve read in a few places that data scientists don’t make for good data product managers. [While it may be true that they’re more introverted,] I don’t think that necessarily means that there’s an inherent problem with data scientists becoming good data product managers. I think the main challenge will be—and this is the same thing for almost any career transitioning into product management—is knowing when to let go of your former identity and wear the right hat at the right time.” (14:24)
• “Make better things for people that will improve their life and their outcomes and the business value will follow if you’ve properly aligned those two things together.” (17:21)
• “The big message here is this: there is always a design and experience, whether it is an API, or a platform, a dashboard, a full application, etc. Since there are no null design choices, how much are you going to intentionally shape that UX, or just pray that it comes out good on the other end? Prayer is not really a reliable strategy.  If you want to routinely do this work right, you need to put intention behind it.” (22:33) 
• “Relationship building is a must, and this is where applying user experience research can be very useful—not just for users, but also with stakeholders. It’s learning how to ask really good questions and learning the feelings, emotions, and reasons why people ask your team to build the thing that they’ve asked for. Learning how to dig into that is really important.” (26:26)

Links

• Designing for Analytics Community
• Work With Me
• Email
• Record a question

Transcript

Brian O’Neill: Hey, everybody, it’s Brian here. Solo episode today; no guest, you’re stuck with me and I’m going to be defining what a data product is, finally. I think it’s about time we do this, right, because, well, I talk about it all the time in the show [laugh], I’ve never had a great definition for it and I think we need one. I don’t want this to turn into marketing hype, or whatever the way, you know, I think ‘Big Data’ had its run and was never properly defined, it was clearly a marketing buzzword that had very little meaning whatsoever.

And I think data products is not a marketing thing. It’s an approach and a way of—it’s a product orientation to doing the work of data science and analytics and putting those primarily into digital tools, applications, sometimes for commercial gain and sometimes not. So, on this episode today, I want to define—I’m going to give you my working definition of what I think data products are and I want to talk a little bit too about the skills of data product managers, particularly AI and ML product managers, so people that are primarily doing this work with some type of data science background, or data sciences is going to be integral to the success of the product. So, let’s start with this, who’s this episode for? I think this episode is probably geared more towards those of you working in larger legacy enterprise organizations, non-digital natives, who you know, you have an, you know, internal data science group, perhaps they’ve been tasked with doing, you know, innovative AI work or machine learning work and maybe expectations are still running high about that. Maybe you’re on a digital team, maybe you’re on a traditional analytics team.

But this is a little bit more oriented at that audience than, say, the technology sector product managers who, I think, natively have to understand more of the ideas I’m going to share with you anyways. But maybe there’ll be some interesting crossover or a good refresher there. If you’re new to software product management, maybe you’ll glean something from this. So, the first thing I wanted to call to your attention is, I’m shipping this definition to you before I’m done. So, right there, we kind of have a modern product idea here, which is getting it out there, getting feedback on it before it’s complete.

And I think this a definition for something like this should evolve. And I don’t own this; I have a perspective and opinion about these things, but I certainly don’t own the word, ‘data product’ or what it means especially, you know, as of now, it’s November of 2022 when I’m recording this and it will probably be different down the road. And why am I doing this? Again, this is also for me to clarify my thinking about it and to help leaders like you understand what I’m advocating for so you can decide if it’s worth listening to it and if it’s relevant to your situation. So, working on this is the act of me clarify my own thinking on it.

And so yeah, so I want to break this down. Before I give you the definition that I’m working with right now, my MVP of the definition, let’s talk about the word product for a second, right, the definition of product. If you look it up on Google, you get the Oxford definition, it says there’s two definitions, but the first definition is, “An article or substance that is refined for sale.” And the key word that I want to—the words that I really want to hone in here are, “Refined for sale.”

So refine, first of all, this is inherent to the design process, in my opinion. In the digital space, we think about products don’t really end, they just—it’s an ongoing process, right? We’re constantly refining. You may think it’s like adding features and all of this, but subtraction is also part of the work. So, we’re both adding and removing things, we’re changing things, we’re constantly learning and making updates. This is very much part of the creative process and it’s a design orientation.

So, this act of refinement, I like that this is in here. But the key thing to know is that unlike some—like, a packaged good where it’s refined to a point and then you stop, you wrap it up, you put it on the wall at the store and now it’s for sale, that’s not the case with digital most of the time. You know, there’s just points in time at which we ship, right? So, I like this idea of refinement being in product. And the other aspect of refinement that’s important here is that subtraction, right, is also part of that, right? We’re not just talking about adding things all the time; products also may need to be taken down or things might need to be removed. And so, refinement is always this idea of making it better for whoever the buyer or the user is of the product, right?

And secondly, this word, “sale,” “Refined for sale.” So, this is actually a big part of my working definition here. The word sale assumes to me—presumes that there is an exchange of value between the buyer and the seller of the product, right, or the maker of the product. In other words, the value is so good that somebody would potentially pay for it. So, that’s one of the big things I want you to lock into, at least in my definition is, the value needs to be so good that somebody would potentially pay for it, they would exchange something else of value to get access to your data product, right?

And this is what’s missing in some of the other definitions that I see around data products, which are usually just about kind of the logical part or what is it within the context of data stuff, they’re usually talking about it from that lens, they’re not talking about it from the customer of the data product lens. And that orientation is, like, sums up all of the work that I’m doing and trying to get you to do as well, which is to put the people at the center of the work that you’re doing and not the data science and the technology and the engineering, or the design or whatever it is. I want you to put the people at the center, right? So, this missing sense of value, I think is really important if you want to define data products, the product-y way because the product-y way is inherently putting people at the center. It’s not putting the technology—or it’s not just talking about what the raw ingredients are, it’s really about the person that we’re trying to serve with it.

So, here’s my addition—my definition. It took me seven minutes to get into this and I hope that’s okay. But as of now, it’s November 22nd—we are—23rd; it’s the day before Thanksgiving, 2022. My current definition is, as follows:

Defining "Data Product" (The Producty Way)

A data product is 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.”

So, what’s missing in this you can see clearly.

I’m talking about this payment thing and on this episode, I want to make clear that I understand that you’re not necessarily building a SaaS inside your legacy enterprise company that your internal business sponsors have to pay to—you know, put down a credit card and use it. That’s not the point. The point is that the quality of the solution is so good for the people you’re trying to help that they might pay for it or they would pay to use it if they had to because it’s so good, the value of it is so beneficial to the people that it’s for that they would pay to use it. That’s the thinking and the product orientation that I want you to have, instead of talking about, well, it’s a set of reusable data that we package up and then people can slice and dice it or whatever. That’s fine. Maybe that’s an example of a data product but that’s not the product-y way of thinking about this.

I’m just calling it the product-y way because I think it’s important for that part of this whole episode of my message to come clear. So, what’s omitted here? I’m leaving our AI, ML, analytics, even digital when I said end-to-end solution. I left that out intentionally because there may be like what we call service design, we call them touchpoints things that are happening in real life, off of a screen that are actually part of the end-to-end solution. And I want data product leaders like you to be thinking more broadly than just what’s in the data store or the data swamp or the data whatever and working on it from that technologies perspective, but always remembering that if I’m building a model or a dashboard or an application or tooling, there’s always stuff around it.

There’s the application wrapper around it, there’s the context of use that the customer has, there’s the business process and orientation, there’s all this stuff around it. And the real question is like, how much of that stuff around it also needs to be designed into the solution along with the data science-y parts because collectively, that’s the data product, right? It’s not just the model development or, you know, the pipelines or whatever the heck it is. It’s not just that technical stuff. It’s the end-to-end piece, and that may include some stuff that happens in real life that is not necessarily all digital, all the way.

So, that’s why I left out digital. And I don’t want to imply that it has to be use AI, or it has to use ML or it has to even use analytics; it probably does most of the time. That’s what we’re usually building these tools to improve decision-making to reduce tool time and different types of taxes that we put on customers to try to do this work themselves, our users. I’m leaving those out. I don’t think they’re necessary, but if you walk away with the idea today that value here is important as it means the bar has been raised to the point that the solution is somewhat indispensable here, that’s ultimately the thing that I want you to take away with this.

So, that’s it in terms of at least part one [laugh] of this podcast is giving you that definition. I’m going to ask you for some feedback at the end of the episode and you’re welcome to send that in to me. I’d love to hear what you think about it. I know this is different than other definitions that are out there. I just want to hold this torch out there because I don’t think the other ones are always getting the point about what it means to do passionate product work to build things that matter and to make impact.

I think that’s often missing here, and it’s kind of like, the way I say it right now is the data community is like, it’s stepping its toe into the pond and kind of feeling the water out there and like, “Oh yeah, this product management stuff that, like, the software industry has been do—like, yeah, maybe we could learn something from that. But we’re not really doing software, we’re doing this data thing and that’s different. But now the worlds seem to be coming together a little bit more, but we’re just kind of dipping our toe in.” And it’s like, “No, I want to plunge all the way in and say if you want to do this kind of work, then you need to be thinking the product-y way.” And this means inherently letting go of some of the data science-y way of thinking and the data-first kinds of ways of thinking.

So, that’s my rant on—not my rant. My definition, my current thinking on this, and it’s probably wrong, it’s probably going to change, but you got to ship. So today, it’s 2022. I’m finally shipping what I’ve been talking about for a while. And I’m going to sit with this and who knows when I’ll revisit it, but it’ll probably be an ongoing process.

So, that’s that. I want to give you some other just thinking right now about AI and machine learning product management specifically. And now I’m talking more about job responsibilities, whether you have the title or not, but this idea of product management where we’re working with AI and ML, some skills that I think are needed in this space if you’re going to do this kind of work. So, if you’re interested in moving into this kind of work, I’m going to share some—what I think the skills are. If you’re trying to hire for this kind of work, I’m going to talk about what some of these skills are and things to be aware of.

So, the first thing is, I think, doing product management, doing AI or ML product management, you need to be comfortable with the fact that the domain that you know about is potentially or very foreign to users and stakeholders, particularly when they are inside the enterprise, right? Really learning how to obfuscate the technology piece and the data science piece and framing things in the words of the people you’re talking to will be key to building relationships and moving your data product efforts forward. So, you need to speak the language of whoever it is that you’re talking to. So, in some cases, if the tech can be entirely hidden from the users, then it’s easy. In fact, your product may reduce the need to even have any type of metrics-laden in interface that used to require a lot of eyeball analysis.

But in order to create trust here, you need to understand how your solution is understood or perceived in the eyes of the people who it’s for, and the more that you’re familiar with the language they use, and that you’ve done the requisite listening and relationship development to understand their domain, their talk, their speak, the more that can come through in your data product, the more you’re going to have some success with the work that you’re doing instead of shipping stuff to crickets and it doesn’t get used, or you have that low adoption problem that we’re all trying to fight against. So, another thing I wanted to talk about here is I’ve read in a few places that data scientists don’t make for good data product managers, and you know, we talk about the general introversion, too, of data and analytics people. And there might be some truth there that, overall, if you kind of survey people and ask them what they thought that they do self-identify more as individuals, and they like to work alone and they’re not—you know, they’re more introverted and all those things might be true. I don’t think that necessarily means that there’s something inherently against data scientists becoming good data product managers. I think the main challenge will be—and this is the same thing for almost any career transitioning into product management—is letting go of your former identity to a degree, or at least learning how to take that hat off when it’s not appropriate.

So, in your case, it may be having to kind of take off the data science hat and put on the other hats required to do product management work. And learning that you might need to delegate some of that even though you may know how to do. It’s learning how to delegate that technical work so that you can focus on the strategic part, the big value delivery part, which is the stuff that all the stakeholders and users and customers are—that’s all the stuff they actually care about, not the build part. So, you will need to learn to let go of some of the implementation details so you can make the time and space to focus on the big picture.

And at some point, you’ll realize the val—I think it [sigh] may not come through right away, but at some point, either because you’re incentivized to do it or because you want to level up your career or you want to have a bigger impact and a legacy with the work that you do, you might realize that being the one that’s doing the model development yourself and all the crazy math and all the beautiful technical work that you know how to do, there may be an opportunity for you to have a bigger impact that doesn’t mean necessarily doing all of that implementation work. And so, product management, it’s a generalist role, it’s a little bit fuzzier, there’s a lot to it. And I’m going talk about those skills today, right now. So, another skill here is, of course, as you know, if you’ve listened to the show, I think, design and user experience, particularly research skills and listening—if you remember the Episode 104 we just did with Indi Young, I definitely recommend that—but also human-computer interaction, understanding the basics of these things, why it matters and how that will be relevant to your product getting adopted because you can’t get to business value if you don’t have user adoption.

So, as I always, you know, talk to my clients and when I’m doing training, if you keep talking about business val—the leadership is talking about business value from data, and I’m like, that’s great, but you got to solve the adoption part first. So, make better things for people that will improve their life and their outcomes and the business value will follow if you’ve properly aligned those two things together. I would even say that, relative to even regular, like, traditional software product managers, the data or the machine learning and AI product managers, you may need to have even a deeper understanding of UX, particularly for dealing with, like, interfaces that are using predictive models and they’re generating different kinds of results based on what the inputs are, what the context is, right? And learning how to know when the design of the product is good enough to ship and understand the different kinds of predictions that might come back. And then how does the experience for the user going to be different or need to adjust to accommodate an interface that’s probabilistic, that doesn’t always show the same thing for every user and every single session when they sit down and use it?

This is not always true. It may not, but I think if you have an interface like this, it’s just a harder design problem to design for because it’s not a simple transactional thing where you can design every state and you know exactly what the logic of the system is and you just, you know, make sure you handle all the edge cases and empty states and all of that and you’re done. We’re really talking about systems that are generating stuff that we may not have seen before. So, how do you know if the design is good enough? And even if you’re not the one doing all the design work, being able to recognize and give that instruction to your design team in a way that’s what I call design actionable, user stories, use cases, things like this, you need to be able to do that, and in order to do that, you need to have some knowledge of what design is and what user experience is so that you can have that relationship with the people doing the work.

In reality, I think a lot of enterprise design teams are not going to have design and user experience resources. Most of them don’t. I think it’s growing, but if you don’t have it, guess what? You’re probably now in charge of the design. And it’s not uncommon that product managers actually dabble in design.

And, you know, in most software companies, obviously, usually have a product designer, especially if there’s a fairly large or sophisticated interface, they know that there’s too many details there for one person, a PM to get to do all of that stuff, right, and that can make or break the adoption thing that we’ve talked about. So, just know that you need to know about it, and if you don’t have resources to do it, then you probably need to know how to do it. And that’s mostly going to come through some kind of training and then actually practicing it and doing it and learning how to design with users and customers and not just for them. And this whole idea of with not for, that’s another thing that you need to be really comfortable with as any type of product manager, but especially as a data product manager, I think because machine learning and AI are foreign. And if you’re asking people to trust the model predictions, for example, one way to build that trust is to make your stakeholders and users part of the design process so that they have a stake in it, so that they feel like they’ve contributed to it.

And it won’t be such a surprise to them because they’ve been participating all along. They didn’t wait to see something a long time later; instead, they’re regularly part of the creation of the thing. And that’s a way to build trust early and often so that they have skin in the game, right? The other thing I would say about this, and in terms of the design and UX piece is that everything I—maybe you’ve heard me say this, everything has a design, whether you put intention to it or not. There’s no such thing as no design and experience.

And so, this also means by definition, platforms have an experience, APIs have an experience, you might have heard developer experience before. Your data, if you’re building a platform to try to help the data scientists on your team do faster work or to accelerate maybe some of the more mundane tasks that they have to do, well your data scientist, while they’re probably fairly technical and smart, it doesn’t mean they like complexity for the sake of complexity or that they necessarily want to spend their time doing tasks that are not optimized for the sweet spot of their skill set, right? So, you can design good services for very technical people. Or you can just let them emerge out of your tech stack and this is what I call that byproduct design, right? My point is, this stuff, these services, whether there’s a visual interface or not, whether it’s a command line interface or it’s a platform, good user experience practices can still apply because developers and data scientists are people too. They have work to do; there’s busy work and there’s high-value work, and tool time and busy work is not what you want to be paying those people to do anyways, you want them using their brain and doing goal-oriented work, right?

So, how much are you going to design the system to help them do that? Again, how much intent do you apply? The big message here is there is a design, there will be an experience, whether the endpoint is an API, or a platform, a dashboard, a full application, whatever it is, there is an experience, so how much are you going to intentionally shape that or just pray that it comes out good on the other end? And prayer is not a strategy that’s reliable here, or wishing and hoping, right? If you want to routinely do this work right, you need to put intention behind it. So, that’s kind of my points on the design and UX piece.

The second one is sales and marketing. So, the short answer here is if you’re trying to change how people think, and this is hard—or change people’s behavior—learning something about marketing can help you. And similarly, sales, even though you’re not trying to get someone to pay, like, write you a check for something—I mean, you actually may be you may be trying to get funding for something, the point is, if you’re trying to get something out of somebody, you need to explain what the value is to them. And so, we’re actually all selling all the time. Even when we don’t notice that we’re doing it, we’re engaging in sales-like behavior.

And I think being aware of when we’re doing that and learning something about how good sales is done, particularly consultative selling, I think is the most relevant time because I think a lot of us—and I used to be this way, too, until I had my own business—I used to think car salesmen: pushy, trying to get you to buy something that you don’t want, the telemarketer approach and all of that. And if you’ve ever dealt with a very good salesperson, that’s not how it feels at all. It kind of feels like you just simply arrived at some destination and decision together and then you went with it. And it was just, like, they’re just kind of helping me out. They’re not trying to convince me of anything.

But there’s a lot of psychology and thinking that goes into that. And this can be helpful especially if you don’t own your resources, which many PMs don’t, your IT department’s over there, you know, the QA department’s over there, your engineering resources don’t belong to you, your design reasons don’t belong to you, you know, procurement has a say in it, but you have no control over what they’re doing. Whatever it may be, you might need to convince some people to go with you on the mission that you’re on with your data product, right? So, learning about some of these methods from sales and marketing can be helpful in furthering that mission to get people on board with what you want to do. Do and that’s very much not technical work, right? It’s not data science work. It’s not all of that.

So, if your eyes are glazing over and you’re like, “Ugh, that sounds like—I have no interest in that,” that’s okay. I think knowing that’s not your sweet spot or that you don’t even want it to be your sweet spot is good. It means maybe you need to raise the flag or say, “I need to hire somebody for this,” or my team needs to hire somebody for this, or we need training for this. But just know that this is part of the game, like, this is—and I don’t mean game in a way like it’s an unfortunate thing. I mean, the bigger infinite game that we play trying to put new things into the world that are sometimes disruptive and different. Like, this is just part of that. So, that’s my thoughts there on the sales and marketing skill set.

This really gets into relationship building, right? I know that if you listened, I think it was Manav Misra that was on from Regions Bank talking about this. But you know, he talked about trying to get his leads on his data team to push back, to speak up in meetings, to push back, to ask good questions in a genuine, empathetic way, not to challenge the person, but to have open and frank conversations about why do you want to use, like, AI on this project? Like, what are you hoping to achieve with that? And really digging into the unarticulated problems.

Relationship building, I think this is where user experience research can be very useful, not just for users, but also deployed with stakeholders, right, is learning how to ask really good questions and learning the feelings and the emotions and the reasons why people ask your team to build the thing that they’ve asked for. Learning how to dig into that is really important. Over time, though, what you’re also doing here when you’re doing that kind of research and listening, or just having conversations but mostly listening and not talking is that you are developing trust and developing long-term relationships there. And so, part of the reason you also need to do that is that not everyone in your team has the time to do all of this work at the level that you may need to do it, so you also will need to then translate your findings about these things into actionable, useful summaries or language or a strategy that the team that makes up your data product can understand as well. So, when they’re asked for something, you can give that appropriate context for where did this ask come from? Why are we doing this work? And you can give the answers to that because you’ve formed the relationships and you’ve built the trust over time there.

So, does this get into politics? Yeah, it probably does, especially if you’re in a big company that moves slow, and you’ve got lots of fiefdoms and power is disseminated across the organization, no one team can really do too much just on its own. Yeah, I would say get ready for it, and if you don’t like it, and I’d say you have to go learn about politics necessary, but people are self-interested, and so learning how to figure out how is what I’m doing beneficial to this group or to this individual, as well as the bigger mission that I have, that’s actually, you can even think about that as politics or you can kind of think of it from an empathetic standpoint, like, “I really want to help this person. Is there some way that my solution here actually would be of service to my colleagues here?” So, be aware, there probably will be some politics involved.

And that kind of gets into the alignment thing, right, too, between these different teams that you might need to work with, right? Not only do you need to know all the interests of the people, but you might need to get all those people aligned, particularly if interests aren’t the same like the digital team has this other agenda or strategy they’re doing, but IT doesn’t want to help with whatever. And how do you unlock all those barriers so that the data product effort you’re working on can move forward, right? So, another one is, when we have that understanding that we’ve—when we’ve talked to our stakeholders and our partners and things like this, I’m hoping that you’re also formulating a strategy and you’re getting clarity on it. And this might in part be taking the strategy from your executive management or maybe your CDO if you’re reporting to the chief data officer or something like that—or maybe you are the chief data officer—and you have a high-level strategy but you don’t have one that’s quote what I would call, “design actionable,” yet it’s not directly actionable at this point, hopefully, over time, what you’re also doing is learning to take all these inputs in and turn them into a brief strategy statement and provide the right amount of clarity based on who you’re talking to that the team, the developer is doing the work or the analyst or the, you know, the partners, the people, the dependencies that you have with the other organizations, getting that clarity will come through all of this work that you’re doing, and that I think really falls on you to be able to formulate that clarity as well.

So, that’s kind of it for the skills part. So, just some general thinking about skills on data product management. I think some of this you can learn through training, but without self-motivation, you’re just probably going to learn skills that you don’t apply. Like, you have to be willing and interested, I think, in doing this kind of work. And I’ve seen this before, like, in my training seminar that I have, I sometimes have people go through it on it—you know, a private client will come through and they have, you know, half the team is really excited to be there, the other half is just kind of a little bit curious.

And so, there’s ten people, and five of them are just kind of curious what it is and the other five are like, “I want to get better at this.” And the reality is, there’s so much information out there, like more information on how to do stuff, whether it’s product management or data science, that’s not the issue, there’s plenty of free information out there. If you don’t have the motivation, and you don’t want to make the change, both for yourself but also for the people that you’re going to serve with these data products, it’s just not going to work. Like, you have to want to do this kind of work. And if you don’t want to do it, that’s okay, but you might be more successful with the user adoption problem and the business value problem if you get somebody who does.

So, either hire the people, or hire some help to do it for you, or upskill your staff if they’re interested in doing this kind of work, right? This is also, like, partly why when I do my training in this space, you know, it’s eight weeks. Four weeks is the content and the material, but really, the reason we meet every week is to practice doing this work on real projects in your business, getting feedback from me and the other people that we’re working with together that are on the same journey and having that support there. And so, this actually gets into why I’m also trying to launch this data product leadership community that, if you’re on my mailing list, you’ve already heard about it. What this is I want to bring a place together for data product leaders to converse about the work that they’re doing to get support when things aren’t going well, primarily to have a non-technical place.

And there’s plenty I mean, it’s okay if people want to have technical discussions, too, but I wanted to kind of take that aspect that I’ve learned is, I think, valuable in the formal training that I do and just break that off for this group of people that thinks product and design matter when we do the work of data products and data science. So, if you’re interested in that community, just getting on the announcement list, it’s not live yet, you can go to designingforanalytics.com/community and that’s where that’s at. But again, you have to want to do this work or you need to find people that do want to do this work.

I think it’s going to really help if you struggle with the low user adoption thing, data product management, and design, the two of these things will help you get the adoption thing moved up, and that’s what’s going to drive the business value, and that’s what’s going to make the business take your work seriously and say, “Yes, please. Give me some more. Can you help us with this?” Or even better, if the expectations are on your team that you’re supposed to be innovative and we’re paying these PhDs these high salaries and there’s a lot of inflated expectations about AI and ML. Well, when you get these wins on the board here, the other thing that happens is that when you develop these relationships, when you have an idea for how you could help the business that’s not necessarily something they’ve planned, but say you’ve detected a pattern in the projects or a pattern in the data, and you’re like, “You know what? We could predict something from this.” Or, “We could build a model that would automate,” whatever, they’re going to be more likely to listen to ideas coming from you that did not originate with the business.

And I hear this a lot. A lot of the times, the business, they don’t know what they want, or at least they don’t know how to ask you for a good data science deliverable because they are not data scientists, they don’t know how it works and it does sound like magic a lot of the times, about what we do. This AI and ML stuff sounds like magic to people that don’t spend all day breathing the stuff that you and I are talking about right now. Okay? So, to get it out of that magic realm or to get them to actually listen to you, when you come in the door with some of this, quote, “Magic,” it’s having some wins to date that were based on, they had a problem, we got clarity around the problem, we understood what the success criteria was, we knew the outcome that they wanted to get.

And then we figured out the right solution to give to them, when you can help show that value and show that change for them, they’re going to listen. They’re going to be more inclined to say, you know, “So-and-so’s-team knows what they’re doing. Like, when they come to me with an idea, I’m ready to listen because they’ve hit some real home runs for me and my team in the past. So, I’m going to take that phone call and I’m going to listen to those ideas even if they’ve I don’t understand how it works or I don’t know what NLP is or I don’t know what—” whatever, I think they’re more likely to listen to you because you’ve built the foundations of our relationship, and you’ve delivered some wins for them.

A couple other just little side points here, I think you got to love the leaders and customers that don’t understand the logic of what seems so clear with data science and analytics work. Like, facts alone aren’t enough to motivate everybody; the status quo is often going to be your enemy. You got to learn to love the people that don’t—that l—it’s just, it sounds like why would they not want this? It’s so obvious that we should do this and yet they don’t. I think it’s learning to love these customers and understand, like, that’s actually a challenge for me to break through that. Why is there resistance? Is there a way we can reduce the resistance and position what we’re doing is valuable to them, not something that’s kind of against them or replacing them, but it’s providing value to them, frankly?

So, I think you got to learn to handle those customers and know that not everybody has the same thinking style that you may. If you’re very analytical, that’s not how everyone else may see the world. And simply understanding that your way of seeing the world is just not how everyone else does, it’s hard because it just seems so rational to us and when we’re surrounded by the community of people that think like us, it’s important to realize that’s not how it is for everyone else. So, how are you going to position these logical data product-type things with people that may make a lot of decisions with emotion, which a lot of us actually do, including probably you in ways that you haven’t really thought about? Not everything is going to be driven by the numbers, right?

So, this also kind of gets into—or it doesn’t get into; it’s just transitioning here to a different idea, but letting go of your identity, I want to reiterate that I think if your identity is really tied to, you know, academic work that you’ve done in statistics or math or data science or machine learning or whatever, you’ve spent a lot of time on that stuff, but if you want to move into this data product space, you may need to let go of your identity that’s really tied to this one thing, and understand my job is not necessarily to do all of that work now. Someone else may be doing that work. My job is to make sure that kind of work, which I know how to do even though if I’m not doing it, it’s to make sure that work actually gets surfaced and actually gets put into production and gets used. To me, someone needs to drive that ship, and if that’s you are furthering your identity in a way. Like if you’re like, “I know all this stuff about NLP, I know it can help my business,” even if you’re not the one doing the modeling and building the algorithms and all this kind of stuff, you might further NLP getting into production, making an impact in your business by being the machine learning product manager in your organization that helps to get this new way of doing things out into the business, into the world into the hands of people that it’s for. You are furthering the mission there, it’s just a different contribution that you’re giving.

Anyhow, overall, I think, if you can cross this divide from the technical to the business and to the language of customers, I think AI and machine learning product managers can really crush it, you’re going to be the ones that can crush it in terms of value creation with data. There’s just a lot of kind of buzzword talk out there about this platform is going to save the day and if only we were—you know, if we were just in the cloud, and this infrastructure was here, or we bought Snowflake or fill in the gap, whatever the current buzzword is, right, so much of the time it comes down to the people, right? And I think if you’re someone that can hold that technical conversation and hold the business in the domain language conversation and you understand both the users and how they may be different from the stakeholders that you’re serving, if you have all those perspectives and condense all of those dances together and know how to build the relationships, you’re going to really crush it in terms of pushing AI and machine learning out into the world. So, if that’s really what your passion is, that’s the work that has to happen, right?

Anyhow, that’s kind of my episode for today. If you’re struggling with this low adoption of data products, and you’d like to get some help, either for you, for your product, for your team, you can visit designingforanalytics.com/go. There, you’ll learn how I help mostly B2B technology leaders increase adoption of data products, primarily using the tools and approaches of software product management and design.

So, you know, whether you work with me or not know, my goal is that this show and my writing, and if you’re on my list, my goal is that I’m really helping you move from shipping data outputs to creating outcomes for people, users, stakeholders, affected third parties, that you’re making an impact and creating value with the work that you’re doing. It’s not just to be good, but to make things that are indispensable to these users and customers that you spend all this time hopefully working with and not working for. So anyhow, that’s it.

I do have some questions for you. I’d love to know what you think about my definition of data products so far. Is it wrong? Is it incomplete? Does it resonate? Please send me your feedback. I’d also—the second question for you—there’s only two—what’s the most challenging thing for you? If you are a data or AI machine learning product manager, what’s the most challenging thing for you right now? I’d love to hear, particularly if you’re from a non-digital enterprise, but I’m open to feedback to from, you know, the people in the tech sector that are listening to this as well. If you’re working on a startup business, or maybe you’re part of, you know, Amazon, or a giant company that has lots of established product, I’d love to hear, what’s the most challenging thing for you?

So again, those two questions: what did you think of my definition of data product? What’s your feedback on it? And secondly, what’s the most challenging thing that you’re dealing with right now as a data and AI product manager? To let me know, just email me, Brian—B-R-I-A-N—at designingforanalytics.com or you can go to designingforanalytics.com/podcast and you can actually record an audio comment right from your browser there. You don’t need to sign up for anything. I’ll get a message and I’ll listen to your response. So, you can make that anonymous too, if you want.

And that’s pretty much it. So, next episode, we’ll be back with interviews. We’re going to jump into have a conversation about innovation in the next episode. I’m really excited to talk to this guest. So, I hope you’re well. Stay good, stay cool, we’ll be back soon with more. Thanks for listening.