AA110 - Project Manager to Product Manager

We've done a podcast on, product owner to product manager. We've done a podcast on the different ways you break into product management, including having no experience at all, but , one of the pathways, which , in my experience, it's one of the minor pathways in that I've seen rather than unusual, yeah. I haven't encountered too many people, is project managers turned product managers or product owners, I guess If this was your career path into product management comment and let us know. And we're very interested in talking to you double, double points if you live in the Tampa area, right? Cuz you're invited to the podcast. That's right. That's right. Here we are arguing Agile again Brian Orlando, product manager Om Patel. Enterprise Agility coach. I say a different title for you every single time. I like it. All right Om Patel emperor of the Moon. Enterprise Sous Chef. That's right. Enterprise Sous Chef. Enterprise Saucier. Hey, as long as it's French, it sounds good let's talk through a project manager moving into product management. So, I h Have some concerns on this episode right off the bat. You have some concerns. I certainly do. I would be concerned with any candidate who is a project manager because I, , maybe you can talk me out of this, but I see it as a different mindset. That's better. Yeah. It is a different mindset. I, I can speak because I have served time as a project manager in the past. Mm-hmm it is a different mindset to come to product from a project management background because, Project managers primarily are concerned with getting things done on time. Come what may! That that's their, that's their mandate usually whereas get, get all the things done. Get 'em all done on time. Get 'em done on time, get everything done. And it doesn't matter. Under budget, under budget and on time. Yeah, that's right. Under budget on time. I know how to talk to get your bonus. I know how to talk to project managers. It's on time and it's under budget. Go away. Exactly. And when it's not, you have a bunch of risks and mitigations to kind of excuse yourself out of that the mindset for product really centers around the customer, which is not even in the picture for project managers usually. I, I don't know of many project managers that even speak to actual customers, the end users. Yeah, yeah, yeah they don't. Obviously this is, this is part and parcel of working in an agile way, but they don't have frequent touchpoints with the customer, so they don't get feedback, on the contrary, what they focus on is getting all the requirements up front. We often call BRUF big requirements up front. Yeah. And get 'em signed off in blood, and then the minute the customer says, wait, I know I said that. Hit 'em with a change request. Yeah. Hit 'em with a change request. Jump up and down. That's right. Yeah. Yep. Cr, CR one, CR two. That's right. Needs money. It's a D. Different mindset. Needs money. Need the money. Yeah. Change all my deliverables. Listen, some organizations incent people and reward people based on receivables. Right? So more change requests, the better and so in that kind of an environment, the project manager's going to be focused on adhering to those in those big requirements documents that were signed off. One of the reasons this is so relevant is our, we did a podcast on contracts and that, like the agile principle that basically nobody, none of y'all out there are. On the internet? I could make guesses as Covered so much in the air, but the, customer collaboration over contract negotiation. This falls in that same category. You have somebody who's used to using the contract to beat people over the head with it, and now we're saying, don't do that anymore. So that, that is a heck of a gear shift. Well, that's a complete 180. Especially in organizations where it's a project managers are bonused, et cetera, based on the collectibles. Right? Yeah here we're talking. Putting the customer in the center. Mm-hmm. That's a huge mind shift. And really, I'm, I'm stretching to think, have I, have I ever come across a project managers that have made that successfully? I don't think I can come up with any, I don't know. I can't come up with anybody who's done well, maybe by the end of this podcast we'll find out why there's so few. Sure. Or like I said, maybe some people will, will show up in the comments and be like, Hey, I. The person you look at. Hello? It's me that you're looking for. Maybe Lionel Ritchie will show up in the comments. That's what I'm saying right now. Oh, he's, he's gonna be singing over for king Charles coronation. Oh, is he? Yeah. Yeah. Him and Katie Perry. Good British singers. Katie Perry. Yeah. Good British. Because, because all the, all the actual like British singers, They all declined. They all, they're all busy, but they declined. Yeah. We asked them all. Yeah. Yeah. They asked decline. Well, they asked Sir Elton John and he is like, I'm busy. Anyhow. I, we digress. Hasn't he done enough service? I'm just saying he's done a lot of service. Yeah, yeah, yeah. He's not on drugs anymore, guys. He's not, therefore not available. So with that, let's let's just say goodbye, yellow Brick Road. Come back to what we were talking about. What were we talking about? What, so we can talk through some of the, some of the pros, some of the cons in, in having a project manager as your product manager slash product owner. And let's, let's start with the very clear, obvious which should be a pro, I dunno if you want to be on the, on the pro side or on the con side of this moment. Let me just throw it out there without context. Sure. This person has a lot of project management experience, which directly translates into ops experience. So there, in the podcast that we did with Melissa Perri's Build Trap, the visualization that we showed is there's tactical. Things that you have to do as a product manager, right? There's operational things you have to do, which is aligning dates and you know, ge, getting people to do things by a certain date and whatever. And then there's strategic things, strategic, that type of that what, what you do with a roadmap and above the roadmap level, that kind of stuff. Obviously project manager won't have pro, probably won't have that stuff, but the operational middle where most product managers usually don't get trained, they'll be able to nail that skill I would think. So. They, they have, I think they, they have the wiring for that, right? As a project manager, they're, they're used to managing dates, they're used to managing people, working to items for those dates, et cetera. So I think you're right. I think that is a natural. For project managers coming into product. Mm-hmm. So that, that would be a pro, I guess if you're looking to do that, the flip side of that's going to be sometimes you can be too rigid with those things. Yeah especially coming from that background, all you're concerned about is making that date or those dates. Right. And, and to a certain degree you need. You, you need more empathy with the customer. Right, right. And figure out why those dates are missed. Right. And sometimes just say it's okay if they're missed, if that's for the right reasons. Yeah. Well line lining up dates and Uh, basically operating, like that's a, that's not really the majority of your role anymore. Yeah. Even if if I were to show the, I mean, I guess I talked about it so much. I have to show the build trap I think that's probably big enough. Where's, can I go like a little bit bigger? Uh, nope, sorry. We don't have the technology. Okay, well, whatever. Um, so like you see here, Tactical operations, strategic, but like the operations, the green part mm-hmm. Is really, it's a tiny sliver until you get to the director of product. Right. Where a like 50%, well probably, oh, like by this it's more than 50%, but basically around 50% is all operations lining things up. Yeah. And that doesn't make sense when you have a staff under you that you're doing a lot of lining things up on their behalf. But you know what, moving into. Even if you move directly in a product manager or, I don't know, somehow you move directly in a senior product manager. You see here it's about the same amount of what, 20 20% maybe 15, 18%, something like that. Yeah. It is a small, it's a small amount. I guess it's an advantage, but it's like a kind of a negligible advantage maybe, yeah. It's not, it's not one of the big ones. Okay. Well maybe we move on to to an actual larger one like you. A, a pro on our list would be you have a lot of experience with stakeholder management, which does directly translate into product management. Yeah, that's a good point. I think it translates as you said, almost one-on-one, right? Cause you're still managing stakeholders. Mm-hmm. Not a lot changes there, I think from skillset perspective, right? You need the communication skills. You need to figure out who needs to know what, when, how, et cetera. Sure and that doesn't change. So yeah, that's a, that's a big plus for somebody from a project background coming in because they don't have to learn anything new they can apply what they. And still be, be effective at managing stakeholders. Well, you went to the second point of where I was gonna go is it's communication skill. I would think that my project managers, oh, I would hope, I don't know, maybe this is not true, but I would think that my project managers have have a bit more polish and a bit more finesse and a bit more ability in their communication skill than anybody that came up. Like for example, if someone came up through development and now they're a product manager, I, I expect they would be a bit more raw on. Communication and follow up skills and the way they bring up sensitive things. And you know, like you may be talking to a team that's stressed or whatever, or maybe they've missed a deadline and now you have to kind of confront them about it. But yeah you still need stuff out of them, so you can't be burning bridges. There's a way to bring that up. So I I, the stakeholder management and communication I see is separate topics. They are separate topics. I think they're somewhat related cause you communicate with stakeholders, but yes, they are separate, I think to the communications management standpoint, yes. Somebody coming in through, coming up through the development side of the house. They may not be as polished. They may not come in with the mindset of raising issues and then raising potential solutions perhaps. Right. Yeah putting that in that light. Yeah they may be direct in some cases. Right, that's possible too cuz developers like to be very direct. Right just because of the nature of who they are. Right project managers, on the other hand, I think they vary. Some project managers that I've come across, they, they're very good at communicating mm-hmm and, and taking those absolute hard. Numerical concepts and putting them in terms that are, let's just say, more palatable for the stakeholders. Some, some of them? Yeah, some of 'em, some of them on the other hand I was gonna say are Oh, just direct, right? Yeah. I was gonna say, I'll, I'll go with no filter people. I'll go with you on this up until a point, but because I've worked with some project managers, That uh, woo boy, you would think they started with the you know, they, they were born in a barn. I don't, I don't know what you would think. I have no idea. Like, yeah, yeah. They, they tend to be very direct sometimes and no filter. It doesn't matter who's there. Where does influence live? Does it live under stakeholder management or under communication or both? Like in, because like as a product manager, you have to build influence. Uh uh, as a project manager, this is gonna be real confusing for me to keep using these few terms as a project manager, you still do have to influence. I mean, you don't have direct control of, I guess, things that are outside of your sphere vendors, stuff like that. Maybe it's not a great argument cuz they kind of are in your control. I think there is an argument to be made there. A project manager has more authority by, by virtue of the position, I suppose. Yeah than. Product manager might. So, so to that end, they have to build their influence, right? They have to make sure that their alliances are brought up and all that. I don't know, I think you can go either way on this, but project managers also need to do that, especially if they're new. Mm-hmm to the project, to the firm or company or just new to the team. They still have to do that. There's one category that I actually want to hit that I think is. Look, all, all these, we kind of talked about both sides, right? I think there's a big advantage with this last category, which is expanded awareness of like running a business. I think of any product manager that I've worked with, or even me, like if someone came to me and said all right, Brian, I want you to launch this new software module that does whatever, and oh, I want come up with a budget of how much it's gonna cost and milestones, or how long it's gonna take. Generally speaking, they don't have to be accurate, but you know, just generally speaking in stub it all out so I can do my budget for next year, cuz whatever, maybe this is reality that we're living in, people do yearly budgets and stuff like that and they're asking me to basically set a lot of this stuff up. Scratch someone who's got the, the PMP certification. Like they, at least they've done this stuff on paper. What I, I could do it just because I have the. Right but there's a certain way that a, a project manager would walk through that kind of stuff and then work with the business leaders and people that have budget and stuff like that, and or move things along. So I, I, I think this is kind of the advantage that point goes into the project manager category on this one. Yeah, I, I initially, I concur with you there because project managers typically do work out budgets, et cetera, not just on paper. Right. They do that in the software too. Mm-hmm so they have the jobs to figure all that out, make projections, et cetera. That part is fine. I, and those aren't necessarily really challenging skills that people can learn. Yeah. But here's where I'm gonna go the other way and say they're gonna be just simply focused on people as resources come up with budgets they're not gonna be worried about or concerned, I should not worried, concerned about coming up with budgets by product features, for example, right? Mm-hmm. They, they don't have. That wiring, they don't think about it that way. Who's gonna be building it? How many people are working here for how long? What's their what's their rate? What are their rates? Because that's what they've been doing. Right as a project manager. So, yes, it's an advantage, but also it can be a disadvantage if they're not. Willing to quickly adapt and think about things. Yeah from a budgeting perspective. Right. Think about things from a product point of view. So the, like everything up until this point was things that I think, might be advantages that project managers coming in might have on their side. So we kind of talked about both. Now we'll go into the category of things that I think are like pretty strictly disadvantages and we can kind of talk through both sides of each one of those. And the, and I want to pivot now because you just brought up. The first one that I think is a disadvantage, which is the, that, that they've never been asked to do product research and basically start delivering something and start delivering with this large cloud of ambiguity or all these unknowns to just say, Hey, don't worry about a plan. Just start delivering. And you can use some discovery methods to find your way where you're going once you're delivering, but I need you delivering first. So the, that, that, that living in a world of you know, I mean it could be if you're setting up a product from the ground up, it could be living in a world, in a world of total ambiguity. As you research your way through that, that research based approach, I think that is working against them that, that, that scientific approach of like, try something, get some feedback, change your methods, do something else, like I think that's working against their mindset basically. Yeah. I concur with that. It is working against them. They're used to having more certainty, having lines on a get chart that they can how long is it gonna take? They oftentimes dictate that if they do speak with their team members mm-hmm they'll add their own padding on that, all of that stuff. So yeah, you're right. They don't have this, this idea of being comfortable with the unknown. Right. Or with ambiguity. So with uncertainty, right? So yeah, that's a big disadvantage in. Project manager's camp. I guess I didn't even think about padding estimates. I like, it's been so long that I've been out of the world of dealing with project managers that I completely forgot that everybody pads their estimates. You know what I mean by, by some amount. Like a up or down, it doesn't really matter. But there is padding built in and it, it's, it's been so many years. Where I've been giving, I, I, I guess, quote, clean estimates I like the velocity or the throughput or the flow or whatever. We're using, cycle time, lead time, like they are what they are. Like there, there's no reason to pad that stuff down. Well, you can't, right? These are, these are lagging indicators, so you can't really pat 'em. Right but that doesn't exist in the project management world so much. So what they do is build in that stuff and they formalize it, right? Often they call 'em feeding buffers. This task feeds this task and all this stuff in the middle. You can flex either way. So we're gonna pat it basically. Right? Right. But I do wanna talk about, okay, so we, we are flip flopping, but, or I am, at least I wanna talk about. There's no rules here. There's no rules here the only rules are no rules I do wanna talk about one, which is an advantage again, for the project management camp, which is risk management, right? Mm-hmm. So they, they, they, they are well-versed in identifying risks and then putting them in that category of are they, are they accepted, are they mitigated, et cetera, are they transferred? Things like that. Especially if you have vendors and you have a risk on them, you put the risk on the. Thus transferring the risk, it's still a risk. The project managers are very good at that so I, I think that's an advantage. I think people not from that background may have to pick up those skills. Hey maybe let, let me let's, I have the natural impulse to push back on this one, but I don't know if that's just me naturally being a pain or if I actually am detecting something that I wanna talk about. I will say the, the majority. Feature team, product managers probably yes, you'll have an advantage over them. Like the people that are fed work, people in feature factories, stuff like that. You'll, you might have an advantage over them, but the, the product managers who find their way forward through continuous discovery. I'm, I'm not sure this is the same skill. so the where it sounds like it's the same skill is hey, when, when we are in this discovery phase, we should be working through the business viability and the usability and all the business risks that can come up when you decide to work on something. I, I told the story, which may or may not survive past the editing, the intent of the story was to say, knocking down business risk saying, Hey, if we use these shaky tools, or if we use these sketchy providers, I don't know why everyone's sketchy, but it we, they may not be stable. Oh, we might, we might invest with this partner business, right? And then they might be outta business six months from now. The, all that stuff is the product manager's job is, is what you're saying that the project manager is used to doing stuff like that, so they have an advantage? Is that where you're going? No. Project managers don't typically think about market and things like that. Mm-hmm. Right. They, they're, they're thinking more about what they call, quote unquote resource risk, schedule risk, vendor risk. We might, we might have missed sorts of things. Yeah. So, so less likely that we have missed a, a piece of the process or something that we ex Exactly. So it's not a wider remit to think about from a business perspective. I mean, that's still an advantage. I, I it is, but it's not a massive advantage those skills can be learned, you know? It, it's not too big, but it, it is there. I think it's a palpable advantage. I agree with all that. I, I kind of shuffled it back into like be being good or thorough at operations, being, being detail oriented with, with operations in mind, that kind of stuff. It's not exactly the same as what I think of is risk mitigation in terms of my risk. Like, I'm gonna build a feature and nobody's gonna use it when I put it out there. That, that's a risk in mind. That's broad think right. Yeah. They don't bring that necessarily Yeah. As a project based, so they think about it from perspective of delivery. They think about delivery risks. Yeah. Right. Is something gonna be delayed is, is something slipping so that it would impact something else upon which that which is slipping is dependent, things like that. Right, right, right. It, it's not, it's not a huge advantage or a disadvantage. Probably, probably a disadvantage. I said, hang on, I'm just thinking through this. Well, it's a bigger disadvantage and it is an advantage now because they don't have the, the business perspective. Well, where I was going before, like my, my brain became my brain and sidetracked myself. Um, where I was going was I'm already forgetting, oh uh, like this might lead to like feature factory type of thing. Mm-hmm. Or, or like, we have to do all of AC feature X, Y, Z. Right. You know what I mean? They might lead to that kind of like, well, I made the plan to do all of. I don't want to leave the last two tasks open, even though I've got everyone in the business agrees that there are higher priorities. Like, why are you still working on that? Haven't you delivered enough? You know what I mean? That kind of I don't even know really what I'm saying. No, I think you're right. They don't know when to draw the line, you know? Well, any deviation from a plan, I suppose, right? Any deviation from a plan, they're gonna see that as this is not good. So let's just come back to the original plan, even though there's merit. I'm not doing that well. This, this is, this goes directly into our next point on here, which is they're going to have to have a, a significant mindset shift. To operate in this new paradigm. Ooh, I don't get to say the word paradigm often on the podcast. That's, that was fun. Um but, but they, but seriously, they had like the idea of like, well, we planned eight stories to deliver this epic, and we delivered four, or we delivered five of the stories. There's still three out there, but the customers tells us like, we love it the way it is. Like, we don't, we don't like those other things would be great, but we love it like this. And. And you're looking at what the customer's telling you, and you're also looking at the things that you need to jump to next. The, the, the, the value you have to jump to next. And you're saying, you know what, all this stuff I need to jump to next is like way more valuable than these other little button up type of tasks. Again, assuming we're not talking about technical debt or whatever, all things being equal, right? And, and you'll say, you know what like maybe I'll move these way down the backlog and if we. Time to pick up like little onesie twosie things. Maybe we'll pick it up in the future, but you're, you're basically saying, yes, we did plan this. Yes, we always intended to do it, but now that we're kind of here and the customer's real happy with the solution, like I don't, I think there's more value somewhere else. And then just. Pivoting. Yeah, I certainly agree. The trouble with paradigms, it's a shift happens Uh, no, I, I look, it's, it's, it's it's tough to throw away work that you planned. It is tough because you feel like you are somehow underperforming. Right, right. And, and, and that, that mind shift change. It's hard. It's hard for people. Coming from a product background or at least product or product orientation. Right. To say, well, good, enough's good enough. Yeah. There's something else that we'd rather be working on next, as opposed to, I made a plan, we all made a plan, we all agreed to it. Mm-hmm. And when we have to execute the plan, the, those two things don't really sit well together and people coming from a project background. Sometimes do struggle with that. You want to hear the you want to hear my insidious follow up to what you just said, like there are, we talked in the previous buck about blame. Mm-hmm. And I would be very concerned if I hired somebody like this to work with me, or I would to be one of my peers. I would be very concerned about their their influence of the organization, stakeholder management, stuff like that. a lot of project managers I've worked with could just be my experience. So I'm like, I'm just want to get that little caveat and little star, little asterisks, asterisks out there to say, you know, something doesn't go the way that we plan or whatever. And this, these, these people might be out there not saying, what did we learn from this experience that didn't go the way we expected it to. And rather say, everyone would've succeeded if it wasn't for those darn kids or whatever. Like, my, my evil plan would've succeeded if it wasn't for you Darn kids. Right? Yeah. Yeah. So that, that, that whole that whole perspective of looking at deviations from the plan and then really looking at blame, right. Right Blame and or some sort of penalization of people that you know, somehow underperformed as opposed to. Welcome those, those changing requirements. Right? Uh that is completely, I think, contrary to the to the ethos of a project manager. They, they have to try hard, I think, to get over that yeah. Yeah, like what happens? Uh, if you have teams that, like when you're a project manager and you have teams that miss their deliverables and you have vendors that miss their deliverables and let, let's say that you're a project manager and, um I, I've seen project managers at shops that actually own no development teams. They're, they're, they're going to offshore developers and then offshore testers and then other teams to receive it that are like customer teams, u a t customer teams to receive. So they're, they truly are like, they're everyone's merc. Working for the project manager at that point. I've been in those organizations too. It's a super scary way to run a business, but also like if somebody misses a and everything shifts. Like how do you not like you're gonna do the five why's? Uh, and, but they're always gonna lead back to pointing at people to be like, well, the five why's we failed because this wasn't a hit. Why wasn't it hit? No, it wasn't a hit because it's, this thing didn't turn out the way we planned. Well, why didn't it turn on a plane? Oh, because you know, because om screwed up. Ultimately. Yeah. Ultimately it all comes down to a person or people and a project manager's kind of mo is going to like I said, penalized people, right? So it, it may be that these people are not performing right, so they write 'em up or they get rid of them in the worst case scenarios. So I think that is a real risk from a project manager coming into this realm. It, it's, it's hard to embrace this idea that everybody tried the best they could, given the direction that you gave. Sure. Now it still comes back maybe to. Right, because you gave the direction, but you should treat that. A discovery, right? This is what we did. Here's how we fail. Let's get up, dust ourselves off, move on. Right? Yeah. We learn something from that. So that's hard. That's hard from a project manager's point of view. Well, the project manager is not really providing direction in terms of leadership and vision. They're quite honestly, I don't really know what they're, they're, they're. Providing direction with regard to the plan, I guess um, but the, the, the why, why are we doing this? Like I don't know if a project manager uh, probably the good ones, they do know the why. They, they, they do understand it. They've, they've made it their business to know the why, but I can think of a lot of project managers I've interfaced with in my career that they don't, they didn't care why. Go talk to this person if you wanna know why. Right? That's not my. Yep. Yeah. And, and those are different skillsets again. Yeah. You know and I don't know if these are easy to learn cuz you're wired that way. Uh if you've been working in project management for a number of years you are wired that way. And for you to suddenly leave that and pivot, that's gonna be tough. Well again, that goes back to the main category we're talking about now. It's mindset. Like it's, it might require a mindset like go, go to our episode 100 where we had Ed. For Carol Dweck's mindset. Mm-hmm. And listen to that podcast or watch it, I guess, and listen to that podcast. Um, because uh, and or if you don't wanna listen to that podcast, that's okay. Like read or download the audiobook or whatever for Carol Dweck's mindset, because that might, that might key you in right there. Uh uh, of oh, I've got some. Behaviors that are set in concrete that I, I've realized that I now believe that they're set in concrete, that I realize that like, hmm to be successful in this new role, I probably should think about changing if this is the same way. yeah, it really is. Maybe we'll be kind and provide a link in the section below to the I've been pretty good at that, the last couple podcasts in the editing. I even lead the little part in where I'm like, I'll put a link. Oh, I'm, I'll just cut it out if I'm lazy. I even leave that in because I think it's hilarious. I don't care if anyone thinks it's not hilarious. I think it's funny. we touched on leadership there in that last bullet point leadership versus management the and let me throw this one out. As something I think is in a con in, in the, in a, in a drawback is the project manager is squarely in the management category and the product manager is squarely in the leadership category. And I don't think, I don't think they work not being in those categories. I don't think you can have a product manager. Who is a manager, quote manager from the management, like perspective of manager, I guess I, unless you're in a feature factory, I guess. Yeah, I was gonna say it. There is some context there as well. Right. So overall I'd concur with that, but I'm sure you can find edge cases in either scenarios. Sure. Right but, but I think the first point you made about project managers, Management as opposed to leaders. It's probably pretty accurate, I would say. You don't gain leadership skills in that sense. What you gain is skills that are directorial in nature. You, you're actually demanding things from people so much whereas a leader doesn't do that, right? A leader empowers people and sets them up for, for success and then gets out of the way, right? Um, that's not necessarily true of. Project managers. Now, some are very good they've taken the time and trouble to, to hone those skills and they're, they're very good. But for the most part I don't think you're gonna find that. Mm-hmm. The other side of the coin product folks being more leadership oriented people. Yeah. I could say again the same thing. Majority of the time, you're probably right, but you could have some rookies that come up and possibly struggle to be leaders unless. Acted in a leadership capacity elsewhere or be outside of this domain. Right. Oh, I, I was gonna say, if you're gonna force me into , the con on this one for like against product managers in, in the category, they should be good at, all of the product manager. Who you know it's the wake, wake up at 10 o'clock and take the bus into work or into like the private bus and have their juices and have a sit on the rooftop bar until noon and do exactly 15 minutes of work or whatever. Like these, these people like advertising their life at Meta or Facebook, whatever. The people that I think in product management that are more like managers are the people that are kind of separated directly from their team. They don't do discovery with their team. They don't do you know, writings the stories and breaking work down and talking through, work with their team. They kind of, they sit with an engineering manager or somebody like that, and then they talk to them, and then the engineering manager goes and plays buffer to the team and, or, or maybe the, maybe the engineering manager. Works with an offshore team to punch stuff out, and then the engineering manager presents the work back to the product manager. So like in that instance, you're kind of like a manager in that, in that you really are, you're not, you're really not leading from the front in that case. Yeah. Right. You're not with your teams, you're not with the customer in that example. Yeah. So what I hear at that point, you're not really a leader at that point. Right. And I'd argue you're probably closer that stage to becoming a, or not becoming, but closer to that person, which the product the project manager would be in that same role. Yeah. Because even though you came from different backgrounds, You're, you're there. You're right there. Yeah. In management squarely, right? Um, so yeah, I agree with that this doesn't really fit into any of the categories, so I'm gonna bring it up here. Right, right. At the end of talking about leadership, like there's a whole marketing component and like a, a growth component of any product manager. Like when you, when you're, when your product is in growth mode as opposed to your product being in sustained mode or sunset mode, right? When your product is in growth mode there's a set of activities that. Project manager would find, um would find that they've never really been exposed to like for example trying to experiment to get retention or experiment to get, you know uh, acquisition of customers or stuff like, it's almost like a marketing side to the job role that maybe they've never done, they've never had to do before. Drumming up excitement and drumming up uh, support out outside of the. Yeah. Yeah, I think you're right. So a community building aspect as well. Yeah. Yeah. So project managers they really haven't been exposed in that way to potential customers and so forth. Work has been given to them. Right, right, right. Taken to them. I guess the other way is, yeah, you, you go figure out is there a market? Right? How big is it? Is there an appetite? Yes but, but fundamentally, I think. The divide, if you will perhaps that's a strong word. Maybe not the, the divide is project managers know about a project life cycle. Sure. They don't know about a product life cycle. Sure. Right. Right most. Product folk know about obviously the product life cycle and, and you could argue that it's not a stretch for them to get to grips with a project life cycle because it dovetails in with the pro life cycle anyway. so that, that I think is a nuance there between the two roles. I'm gonna jump to the last category which is when people tell me doesn't now we're not talking about project manager, we're talking about pretty much anyone. When people tell me they wanna be a product manager I tell them there's really only two ways to enter there is you start with product management experience and the understanding of how to build products and how to do discovery and stuff like that. Or you start with being an expert in a domain and then you go learn how to build great products and interface with development teams and work, work through requirements, stuff like that. But you have to have one or the other to get picked up as a product manager but starting with neither of those, neither understanding how to build products like you've never been on with, with or on development teams and not understanding and being an expert in a business domain, you're really starting way behind. And that, that, that's, this is the, probably the biggest, I say it here for last because this is probably the biggest thing in my opinion, and probably a lot of other product managers that would listen to this is, would probably label this as the number one thing is if you don't have either side of this equation, it's gonna be very difficult to break. Yeah, absolutely. A absolutely true those are the primary pathways into I think, this profession. Right? If you don't have those two, it, like you said, you come in, you don't know the domain. Right. You don't have that mindset of experimentation, et cetera. How do you break in? I'm just wondering now, kind of as, as we're talking through this, is there maybe an ancillary pathway here, which is you work as a product owner, you could come from the development side of the, so at least you still have development type of background and, and the domain. So I guess it's the same thing now I do want to talk about. We say domain, but it doesn't have to be your specific product domain necessarily. What I'm saying is if you know about what products are, how to build those mm-hmm. You could relate that experience with another product. Mm-hmm. So it doesn't have to be the same thing. Like you worked in, let's say, a cosmetic company, right? Sure. To get away from software for a bit you could still, those skills are relat. To any other industry. Mm-hmm. You could go to a a detergent manufacturer or whatever, clothing company. This, these are all products. So if you have a product orientation, product mindset, you can apply those, those those skills in any of these, I'm calling them domains now. Mm-hmm so I think those are relatable skills but if you hadn't, if you didn't have. Well, what, what, what, what, what are those skills before we move off of this topic? I think those skills are like a, a good, a good feeling about like vertical slicing, like breaking work down. Like what, what a story might be, , how to kind of phrase or reword like air quotes, requirements, you know what I mean? Like, like ba type of skills, like a lot of that kind of stuff. Also, like if you're gonna get past that to say like, working with technology to actually implement things like that, that could be it too. Like a lot of the things that I, I ascribe to product management or e even if we got outta the technical domain and we just back up a second, the empiricism about, I'm gonna try something. I'm gonna see the results. I'm gonna act on the results, change my way, go forward, even if you don't even have a software product. And we, and we are just trying to do something to find the way that the, you can still apply a lot of that product thinking that, that the continuous discovery type of thinking. But then I load on top of that with product management skill. When I say product management I'm, I'm loading down all the, the, the business analysis skillset and the product development skillset but, but the basics of like, why are tests important? What is the difference between te, what's a unit test, what's an integration test? You know what I mean? Where should you apply those? How much time should you put in? Or what phases your product in and sunset is in, whatever. I know I'm rambling now, but no. All of those are essential skills really. That's, that's different than, than completely understanding a business. Right. Yeah. Right. So those are relatable too, right? In your example, they were software, but yeah, they, they're relatable too. This idea of having that experimentation mindset, right and also the idea of empathizing with the customer their needs. Yeah even concepts like personas, for instance, right? The Oh, yeah. You know, who, who are you building it? And then figuring out why, what are their needs? Yes how do they use your product, when do they use your product? All of those things. Mm-hmm. Th those skills are relatable, I believe, from one product to a completely different product. Mm-hmm. Right. It's still a product. Mm-hmm so you didn't have those, and you didn't come from a, a, a now narrow, now a narrow focus. Right. So the domain in which you're working. Mm-hmm. Technical domain perhaps. Mm-hmm. If you didn't have those two, you'd. I would see pretty much I almost wonder what if we if there's a way to boil when I say domain expertise, like that might go over some people's heads and be, I mean, it, it, it's like if I worked as a accountant for 10 years, Right. Mm-hmm. Doing taxes, keeping people's books, stuff like that and then I move into telling people how to write accounting software. I'm gonna have a deep, deep expertise when I talk it's gonna be from direct experience, and I'm gonna be able to go super deep into nuance when, when question Now that that doesn't excuse that I still need to be interviewing users and, and stuff like that, but there is a deep, deep empathy for the users that otherwise would be impossible to replicate and yeah, I agree and that would have a direct bearing on. Your ability to synthesize a product. Right. And and to navigate value, I think. Exactly. Yes, I agree. That's right. Yeah, that's very true. So what, what do you think about this idea that you know, somebody from a a, a brand newly minted MBA in marketing comes out and gets installed as a product manager in a Sure. Company. How, how, how does somebody like that fare with Yes, they're armed with an mba, but they don't have domain knowledge. They don't have the product orientations, I call it, in their mind, how do they fare in the industry? I, I've actually seen one case of. This in real life. Years and years ago, I didn't talk about this. I was a franchisee mm-hmm of a, a food business. And the, the marketing person was a 27 year old newly minted Stanford, M B a. This went out for about six months and then he was gone some of the direction that we were receiving had us scratching our heads thinking, does this person really know what we're doing, who our customers are? so that, that's just one example, ed equals one. I get it. But you know, I, I, I think people will fail if they don't have one or the other as we started with that. Right you, you need one or the other. And I think. Most of the time, I'd say you'd lean on the side of having that product mindset is being more important than having specific niche domain knowledge, cuz that can be acquired or you can work with people that have that. Mm-hmm. Right. But if you're a product person and you don't have that product mindset, how are you gonna succeed? I don't know. Well, I mean, there we go. You just, you just put the capstone on the end of our doctoral disserta. I mean, we're, we're not, we're not Stanford MBAs or anything, but you know, Hey, but if you can you know, if you can think of other ways to succeed as a a product person from different backgrounds to let us know. Oh, I, I thought you were gonna say, if, if you're a Stanford mba, please let us know. Yeah, that too.