Today, I’m responding to a listener's question about what it takes to succeed as a data or AI product manager, especially if you’re coming from roles like design/BI/data visualization, data science/engineering, or traditional software product management. This reader correctly observed that most of my content “seems more targeted at senior leadership” — and had asked if I could address this more IC-oriented topic on the show. I’ll break down why technical chops alone aren’t enough, and how user-centered thinking, business impact, and outcome-focused mindsets are key to real success — and where each of these prior roles brings strengths and/or weaknesses. I’ll also get into the evolving nature of PM roles in the age of AI, and what I think the super-powered AI product manager will look like.

Highlights/ Skip to:

• Who can transition into an AI and data product management role? What does it take? (5:29)
• Software product managers moving into  AI product management (10:05)
• Designers moving into data/AI product management (13:32)
• Moving into the AI PM role from the engineering side (21:47)
• Why the challenge of user adoption and trust is often the blocker to the business value (29:56)
• Designing change management into AI/data products as a skill (31:26)
• The challenge of value creation vs. delivery work — and how incentives are aligned for ICs  (35:17)
• Quantifying the financial value of data and AI product work (40:23)

Quotes from Today's Episode

• “Who can transition into this type of role, and what is this role? I’m combining these two things. AI product management often seems closely tied to software companies that are primarily leveraging AI, or trying to, and therefore, they tend to utilize this AI product management role. I’m seeing less of that in internal data teams, where you tend to see data product management more, which, for me, feels like an umbrella term that may include traditional analytics work, data platforms, and often AI and machine learning. I’m going to frame this more in the AI space, primarily because I think AI tends to capture the end-to-end product than data product management does more frequently.” — Brian (2:55)
• “There are three disciplines I’m going to talk about moving into this role. Coming into AI and data PM from design and UX, coming into it from data engineering (or just broadly technical spaces), and then coming into it from software product management. I think software product management and moving into the AI product management - as long as you’re not someone that has two years of experience, and then 18 years of repeating the second year of experience over and over again - and you’ve had a robust product management background across some different types of products; you can show that the domain doesn’t necessarily stop you from producing value. I think you will have the easiest time moving into AI product management because you’ve shown that you can adapt across different industries.” - Brian (9:45)
• “Let’s talk about designers next. I’m going to include data visualization, user experience research, user experience design, product design, all those types of broad design, category roles. Moving into data and/or AI product management, first of all, you don’t see too many—I don’t hear about too many designers wanting to move into DPM roles, because oftentimes I don’t think there’s a lot of heavy UI and UX all the time in that space. Or at least the teams that are doing that work feel that’s somebody else’s job because they’re not doing end-to-end product thinking the way I talk about it, so therefore, a lot of times they don’t see the application, the user experience, the human adoption, the change management, they’re just not looking at the world that way, even though I think they should be.” - Brian (13:32)
• “Coming at this from the data and engineering side, this is the classic track for data product management. At least that is the way I tend to see it. I believe most companies prefer to develop this role in-house. My biggest concern is that you end up with job title changes, but not necessarily the benefits that are supposed to come with this. I do like learning by doing, but having a coach and someone senior who can coach your other PMs is important because there’s a lot of information that you won’t necessarily get in a class or a course. It’s going to come from experience doing the work.” - Brian (22:26)
• “This value piece is the most important thing, and I want to focus on that. This is something I frequently discuss in my training seminar: how do we attach financial value to the work we’re doing? This is both art and science, but it’s a language that anyone in a product management role needs to be comfortable with. If you’re finding it very hard to figure out how your data product contributes financial value because it’s based on this waterfalling of “We own the model, and it’s deployed on a platform.” The platform then powers these other things, which in turn power an application. How do we determine the value of our tool? These things are challenging, and if it’s challenging for you, guess how hard it will be for stakeholders downstream if you haven’t had the practice and the skills required to understand how to estimate value, both before we build something as well as after?” - Brian (31:51)
• “If you don’t want to spend your time getting to know how your business makes money or creates value, then [AI and data product management work] is not for you. It’s just not. I would stay doing what you’re doing already or find a different thing because a lot of your time is going to be spent “managing up” for half the time, and then managing the product stuff “down.” Then, sitting in this middle layer, trying to explain to the business what’s going to come out and what the impact is going to be, in language that they care about and understand. You can't be talking about models, model accuracy, data pipelines, and all that stuff. They’re not going to care about any of that. - Brian (34:08)

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I’m going to chat with you about my vision for what a data and AI product manager should look like. This is actually in response to a reader’s question.

I had someone on the mailing list—as most of you know, I have an insights mailing list. I publish every other Tuesday between these podcast episode drops, sometimes a little more frequently—and this reader was in a career change, you know, not a drastic one, but was particularly thinking about moving, I believe it was out of design and business intelligence, data visualization type role, and curious about possibly exploring data product management. And he had mentioned that he perceived most of my content was for people that are already in management and executive leadership positions, and he was wondering if I had ever done an episode about stepping into this type of role with less experience, not coming from product management, or not having been doing it for a while. So, I thought that was probably worth stepping into, whether that’s you or you have a team and you’re thinking about hiring in this space. I thought I would give you my very opinionated take on this, about what I hope to see as a product person working in this space, like, if I was to work with somebody, what the skills are, and really the mindset that I would hope that that they would have in the work that they’re doing.

And as with almost everything on this podcast, I’m coming at this whole thing from very much a business and user experience perspective, and not from a technical perspective. And I’m going to talk a little bit about the technology side here, the requirements and that piece of it, but I believe there’s plenty of content out there about this, and most of the people listening to show probably already have most of that knowledge. I know we have listeners here coming from more of the software product management as well as user experience design, so I’m going to talk about those transitions, like, if you’re moving across those roles, maybe what some of the biases are, and things to watch out for, and all of that as well. So, let’s talk about that. Maybe we should talk about that first.

So, who can transition into this type of role, and what is this role? So, I’m kind of putting these two things together. AI product management often, in my perspective, seems to be very much attached to software companies that are primarily leveraging AI or trying to and so they tend to use this AI product management role. I’m seeing less of that in the internal data teams where you tend to see data product management more, which, for me, feels more like an umbrella term that may include traditional analytics work, data platforms, often, AI and machine learning, that type of thing. I’m probably going to talk more—I’m going to frame this more in the AI space, primarily because I think AI tends to more frequently capture the end-to-end product than data product management does.

And the reason I say that is because data product management and data products in general have many different definitions, as we’ve talked about on the show many times. Data product management can still very much mean basically building reusable data assets, data platforms, things that require further refinement before they are leveraged into actual applications and tools that provide end-to-end value. And that’s not what I tend to see the gold standard for the role. I know those people exist, and I’m not saying that you may not need someone managing a data platform, for example, but in my vision and opinion of the world, if your whole existence is to provide the platform only, and you’re not responsible for the actual value that’s going to be leveraged out of the platform, then there’s kind of a gap there. And I realize another PM might have responsibility for that, but I kind of have this just purist mindset about it, I guess, and I think there’s just so much work happening that happens in these isolated buckets where one person owns this piece of infrastructure, and another person owns this piece of infrastructure, and this person owns the model and the math—you know, as the Brits would say, the maths behind it, and then yet another person is supposed to refine that into something, and on and on and on, and we end up just with a lot of cost and not a lot of value a lot of the time, so I’m going to still paint this picture as I think it should be painted. So, keep that in mind here.

So, who can transition into an AI and data product management role? What I tend to see the most is the data product management role tends to exist mostly in the internal data crowd space. So, this is for data teams that are trying to leverage, usually working in large enterprises, and trying to turn that data into new forms of value. I see that less in the software company area. That’s where I tend to see the AI product management roles, et cetera.

Regardless of where you see it, I would also say that I tend to see more grooming of these people from different roles internally. Particularly on the enterprise data side, it’s going to usually be someone that already was working with a data team that has been groomed into, or at least retitled into a data product management, then they seem to throw training at them, and they try to work with someone that they already have and turn them into this role. So, it’s kind of like change the job title, add new skills, and then I think hope that they will grow into this role and start operating the producty way, whatever that means inside of that organization. On the AI PM side, I think, while there’s a lot of people, I think trying to jump into this space because they see it as being a hot place to be, I think where you’re going to probably see more successful people is tends to be someone that’s come out of a traditional software product management role. They understand product already, and they’re really focusing now on AI specifically in their product work.

So, who can transition here? I tend to have a very open view that anybody can transition into just about any role if you’re willing to do the work and make the changes required to do that work, and you’re willing—possibly—to have to step back to do pro bono work, for example, to build a portfolio or to do something that can show the results that you know what you’re doing. And there will always be plenty of jobs out there that just list raw technical skills. I’m still hearing this all the time, even at the chief data officer level—and Kyle Winterbottom talks about this quite a bit—about how a lot of companies, they keep hiring for the wrong stuff. They all want to have the same value coming out of their chief data officer, but then when you look at the job descriptions, the company clearly doesn’t know how to hire for the role.

I think the same thing. I don’t sit and look at job descriptions regularly because I’m not in that space, but when I do see them, I often will see largely technical requirements for these types of roles, and it tells me that the company really doesn’t understand what product—and this is more true, again, in the enterprise data space—the company really doesn’t understand software product management and this idea of leveraging how to do that work internally against their internal data products. They really don’t get the joke, so to speak. And that’s probably understandable if they’ve never had this role there. I think they’re trying to get all the benefits because they hear that a lot of people are working this way, and they want to get those benefits, or maybe one of the big four firms told them that this is the way you should be doing stuff, and so they’re trying to bring people in.

And I still applaud that work. Even if they’re not sure, they’re taking the first step and they’re saying, “Hey, we’re not quite sure what this looks like, but we’re trying to move this direction.” So, I think that’s okay. So, who can move into that? Well, again, I think the reality is that, on the enterprise side, they’re looking for people that have come out of data roles. So, if you haven’t come out of a data-related role, it may be harder to get a position in that space unless you have a very compelling portfolio or resume that shows results doing this work. And you might have to go out and do some projects or work on some products or do some pro bono work to build something that will show the benefits that you have created for users or for an organization in order to step into that type of role.

There’s three disciplines I’m going to kind of talk about moving into this role. So, coming into AI and data PM, from design and UX, coming into it from data engineering, or just broadly technical spaces, and then coming into it from software product management. I think software product management and moving into the AI product management, as long as you’re not someone that has 20 years of experience, and you really have two years of experience, and then 18 years, repeating the second year of experience over and over again, if you’ve actually really had a robust product management background across some different types of products, and you can show that the domain doesn’t necessarily stop you from producing value, I think you will have the easiest time, probably, moving into AI product management because you’ve shown that you can adapt across different industries or whatever it may be. And it also shows that, you know, arguably, what I think is probably the trickiest space, which is not the technology, it’s all of the glue work that product managers need to do with relationship building, navigating politics, especially when you get into larger organizations, understanding how to talk to sales and marketing, if that’s more on the commercial side. But really this idea of you have all these different stakeholders, you may have all these competing different needs, and deciding what gets love from your design and engineering and data science teams, that’s often where the hard work is because delivery work is getting easier and easier today, ironically because of AI.

So, the deciding what to do is hardest and PMs that have been doing that kind of difficult work, I just think you’ve got most of the skill sets that are more beneficial. As long as you’re open to realizing that, particularly in the AI side, we’re in a new time. And I think that there’s a—this is for the web, if you’ve been through all the different stages of the web, like I have, it’s kind of like these big forks in the road. It’s like, Web 2.0 came out. It’s like, are you going to keep doing the old thing or are you going to adopt to social.

And then I remember when, like, AJAX came out, and you finally had dynamic web interfaces where you could pull data without refreshing the entire screen, and it’s like, basically, you had desktop-type software experiences that could finally come into the browser. Are you going to keep doing it the old way, or are you going to start thinking more like we now have a platform to just build software right in the browser? Right or left? Which way will you go? You can kind of keep going down this road and having these forks there.

And I think if you’ve kept understanding when you’re at a fork and then making the correct turn at the fork, going right or going left—if left means keep going to doing the same thing; right means, hey, I’m going to go down this road because it seems like that’s where things are going—I kind of see this, all of what’s happening with GenAI as one of these forks in the road. So, you can either embrace it, or you can kind of keep doing what you did yesterday. But back to these roles here. So, product management probably has the easiest time here. They’re going to need to obviously, really understand more of the tooling, but I feel like it’s so much easier now to get a grasp on all of this tooling, to understand what’s possible out there. It’s never been easier to actually catch up with this stuff, the amount of content that’s available, using AI to ramp up on these skills. There’s just, there’s a lot here. So, that’s my take. Let’s just move into—these aren’t necessarily ranked, but I think that that one has the easiest time.

Let’s talk about designers next. I’m going to include data visualization, user experience research, user experience design, product design, all those types of broad design, category roles. So, moving into data and/or AI product management, first of all, you don’t see too many—I don’t hear about too many designers wanting to move into DPM roles because oftentimes, I don’t think there’s a lot of heavy UI and UX all the time in that space, or at least the teams that are doing that work feel that’s somebody else’s job because they’re not really doing end-to-end product thinking the way I talk about it, so therefore, a lot of times they don’t see the application, the user experience, the human adoption, the change management, they’re just not looking at the world that way, even though I think they should be. So, I think designers and user experience people could definitely bring value into this role, but I’m not convinced that most people hiring for this role will understand that mapping, so they probably will not see the value that you can bring into the role unless you can translate your work into results that directly address the challenges that the hiring company thinks they have. So, even though you might think you have the skill set to bear that’s going to help them, they have to perceive that as actually mapping on to their problem space, and if you’re using different jargon and lingo to talk about this, I just don’t think a lot of data and AI PM roles are going to be able to map that work onto what they perceive as being valuable for the role.

So, I think maybe this group will have the hardest time moving into this. The exception for this would probably be more in the software AI product management space. If you have been a true product designer, which for me, means you’re really looking at both user experience and the human part as well as the business, and so your design work has always been balancing the two of these, and you’ve been, really, a true counterpart to a product triad, or however your product groups were made, and that really means to me, you’re almost like—you and your product management counterparts are essentially almost equals. It’s like multiple brains all forming into one product brain, and that’s how you’ve been operating, as opposed to, I’m waiting for a product manager to give me a list of work to go deliver against. If you’re the former, I think you have a chance in this space, particularly if you’ve been working on heavy data applications, analytics applications, AI things, and you’re able to talk that language, and you’re able to attach business value to the work that you’ve done and show that, I think you have more of a chance here, but I think your uphill battle is going to be your perceived lack of technical skill here and not being able to interface properly with data science and engineering people in this space.

And there’s a lot of technical things to know about in this space. And the technical teams are also struggling with this. I mean, I was just talking to one of our data product management members the other day—one of our founding members, actually—on one of our monthly team times—so we have these—every month, we have TEA(M)—T-E-A parentheses M—thank you to [Marnix 00:17:02] for adding the M, what used to be called TEA time; now it’s TEAM time—but we have these, like, monthly no agenda meetup opportunities online, where it’s just a social time for 30 minutes, drop in and it’s just a chance for us to stay in touch with each other. And so, I was catching up with this leader, and she was telling me that, you know, one of the challenges with the—they’re deploying a GenAI-based feature into—this is an accounting-related software product, and they were launching a GenAI feature in there, and just this idea that how one small change with, like, a pipeline or something that may seem trivial, can have a downstream effect—or even an unknown effect—on what the model is generating. In this experience, it was a chat, conversational-type interface inside of the product that allowed you to do some, you know, some different tasks inside the product through conversational interface.

And even the data teams are struggling with this because it’s not always clear why this small change here is having this downstream impact. So, given that data and engineering teams are having this challenge already, if you’re coming from design and you’ve really not fully embraced the technology part of doing product work, and you’ve kind of, I mean, frankly, had your head in the sand, or you’ve been part of that camp that says, “Designers shouldn’t code. That’s not our job. We don’t need to know about this, and I want to stay creative because I was hired to be creative, and if I know more about how to build the products, then therefore, I will not be as creative,” I am, just so not part of that camp. I think that argument died 10 or 15 years ago. I know some people still have it.

I’m very much of the camp, if you’re a designer, you need to know your medium, whether it’s brushes because you’re a painter, or, you know, if you’re a sculptor, to know the types of material that you’re working with, and if you’re doing software-related work, whether it’s AI software or not, you need to know how to code. At a basic level, you need to understand how APIs work, you need to understand how models work, and if you don’t have these skills and you don’t want to gain them, I think operating in this role is going to be very difficult for you. It doesn’t mean you should be spending your time doing coding and all this, or even doing code reviews or any of that, but you’re going to be spending a lot of time, particularly with GenAI, on figuring out how to drive quality, where quality—you’ll understand what user experience outcomes look like, and what quality looks like there, but there’s also the business side, and then there’s the whole probabilistic side here, where this isn’t just a matter of defining all the states that need to be managed within these applications and making sure that we’re handling all those gracefully. That’s no longer the world we’re operating in. So, you’re going to have this skill.

And I feel like a lot of user experience professionals out there don’t have this. This is still, like, a special 25%. I mean, again, these are all just my perceptions about what’s out there, but finding very technical designers, and I mean designers that understand the tech that can hack together their own—whether it’s vibe coding or low-code, no-code, solutions, they just have a technical mindset. They have a builder, hacker mindset. They want to prototype their own solutions.

They’re willing to get in the weeds to understand how things work, just enough such that they can be more productive as a designer or a product manager. I think it’s a rare skill, and a lot of UX people just don’t have it, or they’re not working on it, frankly. So, you’re going to need to really understand this space. I would probably be taking training on this if I was in that kind of role and I didn’t have these skills. Personally, I like to learn by doing, and then I’ll dive into training or learning through the process of doing something.

So, I’ll build my own application when I get stuck, then I’ll try to go learn about something conceptually, but also through the practice of doing. That’s more my style of liking to learn. But I think an uphill challenge here, unless you really can show what you’ve done here, you’ve done some volunteer work or something to, again, have your portfolio represent that you could actually manage a technical team. Even if you’re not directly managing the engineering and the data science and machine learning engineers and data engineers and all of this, you’re just going to be spending a lot of time doing that, and not a lot of time in the UI and the UX space. So, that’s my take for the designers out there.

Let’s talk about now maybe the largest, I’m guessing, the largest part of this audience. And it’s always funny, after all these years, you still don’t know exactly who’s listening to this show, except when you all write into me, or if you join the mailing list and you say, “Hey, that’s how I heard you,” or you shoot me a message on LinkedIn. I always appreciate getting those that actually, whether it’s a compliment or just a chain, like, I’d like to hear more of this kind of content. All that stuff is super welcome. I also just it’s really helpful for me when you drop me a line because it lets me know, like, oh, who’s this person? What kind of company are they at? What kind of role do you have? It tells me who’s listening to the show and it’s really helpful, so I always enjoy getting those.

But anyhow, so let’s talk about coming at this from the data and engineering side. This is the classic track for data product management the way I tend to see it. I think most companies want to groom this role in-house. My biggest concern there is that you end up with job title changes and not necessarily the benefits that are supposed to come from this. I do like learning by doing, but you know, and you’ll see—like, Marty Kagan talks about this a lot, this idea of, like, having a coach and having someone senior in there who can coach your other PMs, particularly because there’s all this stuff that you’re not necessarily going to get in a class or a course; it’s going to come from experience doing the work.

Because this work is not delivery work. It’s not a technical work where here’s a challenge, it’s technical and there’s a puzzle to fill, and generally, there’s a right answer. There might be a few different right answers, but there will be this moment where you crack the code and—maybe literally crack the code—and then you’ll get through that gate, and you’ll be on to the next thing. I don’t think most product management feels like that. Product management just feels like this ongoing thing that never ends. You’re placing bets all the time. A lot of times they have longer horizons. It can take a while to get feedback on it.

It’s a very different space, and so I’m really curious to see what’s going to happen with the teams that are trying to implement this, that are only doing this through grooming and light training, especially if they’re primarily taking training on things like project management and Agile training, and like, using product management software and kind of all the hard skills stuff. That’s pretty easy to get trained on and to, kind of, act the part. Creating the actual value, though, this is really why are we doing all this? Well, the product manager is supposed to be the buck stops here on delivering benefits. That’s really what this job is about, is not creating the outputs and being a project manager for all the technical work that’s going to happen.

And this is often what happens when you—even PM, I hear people sometimes interchange the word project manager and product manager and those are entirely different things to me. The project manager often is not in charge of whether or not this project even makes sense and whether this project is going to produce value; their job is to manage the assigned project that was given to them. And I am not saying that that’s not important, but if you’re spending all your time doing project management, you’re probably not a product manager as the next company that’s going to hire you is going to see it because that’s not what this role is about. Most of the time, if there’s been executive support for hiring product managers, the assumption is that this is the role that’s going to make sure all this technical work and all the design and user experience work, all the delivery work, is going to roll up, and it’s going to produce value for the company. Change will happen based on your decisions about what we should do.

And if you can’t do that work, or you’re not associating your work with benefits delivery, outcome delivery, I think there’s a huge gap here. And frankly, I’m really concerned about data teams and when people come out of data and engineering teams into this role, and they haven’t had the support on all of the non-technical aspects here, and instead, they’re kind of looked as, like, a technical lead now, who’s going to manage all the parts and then the delivery of some output at some point, but with a new title. That’s a tough space to be in because I always wonder, hmm, upstairs, somebody probably sold this transition to doing data products, and maybe they sold this idea that we’re going to have these teams, and these product managers are going to own the value delivery, and then they’re going to have their technical counterparts working, kind of, with them or under them—whatever, however the management structure looks—but they’re not actually enabled yet to really produce this value. They don’t have the high-level support that they’re going to need to deal with all the social, the political aspects inside the company, all the blockers to getting access to customers and perceptions that you’re really a cost center, you’re a delivery team, just give me what I asked for.

All that stuff there, it’s an uphill battle because you don’t have the skills you may not have the executive support for that role. I think it’s a tough place to be. Obviously, you’re going to have this super-strong asset on your side, which is, you’re going to understand all the data parts and the data science aspects and the engineering. You’re probably going to be very well wired and positioned to understand how to predict where there’s going to be potholes and obstacles on the way, model quality and drift and all the things that business is going to need to look out for, you’re going to have a much better sense of that than anyone else, and that’s really great. I mean those skills are highly valuable.

But it’s really transitioning into the change management piece and making sure that you understand, well, what does it mean to ship a small increment of value? And we often talk about, well, we got to build these models first, or build all this plumbing and all this, and it tends to be these giant monolithic projects all the time, and that’s not really part of what a product person’s mindset should be. A product person’s mindset really, in my opinion, should be about how regularly and quickly can we deploy a hypothesis into production, get feedback, learn from it if it didn’t work. If we did create some value, how do we double down on that and continue to create value whether it’s for the customer and the end-user or for the stakeholder, or ideally both, since really the role of any PM is user experience outcomes and business outcomes. It needs to be both of those things, and sometimes those are at odds.

So, lots of benefits if you have a data and engineering background moving into this role, but all of this soft stuff that I’m talking about, all the politics management, frankly, knowing about design, user experience, change management, user adoption, resistance. We’re hearing all this again about resistance to adopting these tools, there’s people that feel threatened by these solutions, and if you’re brushing all that off as, like, well, you’re just behind the times and this and that, you’re going to end up with technically right, effectively wrong solutions. The same thing again, it’s just your job title might be different, but if you keep doing yesterday’s work with a new title, I wouldn’t expect any new results as a result of that. You’re really going to need to study up on those skills such that the technical work your team that you’re now managing and not necessarily doing the delivery and coding work and the model building and all of that, you need to really start thinking about what is the human and cultural change that’s going to be required to get this thing adopted, particularly if the solution is perceived as being disruptive and not necessarily something that people were asking for. They’re eager to get their hands-on, the human dynamics here are really important to understand.

As most of you know, I tend to see this challenge of user adoption is often the blocker to the business value, particularly—I mean, this is really true for commercial and internal data products, but if you don’t have human adoption of the work, of the applications, the tools, however, your solutions manifest themselves, if users don’t care, they don’t like it, they can’t use it, they don’t trust it, it kind of doesn’t matter. You’ve just been doing basically R&D work and cost center work. Your bet did not pay off. And so, how do we make sure the last mile isn’t where all this great technical work died? And so, this is what my training tends to be focused on, you know, my Designing Human-Centered Data Products course and the seminar, the training that I do with private teams, these are evergreen skills that I think anyone in a data or AI product management job needs to have if you want your work to create value.

I don’t think of my training as being specifically for, like, end-to-end here’s how to become an AI or data product manager; I’m focused really on the blockers to adoption, the change management being built into the process of building these solutions, so it’s not something that happens downstream by yet another part of the organization who tries to force some new solution down people’s throats against their will. I don’t think that’s how great data products are built. I think we try to design the change management into the solutions. So, my training is really focused in that particular space of all these non-technical skills that are required. So, it’s really oriented for, you know, people in data engineering and/or product management trying to move into the data product space, and they’re struggling with that, the value piece, the adoption piece and all of that.

So, this value piece is probably the most important thing, and I want to focus on that. You know, this is something I talk about in my training in the seminar quite frequently is, how do we attach financial value to the work that we’re doing? And this is both art and science, but it’s very much a language that anyone in a product management role needs to be comfortable with doing. And if you’re finding it very hard to figure out how your data product contributes financial value because it’s based on this, like, waterfalling of well, we own the model, and it’s deployed on a platform. The platform then powers these other things, which then power an application, and how do we figure out the value of our tool? Yeah, these things are challenging.

And if it’s challenging for you, guess how hard it will be for stakeholders downstream, if you haven’t had the practice and the skills required to understand how to estimate value, both before we build something as well as after? And this gets into being able to define success metrics, both progress metrics and success metrics for your initiatives. So, I spend a lot of time on this when I’m doing coaching and training, both individuals coaching as well as in the seminar, is really thinking about the metrics that we will use for this. And I’m not talking about analytics necessarily. Most of the time, analytics, which are computer-based metrics, those are not the way projects or increments of product work can be measured a lot of the time.

Or they’re the wrong stats, like, things like how many people used the data product, and we can track that. Unfortunately, what you’re doing is tracking product metrics. You’re tracking metrics about the tool that you created, and this is used as a proxy for actual value created. And that’s not actually telling you anything about whether or not benefits were created for somebody or not, let alone the financial value there. I don’t want to get rat-holed too far into this, but this value topic in general, if you don’t want to spend your time talking business language and you want to be either in the design space, the model-building space, the engineering space and all of that, then this role is not for you.

If the dollars and pounds, or whatever currency you use, if this is not language that you want, you don’t want to spend your time getting to know how your business makes money, frankly, then this work is not for you. It’s just not. I would stay doing what you’re doing already or find a different thing because a lot of your time is going to be spent managing up for half the time, and then managing the product stuff down, and sitting in this middle layer, trying to explain to the business what’s going to come out and what’s the impact going to be, in language that they care about and understand. You cannot be talking about models and model accuracy and data pipelines and all this stuff. They’re not going to care about any of that; they’re just going to see AI is really cool. It’s magic sauce. When are we going to get some of that value? What’s going on with this product that we’re supposed to be rolling out, or this feature we’re rolling out, or whatever it may be?

That’s the operating model when you’re managing up as a data or AI product manager: when are we going to see some value here, as we define what value is? So, you need to have this skill set here, and broadly speaking, across all of these roles, thinking about transitioning into data and AI product management. The most common thing that I see, like when I do training and if I have individual contributor type roles in my training, is that, frankly, they don’t have any incentive to focus on this. They were primarily hired to do technical delivery work most of the time, and so the mindset and attitude is that, well, my job, that’s someone else’s responsibility to make sure that we’re actually building the right thing. And I think if you—there’s nothing wrong with that, if that’s the kind of work you want to do.

And I think most people kind of inherently know, do I want to take the responsibility for value creation, or do I want someone else to do that, and I want to kind of help them realize their vision, but ultimately, I’m following them? To me, product managers need to have a little of that CEO-ness inside of them. They need to be leaders, and all you need to be a leader is to have followers, but you need to be a leader that people want to follow. And you need to champion this more than anybody on the team does. And a lot of ICs simply don’t have this skill because they haven’t been required to focus on value.

They haven’t had any incentive to focus on value. Financial incentive, whether it’s bonus structures or things like this. It’s kind of like you get paid the same whether or not the solutions work or not. So, if you’re going to move someone into a data and AI PM role with an expectation of value creation, but there’s no incentive set up for that, I think you should be really thinking about whether or not simply changing job titles and descriptions is going to work and actually create the value inside your organization. So, they need to have the desire to start thinking about benefits and outcomes—which is, kind of, synonyms for value here—they need to be enabled to spend the time on that. They’re going to need to develop skills in this space.

But most ICs don’t have them, and most of the time they don’t want to have them, in my experience. I tend to feel like I can assess this pretty fast. And it’s really someone that wants to move up a career ladder. If someone really wants to move up the career ladder inside an organization, you have to start thinking about value and less about outputs delivery. And it’s very clear, oftentimes, who these people are.

And I think if someone’s hungry to do that work, eager to do that work, that’s probably the most important skill, assuming that they have a modicum of intelligence, and you can assess that intelligence, that desire to do this work and to step into that space, again, I like to believe that, especially for adult learners, your desire to learn and willingness to change how you do your work, that’s the most important thing to have. There are people that do not believe this. I [laugh] thinking of one of our members in the DPLC, who’s a chief data officer. He has very different opinions about who can step into this role, and he doesn’t believe that all these job titles, people that are coming out of these different tracks, technical, design, or existing product management, that all people are created equal in this space. So, I just want to share that not everybody believes that all these skills are equal.

And this is casting a broad generalization. I’m not saying this person says, “If you have this job title, you’ll never be able to do this work.” That was not—I don’t think that’s the message this person was sharing in one of our DPLC monthly webinars that we had in the community, but it was more the evidence has shown, in his experience, that certain types of personalities, roles, skill sets, tend to be more oriented for moving into this track than others. So, for what it’s worth, just know there’s different opinions, and I’m just sharing my opinion, which is largely based on just my exposure time and also my vision that I—my agenda.

I have an agenda. I am very much trying to influence how you do your work. I am pushing you as a listener, and these teams, to build stuff that matters and to stop making more outputs. We don’t need more technology crud out in the world—I’m not talking about Create, Read, Update, Delete, for you engineers, when I said ‘crud’—I just think we have so much skill here. We have limited time on the planet. Work is a big part of a lot of people’s lives, in terms of minutes spent in your life. Let’s make that life—let’s put out meaningful stuff into the world.

So, let’s design for human impact benefits for end-users. Let’s make better software, better empowerment. Let’s leverage AI for the benefits of people. And also, we need to feed the beast for tomorrow. So, we need to create financial value for the company as well. But I do have an agenda, so I just want you to know that. Take that with a grain of salt, this whole episode.

But anyhow, so this whole value space here, you got to live in this space. You got to want to live in this space. And ICs—Individual Contributors; sorry if that term is not used in your country. It means individual contributors, non-management function—if you’re not thinking this way, and you don’t want to think this way, you’re probably dead in the water trying to get a role like this because you really need to step into that. And frankly, you might be coming into a space where the hiring people know that this is important, but they don’t know exactly how a data product manager and AI product manager attaches the financial value to their work.

They’re kind of learning, too. They’re kind of switching into this product way of working—and now I’m talking back again to the internal enterprise data teams here—they’re moving into the data product space, and for them, that means something to do with adopting software product management life cycle, the way of working, the way of design, tech, and product coming together to deliver value. They don’t know exactly what that looks like, and they don’t know exactly how we move into a more outcome orientation. So, even the hiring team may not fully see it and know how to do it, which might be why they’re hiring for this role in the first place. So, you really need to have a compelling vision and be able to express that if you want to move into this role, particularly from the outside.

I think there’s less pressure to do this from the inside, if you’re transitioning into this role from an existing data role, and they’ve kind of—hey, you know, John or Jane, please step into this role. You know, we’d like to make you a data product management. Are you interested in this course? We need someone—you seem to be able to talk to the business. You seem to know how to connect with, you know, our designers and talk to customers and all of this, and so they feel like you’re this, like, natural fit there. But they may not have some of these value-estimating skills and figuring out how to attach financial value to the problem space.

So, develop that skillset. Do some pro bono work, do some project work if you don’t have it, but figure out how to attach the benefits and the value to the work that you’ve done, such that somebody can see it, and they can understand how your work contributed some form of value to the organization that you were helping. They really need to be able to see that, otherwise, you’re just going to be showing them all the mechanics of product management, which might get you a job in some places. To me, you can go through all the rituals and all of that and not create any value, and that’s not what product is about. It’s really this outcomes versus outputs mentality and being able to show that.

And on that, you know, just a final comment on this outcomes-outputs thing. I really want to just keep pushing this idea down because I don’t see this all the time. For teams that do understand the financial value they’re trying to attach to their data product work, they’re still often not talking at all about user experience outcomes, and they’re not connecting the dots that you can keep talking about how your model is going to drive this business lift, for example, or something like that, but if there are humans in the loop here that have not been part of the solution that we’re building here, or we’re building a tool and hoping that the staff is going to—you know, you’re building your AI conversational agent, or whatever it may be, inside the business, and you don’t know what an improvement to the end-user’s life looks like, then you’re only doing half the work because that’s where your roadblock is going to be to get to the estimated value that you’ve been talking about. And so, broadly speaking, the user adoption piece, which is tied to the user experience piece, this is often still a big skill-gap area, but you will hear people talk about this in terms of low adoption. This is what I would call the presenting problem that I hear about in the industry, but a lot of teams do not associate the practice of product design, as an antidote to that.

So, I think this is a skill that you really need to have, and frankly, I kind of think that the direction with AI product management is going to be hybrid PMs and designers. There will be fewer and fewer specific design-only roles here as we build more applications that have less reliance on heavy user interfaces. The really powerful players, the powerful product managers out there are going to be these hybrid people that understand the tech, they understand user experience, and they understand the business side of PM, and they can bring all these skills to bear. So, I’m probably very biased because, you know, I’m a designer, and I come out of that space, and so I tend to think design skills can help almost anybody in anything, and that’s probably a bias that maybe isn’t always true. But I haven’t seen it yet where not having that skill doesn’t make a product manager much better, whether it’s because they now understand the skill gap they have and they know that they need help, so they’re problem aware, or they’re just literally enabled themselves because they’ve had training and they know what to look for when it comes to design and user experience problems, they know how to address those problems themselves, particularly in an AI context because they’ve had training in it, they’ve developed skills in this space, and I really think that’s, like, the future.

If you want to be the top 10% of people in this role, it’s going to be having all three of those skill sets: the business PM side, the enough technical knowledge to prototype rapidly, to understand how to talk to data, the data science and engineering counterparts, and to understand that user experience and adoption really matters, particularly in a probabilistic environment where we cannot control everything that people are going to do and what the models are going to generate over time within our applications. So, the last thing here I’m just going to say to, kind of, wrap up this episode, is that delivery work is getting faster. Coding is getting easier. This is the highest use of generative AI right now is for software engineering, so—and I’m not talking about software engineering today, but my point here is that all these tools right now are enabling us to build stuff faster.

It doesn’t necessarily mean we’re making better things, so if you can connect the dot—if you can leverage all the speed gains we’re getting, and figure out that probably what you need to be doing is prototyping sooner, have a hypothesis, get a working solution out into a user’s hands, and getting feedback quickly, and then tracking whether or not your progress metrics are being met, if you can do that, you’re going to be in a great place. Because as delivery work gets faster, the most important part of this role is deciding what should we actually make. Making it will be fast, but there’s a thousand different things we could make. What’s the right thing to make? And that’s often rooted in your customer exposure time, your understanding of the problem space, you’re understanding the change in adoption, your understanding of how easily can we attach any actual, quantifiable business value to this thing? That’s where the time is now going to be spent. It’s not going to be spent on these giant, long delivery cycles. The delivery cycles will be much faster. So, this means placing more bets, running more hypothesis more quickly, and hopefully reacting to that feedback sooner.

So, the other thing I’ll just say here is also in the agent space, is really understanding and thinking about agents almost as—and this isn’t my [idea 00:48:23]; I saw someone talk about this. I can’t remember who it was about thinking about agents, designing for machines as almost another class of end-users to making your services available to machines. I think this is another skill set that, like, data and AI PMs, need to have here. So, not just our human end-users, but also, how do we make our solution useful in an AI ecosystem when we’re in the middle of deployment? Because oftentimes, we probably have a very practical reason we’re building this product to serve a specific class of problems that we’re trying to address, but I think thinking ahead also to how could other machines and agents leverage this work that we’re doing now, this is another skill—particularly for the AI product manager, obviously—that I think is going to be important going forward.

So, that’s it. That’s all I got for you today. I hope this was helpful to you. If you are looking for training and/or coaching help. I am considering relaunching a group coaching offering here. So, if you hop over to my list, you can get on that from designingforanalytics.com/podcast. You should get a welcome email when you get that, when you join the list there, and you could just reply to that and tell me if you’re interested, and I can give you some more information about that. So, for now, that’s all. Thank you for listening, and we’ll see you soon.