AA76 - Product Owner vs Product Manager

We wanted to have a podcast about product owners versus product managers. Because when I read job descriptions, I see a lot of positions where companies don't know what to call them. mm, right. Should I call it a project manager? Should I call it a product manager? Should I call it a product owner? I don't know. And I guess we Om, we should start this podcast by talking about the Mike Miller definition of product owner versus product manager. Yeah. I think that's a good starting point. So Mike Miller and several others, by the way, subscribe to this viewpoint that a product manager is responsible for the profit and loss of that product. So they're more of a strategic, role that they play a strategic role and they are also more outwardly focused, meaning that they're dealing with the marketplace. Right who are the target customers and you know, where are they. What are their needs, et cetera, as opposed to a product owner who, according to this viewpoint the product owner is more of an inward focused role, right? They work with the teams and they do the they basically coordinate getting it done to the point where the product is, what it's supposed to be. So they're not concerned about how to price it for instance, right. The viability, is it gonna make us money? Is there a market they're not concerned about that? That's the product management type of role which is more strategic. The other one's somewhat strategic, largely tactical. I would. Agree with that with some caveats number one to your point, Brian, I think there is a whole lot of confusion when we look for instance at job descriptions and I almost sometimes think it's intentional. Like there's some intentional ambiguity so that they can just kind of be able to, it could be ignorance it could be ambiguity could be intentional. I'm not sure and maybe a little bit of all the above and of the above, but I, I like intentional maliciousness. I like, I like that idea. I mean, what I can tell you is that as a product owner, I, when I am interviewing one of the. Things that I do once I get to the point of actually interviewing with the actual hiring manager is to understand their definition of product owner or product manager, whatever it is I happen to be interviewing for, what is it please define to me, what does that mean to you? What is a day in life of a product manager in your organization or a product owner And that's very telling. And oftentimes what, what I'll hear is a lot that has to do more as a project manager, which I think is very, very common. And I don't necessarily know that that's intentional or even malicious, but just maybe some ignorance or Yeah so anyway, and then, then I'll know, Hey, this is not a company that's, I'm gonna be a good fit for. But as far as internal versus external, I think that that's a good, a good way to describe the differentiation between the two. However, I also think and I'll bring this up here number one, that they should be collaborating very, very closely. So a product owner should be involved for instance, with the decisions and the overarching kind of understanding of that product when we're, for instance, working with marketing and such. So there needs to be some understanding or collaboration between those two roles. If you happen to have two and and that goes both ways. So I think that the, there needs to be an under a mutual understanding and input from the product owner to the product manager's perspective and probably the product manager to the product owners and the developments perspective. So there, there needs to be some collaboration, some kind of cross pollination there and no hierarchy. They should be equivalent. Oh, equivalent. Yeah. Equivalent. Yeah, you see different sides, right? So different aspects and different parts of the team, but equivalent. So product manager is dealing with marketing leadership, vision mapping, P and L you mentioned those things, product owners dealing with end user understanding the, from a being a me per perhaps you understanding the ins and outs and understanding truly the why and the what from the end user perspective. And if we were to, for instance, kind of. Differentiate between a user and a customer, which usually who's paying for the product. And who's actually using the product. The product manager would be dealing with the customer and the product owner would be dealing with the user, at least from my personal perspective and opinion. That's an interesting place. You just went to where he said they should be equivalent because absolutely. That is not what we're seeing often out there. When you look at the job descriptions, which by the way, I, I don't know if that's intentional or not. Some of the contents that you see in job positions advertised are just a they're all over the place, frankly. It, it almost looks. The job descriptions for scrum masters and and coaches or any pick any two roles except maybe developers, the people just take a job description and do a search and replace. It looks like. But, if someone asks the question, what's the difference between a product manager and a product owner then particularly, I might say about 25,000 a year about right. So that's just going to that point. You made about it being equivalent. The job positions advertised do tend to advertise product managers and kind of position them. The strategic leaders, right? Mm. And they would be charged with the failure or success of the product with the P and L product owner. They say works with the team. Right. That, I mean, this is literally from job descriptions so therefore by definition, not so much a strategic role. This is what I've seen. Mm-hmm I'm not saying this is how it should be. Mm-hmm ideally there should be a single flat hierarchy that says here's the product owner, here's the product manager. And here's the customer, mm-hmm, all on the same level field, but that might be utopian at this point. So we'll take baby steps for now. the strategic versus tactical point in here is what I wanna spend a little time on. Yeah. If I'm hiring a product owner and I want them to be an expert at engaging my team, building a backlog, talking to a customer about their niche part of the product. look at Facebook, for example, you have the timeline, you have groups and you have advertisements or whatever. You have different features. Yeah. Each of those could have a different product owner. For sure. Mm-hmm like, but they're creating a product. Oh yeah, yeah, yeah, yeah. I completely agree with that. if you're looking at it from that perspective, one is strategic, the PM in that example is strategic to say, if I have this feature for timeline and they have this feature for marketplace and I have this feature for groups, I want to combine the three of them to launch something that goes up across all three of them at the same time, or maybe I want to change the ads they get served to all three of them, cuz let's be honest, it's Facebook. So they really only care about selling you ads. Right? I will, I, as the PM will gather all of my POS for the different pieces of the system and say, here's this strategic level thing Hey, we want to give users less things that are actually helpful to them. And we want sell more widgets. They seem doing that very, yeah. That, I mean that that's their strategy. That that's why they like, yeah. I mean, that's why they're losing market, like at a blinding pace because their, their PMs are coming at it from that perspective, how can we sell more advertising and here are the features that each of you have to implement in your small areas of the product in order to cater to the strategic things that we, the leadership are trying to. So, the reason I bring up that accusatory example is because when we say the PM and the PO should be equal levels my experience is they certainly are not equal so the people who serve the strategic interest and the people who serve the teams, it's like these people are coupled with your leadership versus these people are grassroots couple with your teams. They live in different worlds. Mm-hmm is kind of what I'm saying. So I, I don't, I don't see them as like coming from an agile transformation experience where, Hey, my development team say we need to be more agile. And my leadership team says I don't care about agile. I want everything on a Gantt. You know what I mean? Like, from that perspective, I would say I understand where you're saying they should be equal. Hierarchically should be equal but I, I see the group that communicates with leadership as a, in a superior position to the ones that work with the development teams. That sounds like somebody who's really buying into hierarchy and patriarchy and not very agile, I would say, well, it's prevalent though. I mean the DNA, I'm not saying it's not prevalent. So here here's another example of that, right? So Microsoft has Microsoft office mm-hmm and there are other components that office kind of has overarchingly, right? So to take a non-technical example, how about construction? So in construction, you have an architect who basically oversees the construction from a design standpoint, and then you have. the plumbers and you have the electricians, and you have the roofers or whoever people that put up walls. I don't know what you call 'em wallers. I don't know. Anyway, doesn't matter you have those people wallers. So wall-e's, masons, I don't know. These are product owners in construction, but. You know, their product manager might be the architect, really? So are they at the same level that that's really where I'm going? Just another example to think through. So from building perspective, each of those products are individual and necessary for the overall success of the project. You can't have a home without plumbing or electric or at least not a modern day home. Yeah. Unless you're in China. Right? Right. You don't get in here, you wouldn't get a co and maybe, maybe it's the inspector, that's the product manager. I don't know, you know? Who's you know, deciding, Hey, failure versus success. This moves, this actually goes to production. We are allowed to checkbox. Yep. You meet this or you don't. I mean, I'm not sure. I'm not sure where the analogy goes. Inspector wouldn't be though, because they don't have a vested interest. They're a third party looking at from a regulatory perspective, right. To grant, grant you a certificate of occupancy or not. So they they're simply looking for conformance to specific regulations. So to follow along this analogy would be whomever, the construction, the builder, the builder, the construction, the builder is because they would be hiring all of these subcontractors, which would have their own kind of product owners or their own features that they're bringing in. That must be completed. Yeah. Yeah. Is, are, are, are we kind of meeting? Yeah, I think that might be a better analogy, the builder, and then that way we can flatten out hier hierarchically, right? So you have the architects, the plumbers, the electricians, but is the, they're all at the same leader. But is leadership builder, the leadership or the product manager? I'm staying out this one. I don't know. Maybe we're going down and rabbit whole should go down. What are we talking about? Know, I hierarchy, we're talking about hierarchy. We talking about building houses, so, and, and where we should be flattening out the freaking hierarchy. Seems to be just proliferating because we can't get away from the manner in which we have been so accustomed to making sure that we have, you know one of the podcasts I listened to one of the things that he brought to my attention actually, and it's about product ownership and , he mentions when you have a question about why things are done you look at the incentives, what are they being incentivized by? Where are the incentives? That's, what's driving the behavior. And so we're talking about hierarchy. Incentives driving the behavior. It could be $25,000. Oh boy. Right. Oh boy. Like we're we're we're gonna cut ahead. A couple podcasts to, to the DMing podcast that we're never gonna get to. We're gonna get to it. We're totally, but listen agile, can't help you if you are not running a good business. Mm. Like there's nothing that we can do. That's gonna help you if you're like, oh, I want to produce 10 more widgets per day than I was producing before. Well, cool. Well now your defect rate is gonna go from 5% up to 50%. But all your people who get measured by number of widgets per day, mm-hmm super product gonna, they're gonna get their bonuses but seven of those 15 widgets you're punching out per day are completely unusable. You gotta throw 'em in the trash,. Why would you incentivize mm-hmm the into concern, the total quality or the usability of the like, okay. Like, that that's that's, that's where we're ending up now. Right? In this, in this conversation. Yeah. so going a little backtrack and go a little deeper in there. Why do we need 15 widgets instead of 10? What problem are we actually trying to solve? And for whom? This is, this is what we like to call vanity metrics. It all goes back. Yeah. It all goes back. Vanity metrics like when, when you are a middle manager and you don't produce anything. The way that you know, that you are having the effect is that the vanity metrics go up. Mm. Yeah. And then you can prove your job. I feel we should do a whole podcast about decentralizing your organization. Mm. Yes. Basically distributing your organization because. each team could keep track of their own effectiveness and efficiency within the sphere of what they produce. Yeah. Yes and, but when you do that there's a whole middle layer of the organization that basically doesn't have a job anymore. When you distribute the production to each individual team what are all these people that are left? What, what do they have to do? They don't produce anything. So we're gonna continue paying salaries to people that we could potentially find other opportunities for. And while, while actually, building our product out to have longevity and to create the opportunity for innovation and growth. But I hear some incentives there that are really keeping people in that middle management that just have to keep them there. So yeah, this is a problem that goes much higher. and has nothing whatsoever to do with PO and PM. Oh, well, no, I, no, I don't. I don't agree. So oh yeah, right. Okay. Where, where I don't agree, brings us back to our topic of a strategic versus tactical because the people that are the PMs, the people that are in that strategic role, this is like, I don't, I don't know if, is it too early on the podcast to break out like all your PO's could just relabel themselves as PMs and just kick out all the PMs? Is it too early for that? No, I have great thought on that because, because the people in that strategic position they have found themselves in the role that we were just bashing on all the people in like, oh, I think you're the only one. You have to be in the contrarian position age. I think contrarian, you have, you have to sign in the contr. Although I really have some powerful things to say. Okay, well, the advocacy end of it, I'll I guess I'll sign onto, I don't know how I'm gonna do this, but actually gimme a minute, gimme a minute. And I'll figure out a way to sign onto the contrarian position, the people that are in that strategic only spot who only face the leadership and don't interact individually with developers, do you think that strategically in the organization, the leadership trusts them? More than they trust the people in charge at the tactical level. That that's my challenge to the mic. We should talk about this. So Mike, when he is on the podcast, we should bring him back. Mike, if you're listening. Yeah. If you have people who work at the strategic level, who their main audience is a leadership, and you have people who work at a tactical level and their main audience are developers and team members who has more clout in the organization. That's where I'm going with this, the leadership hire. Those people that are the PMs, right? The presumably they hired them. Yeah. So obviously they're the ones that gonna trust. Right? So cuz you hired that person. Well, that's a big problem. I agree. But if you hire somebody and then you cast a shadow on them and, and say, I dunno if I trust you, you've made a mistake. It seems like to the organization and they're gonna look at you. But you hired this person and now you're saying they're not working out. We don't trust you hiring capabil. Yeah. But the reason I'm lingering on this one so long is if we're saying these strategic and the tactical people, the PM PO if we're saying they are on equal footing, mm-hmm , but half of the audience, the PMs, only interact with leadership. And the other half of the audience only interact with my customers and my internal stakeholders, developers, team members, whatever they are not on equal footing. One is elevated in the organization. And has more influence just by their role, like their circle of influence. Yeah. The circle of influence. Yes. Yeah. That's not a good way to split up your PMs and POS. Absolutely. I would say they have more influence by nothing more than the fact that they have a manager title in their name. number one, which I think is what makes one of the things, this is just hypothesized, I don't know. It's the prestige of being a manager, a manager in the position. Right. So the other thing I would mention, so a little bit of history here, I think would be helpful. So number one, scrum came about before the agile manifesto, right? Yes. So they, right. So scrum. N actually created the term product owner. Right. And that, and that that role has developed over the multiple iterations of the scrum guide. Right? Yeah so product owner was a role that was coined by the scrum guide and the developers of the scrum guide, obviously they were involved in creating the agile manifesto. Right? Mm-hmm product management actually was coined by Hewlett packer, Packard in the, about, in the early mid nineties however product managers had been around prior to that long before have been, maybe been called something a little different, but certainly been in that capacity. We could actually historically go back and, and currently figure out what those definitions are. Yeah. Right. And then actually the historical to manifestation of those and, and, and their. but I actually, because I attended recently the agile 20, 22, and I actually watched a keynote by Melissa Perry. And I don't necessarily agree with this to be very honest. However, she had a point that I'll bring up here and that is she'd actually never worked as a product owner. She only worked as a product manager and she's the one that actually brought this history up. Right but then scrum came along and then there was a product owner, which was in her mind, a product manager. She just kept her product manager, role title and whatever. But her definition when she differentiates product manager and product owner, is that. The product owner is the role where the product manager is the job they are or can be. Yeah. One and the same. Yeah. I can say that. So the job is to manage the product. The role is the product owner, which is defined by the scrum guide. Yeah. That's Melissa Perry's interpretation of it. I wanna just go to this directly now and say, forget about all these titles. Forget about product owner, product manager, somebody who cares about the product, give 'em a title. Mm-hmm, a product evangelist and that's it forget about whether they're tactical strategic. Yes, they are. The tactical. Yes. Are they strategic? Yes, because they care about the customer. Mm-hmm, in shortcut all this BS. I agree with that. However, we don't have that in job description. We have companies who are going I want a product manager literally, because that sounds more official than product owner or they don't know what a product owner is. And it sounds a lot like project manager, which is kind of what I want. So let me, let me just, well, I don't know what a product manager is. Right. I know what a project manager is because they've been around since Adam and Eve. So what we're gonna do is we're gonna take a job description for project manager and search and replace project with product. This is what I have found. Yeah. Yeah. And, ah, so that's my point is that there's a lot of just misconception miscommunication ignorance, intentional or not, malicious ignorance, I think. What was that term? You coined earlier, malicious compliance, malicious compliance. There you go. Yeah. So that's what I'm finding. And so that makes the job market for someone who is truly trying to get out there and be for instance, the product evangelist, the product advocate, the product nerd. Freaking product, you wanna call it, but the person that's going to go in there and find out the who the what and the why, and make this a successful product. That's what I wanna do and allow me to do that and give me the levity and the trust, the respect, and the absolute authority to make decisions in regards to that product. That's what I need. And that's not what I'm getting. oftentimes when I see a product manager title, which almost screams, command and control. Absolutely. I agree with all of that. Maybe product minion. How's that for a title? Fair enough. A product minion. Beep beep beep beep, sorry. I can't do opinion. If I'm gonna pick something outta the air you definitely can draw a dividing line through technical product owners, a technical product owner. If you're saying like, I like the PM market is saturated between people looking for project managers, relabeled as product managers versus actual product managers I would say that the, the technical PO role I would argue it's less saturated than the product manager market, cuz usually people looking for technical POS are people that are delivering products to internal stakeholders. They're also technical in nature themselves. Mm-hmm right. That is a job description or a company that I skip over. As soon as I see technical PO I'm like, okay, Nope done. Oh yeah. I also skip over them as well. But probably for different reasons. Okay. What are the reasons that you skip over them? I skip over them because, if I were to read the job descriptions, typically I will see in there somewhere that they want some experience with coding language, I'll see things like SQL experience or Python program. So typically along with it, I will actually. Coding I'm going like, okay. So they're asking for someone to solve the, how sure. That doesn't allow me to be a product owner. If I'm already being hired to go ahead and figure out the how, or to guide a team, to figure out the, how, then I am not going to be permitted to actually do my job as a PO I have reasons why I would skip by those ones. Oh really? Oh yeah. I, I would basically, yeah, next what's the term that the youngins use swipe swipe left. so, so the reason is this, that my reason is I thought, think you're gonna bringing a song and be like, thank you next, like trying to be hip. I didn't know where to hip this. No the reason why I would turn those opportunities down is because I do not wanna work for some pointy ahead, who thinks they want a product person, but really they want somebody who they can say. I, I know what I'm doing, right. You're just gonna follow along. You'll be my shadow. Ooh. What would they call someone like that? I, I know backlog administrator oh, wow. That's log admin, backlog. Admin. Love, love that. You're in charge of this section of the backlog. Technical PO like I I'm kind of with you on that was like Hey, your job. To talk to customers. I'm gonna tell you mm-hmm like, I like the pushback of that one is super easy. Anytime I see tactical PO as a job title, I assume that they work for the development focused wing in the company. Mm-hmm in some way, shape or form CIO, CTO, whatever they don't work for a product organization. They work for the technical organization. Right. Mm-hmm . And I went through a period where I thought that this would be a good section a product section for me to, to enter like early in my product career, because I, I was like, well, I, I have a lot of experience in technical teams. Mm-hmm and like, I, I know like a bunch of different programming languages and SQL and stuff like that. Bunch of technologies, basically. Mm-hmm. So maybe it would be easy for me to get development organizations, like when we did the podcast about the different types of teams, mm-hmm, where enabling teams and platform teams and stuff like that. Well maybe I can get my foot in the door by working for a enabling platform team where basically your job as a team and a product owner is just to enable what SAFe calls systems, teams, other teams. Yeah, yeah, yeah. Right where all you do is extend the architectural runway of your company. Right. And, and, and that's your roadmap. Your roadmap basically is like, what are all the things technically that we're gonna do to make the lives of the other teams, easier. And I was like, that's, that's kind of a cool job. If you think about it, it really is, especially to your point about somebody wanting to break into the field, right? Yeah. But I do have an example or actually two, right? Where a technical bent in somebody who comes in as a product person is advantageous. So one is, and I've seen this firsthand. I know when I worked at Boeing as a contractor, they have products in, in any definition they're products, right. But they, they're not sold to the individual they they're sold to integrators, meaning they they're sold to companies that buy their products and integrated into their product. So over and above building aircraft, they do that. And so a product person for such a product, if they're not at least appreciative of the technology, they don't have to be experts, but they have to at least understand high level what's going on. They would be at a disadvantage, I'd say, I mean, I've seen that happen. I've also seen the flip side, which is somebody brand new as a product owner came in as a technical product owner. Learned a little bit about what this is high level technology terms. Yeah. And they were very effective dealing with their counterparts at the other organizations. They are the clients. In order to bridge that communication that worked remarkably well, the other industry, and I don't have any experience in this is potentially I'm saying might be the, the pharmaceutical industry where if you're dealing with, as a pharmaceutical company, if you're dealing with. Or if you're dealing with manufacturers, they're your clients really? Mm-hmm . And so if you can't speak, at least some of that language, it may be a disadvantage. See, but I, that that's domain knowledge, so, right. So, okay. So that, so I think I, so what I'm hearing is, so when you're dealing with a customer there's benefit to having domain knowledge, I, and, and I believe that wholeheartedly, that's why I am in product a hundred percent. I'm a passionate advocate for healthcare information technology as a registered nurse in just making it better for. providers, patients, family members, users of healthcare technology, right. Mm-hmm and I can bring my domain experience and experience with that type of transition. So then I think the differentiation here is what you're saying is that you don't necessarily need like this isn't about being a technical product owner. In other words, I am a, I used to be a developer. So now I can do this. It's about saying, you know what, I'm familiar with whatever type of technology we are developing in far as this platform or whatever it is, maybe concerned that we are, we are developing for our internal customers, right? So that's a little different, that's still the same thing. That's still domain knowledge. And not necessarily a specific coding language. Oh no, no. I'm not saying right. That's much, much lower level from what I'm saying, not coding language, for sure. So if you're, you can say it's domain knowledge, but it's technical domain knowledge. Mm-hmm . So if your company is dealing with customers that have your counterparts, right. Speaking a certain language, not programming language, just some terminology. If you don't know that, yes, it will. It will be a hindrance to you probably mm-hmm and this is not going deep into like coding or all of that stuff. Right. You don't have to know CPT codes for instance. Right, right. We just have to know what they are, how they're used. They're used for billing. Right. You know, they, they use for compensation in terms of RVs or whatever it is, right. Alphabet soup, but you need to know just that. That's all I know. I mean, but, but I'm not in the industry. Mm-hmm so somebody coming in should I think be given at least that level of an overview, so they're aware that's it? That's where it stops so they can communicate better. Yeah. So Brian, with your point that you made earlier. Question. So do you think that when you spoke to that technical product owner and I think that if we can differentiate out the technical product owner where we're talking about domain knowledge, right? So I'm gonna use that even though, so not necessarily a coder, but someone that understands whatever it is that we're actually trying to build, or certainly nomenclature of that so that we can speak with and understand the customer, right? Yeah but you were speaking to the technical product owner and you thought what a cool job I have experienced with this. I can bring in. Have you found that to be in your experience, potentially a detriment and, and, and, and I'll see this a little bit in saying. I find that dependent on the application I'm working on, there's always, you never walk into a product typically that you don't have to learn something about right. Mm-hmm so you always have to learn something about it. Right? So always I'm needing to learn current state and there's always some new nomenclature and new, new technology. There's tons of things that every other, every company you work for is working a little differently but I find it advantageous to me that I don't ever have to kind of draw the line and figure out, Ooh, am I delving into the, how am I questioning my developers? I can't. And won't do that because I don't know. So I am 100% relying on and automatically trusting in the fact that my team as a team will work together and make sure that the product that we're developing from the, how, how they're figuring it out, how, how to do it. I obviously have the opportunity to, to, to see that and see it come to life and make sure that it's meeting my needs. But when it comes to lifting it up under the covers and seeing what the code looks like and all that, I'm not a part of that. And I don't, and, and I don't even need to think about where to draw that line because it's not something I know how to do. If we take an example, it might help kind of elucidate what we're trying to say. So let's say you're working in a technology company software development, perhaps, and you're coming in from a background that is completely non-technical mm-hmm , let's just say that and the industry is pick an industry. It doesn't matter what it is. Mm-hmm , let's say you don't have that domain knowledge either. Mm-hmm so we'll take that out of the equation. So now there's two levels of. Of kind of knowledge that, that I'm saying that we're we're distinguishing here. Really. One is the level where you can have an intelligent conversation with your customers or anybody else about and the other is the danger of influencing I'll say negatively or positively your dev team. Right? Mm-hmm and I think to me, at least those two are completely separate. So an example might be you come in and into an organization and, and you learn a little bit about the technology, but not technical stuff at all. You know, that your dev teams are using Python that your solution is hosted on the cloud. Mm-hmm , that's, that's the stuff I'm talking about. Mm-hmm so when you meet with somebody, you say, wow, we pro you know, we're Acme, Inc. We provide this and this and this, our solutions hosted on the cloud. And some of the technologies we use include Python. You're not gonna influence any developer with that. Right. I that's just like basics. Right, right to them anyway, mm-hmm so that is one end of the spectrum. The other end of the spectrum. Where you go in and say, ah, I see your, you still using angular 2.0, you haven't upgraded right here are all the benefits, like you're way in the weeds, leave it alone. Mm-hmm so that is the other end of the spectrum. Right? And so coming from a non-technical background you cannot do the latter, which is fine, but coming from a technical background, it's a challenge. This is where I was gonna go with the answer to the earlier question. If you come from a technical background, it's a challenge to not go deep diving in mm-hmm because that's a natural bent that everybody's technical has. Yeah. I feel like you just put one up next to the net for me to spike down, because like, exactly this one's easy to argue against. Cuz if you are in the service of providing APIs for developers, your product manager who interacts with the community should be able to talk specifically to the API endpoints and what the vision is for the API endpoints. And you're getting in a technical discussion with your customers who mainly are developers or what we were talking about before. If you're a technical product owner and your job is to create tools for other developers on other teams inside of your organization, those are your customers, which I kind of feel is like also, like that's like the softball of product management is like, your, your customers are internal customers. Mm-hmm so like, you literally could like walk over to their remote aside. Right. You literally could walk over to their desk and be like, Hey, what do you think about this? Like mm-hmm, , that's, that's like your, your customers are captive inside of your organization. Like that's, that's easy street. For product management. It's I don't need to develop a bunch of tools and instrumentation or whatever to figure out. Cause I can walk over to a person's desk and look over their shoulder as they use my feature easy street. what I'm talking about. Breaks down when you get to that level of , my customers are internal or even if you're not even if your customers are not internal, but if your product is overly technical like like I think of, I think of like, for example there's like services like Datadog and stuff. For example, it's like you install their product in your cloud on a server, and then you point it to their, their product and they tell you like your uptime of all your services and your computers and your milliseconds of response time, they basically monitor your services, uptime mm-hmm or your software's uptime by doing some real general stuff, but like that's all real low level details. It's unlikely a customer is going to bring that low level of detail, but when you're providing that to other development teams, and that is your product, if your product is overly technical, overly, I guess overly that's. Yeah. That's the key, key word. Yeah. But, but in that situation, even, right, why wouldn't you just bring one of your tech leads or develop or in to facilitate that conversation? At the risk of delving into a topic that is part of a whole nother podcast. Why don't you do that is because at that point, what stops you from becoming a, just a product marketing person, rather than a product manager and no longer being a product manager where basically you are uninvolved from the technical details, uninvolved, uninformed, unable to hang in the conversation about the technical details of a technical product and now you're becoming more of a marketing person. You, yeah, you're a product admin really? That's, that's where it boils down. Yeah. So like that, that I I'm very concerned about having no hand on the wheel anymore, because you say, well, my, I have to get my development lead to talk to you about quite literally anything involving the product, because it's so technical. I can't, I can't tell you at all, but that may well be a valid use case right. In those kinds of market segments, or that may be valid because this stuff is highly technical. I don't know, like that's, that's this just hire technical people. So if in your marketing organization, I would have to say if you're a product manager in that situation that you need to be aware, right? You need to be aware of the overarching product and the how those connections, what you're selling, what benefit it's what, what benefits it is providing all of those things. But when you're getting super technical, that it should be, the developer speaking, for instance, with a developer, like where we're getting into that technic, if we're getting into the, the weeds that the, how we're getting into the, how that is not something that I expect to be able to explain well, I certainly should be able to, as a product owner, product manager, be able to explain, you know Generally, but if we're getting into the weeds there, I, for sure want my dev team there and their dev team, if that's who we're speaking with, if that's who our customer is, to be able to dive into the details. And I think that's my other point is context is key here. So having not so certainly having dealt with, for instance products, which were. very analytical where I'm literally the product owner for so many inputs and data crunching from every EMR and lab system and hospital. And so so I could speak to those things. Mm-hmm could I get into the the minutia of the actual enterprise architecture and what's happening at what point? Absolutely not. Right. That's a conversation. If there were questions that needed to be asked in regards to those things. No. That's time for me to bring in. Yeah. You know, my team. Yeah so I think context is key. Everything we're talking about. Falls under the banner of working with users. That's, that's where I'm going with with what I'm about to say, because if your users of your software are developers and you, the product manager can't work with them, cuz you're too in the weeds. Are you a product manager at that point? You could say, well, well maybe that's just a very small slice of my software. What if that's all of your software? Mm-hmm what if you were only the, the PM for the API part of LinkedIn, for example, you know what I mean? Like API of LinkedIn, terrible. One of the worst APIs I've ever worked with LinkedIn. Hopefully you're listening. Yeah. LinkedIn. So, the integration between YouTube and LinkedIn, Microsoft and Google, for example, they don't allow certain things. Mm-hmm on purpose. Sure. They don't necessarily put it in a documentation, but if I'm in the audience consuming their API and I find out that for example, if I post through the UI, the UI team has gone through because they're magnanimous and allowed my YouTube. This is an example, a very specific example. It could be anything could be maybe, maybe not. For example, if I use the UI for LinkedIn and I add a YouTube video, it automatically pulls the thumbnail through automatically, automatically.. But if I go through their API and I add the same link, it shows me a black thumbnail. Mm-hmm because it doesn't automatically through the API. It doesn't automatically pull the thumbnail through and that's desired. Mm-hmm because a team doesn't care about integrating with Google mm-hmm okay. So the team that maintains the front end experience versus the team that purely concentrates on the backend experience, they're different teams. Mm-hmm, probably different POS slash PMs in this instance, different experiences. Mm-hmm they care about different things, different gardens and different walled gardens, right? Yes. Right. You think they would talk to each other cuz they're doing the same functionalities. Oh, that weakens, the team it's a novel communication concept. Yeah. Yeah. But again, they're working with the same user mm-hmm But are they like is the user who's setting up a hundred YouTube videos a week and needs that stuff linked added to LinkedIn to, to support the channel versus the, power YouTube user who's manually adding those. Like, are they the same user? Wouldn't they, but there might be some overlap. There might be different. I don't know. I think some different, there's definitely a different persona that could potentially be parsed out there, but they're different. Yeah. But the question is. Would the results that they're looking for, be beneficial if they lined up. So the answer is no. Yeah. Well, they probably should have lined up before they implemented any kind of, no, that's my point. Like I think the desirable outcome, regardless of those two personas that you described would be the same so in, in that example, I know I already know that like the, the front end team and the API team or whatever, they they're different teams. They're different teams. They probably have different PMs. They probably get paid a ton of money. They probably out of Seattle or Renton obviously they did not talk to each other. Mm-hmm right. When they implemented the functionality, you would think that the people implementing the back end. should have talked to users implementing the back end while at the same time, interfacing with the front end team as a user representing their own users. So it's, it's just like different circles. Oh, it's just gonna go there. Different diagram. Almost like a ven diagram. Yeah, yeah. Different diagram. Right? Could they not, I mean, if you have a product owner for your back end and your front end, I mean, if you have personas or users that you are using, could we not just have the product owners without the backend product owners in kind of interacting with their own users maybe, or be a part of. You know, be included in those user discussions, which is something I advocate very, very strongly for is getting my teams, enterprise architect my development teams, anybody H C D UX design, anybody I, anybody I want them involved. Right. Yeah yeah. So I think this speaks just a little bit to the, what, perhaps I wrote this down because you mentioned it before, and I think we might be able to pull this outta here and that is PM versus PO so internal versus external mm-hmm, closer to leader versus farther away from leadership, right? Mm-hmm conflict of interest. Right. So when we're talking about the representation, if we use the definition of what we used initially in this, in this podcast of the PO versus a PM, and you mentioned trusts the trust of leadership to a PM versus a PO, and how closely they might be aligned to them, that, that so on and so forth. Mm-hmm we now have, and I talked about incentives, right? So we now have a PM. That's incentivized to make sure that leadership marketing sales is happy. Mm-hmm . And I think that's what gives a lot of times POS and PMs a really bad name or a bad taste when it comes to, when you see, hear developers and scrum masters who are bad mouthing POS and PMs, but yeah, there could potentially be set up this real conflict of interest, and we need that protection. And whether that's the PO or the scrum master, the agile coach, or a combination of all of those people to make sure that our development team is being protected and things aren't being shoved down their throat from you know, leadership, because if you have that hierarchy in place, intentional or not just the virtue of a name manager, insinuates, a level of authority, which influences potentially how things are perceived and received. Mm-hmm by the development team and creates potentially this conflict of interest. Yeah. I like, I see where you're going with that one that was way down in the agenda that I had to talk about. Oh, sorry. But I, but I kind of want, I didn't know how we were gonna get there. So this is like, thank you for getting us there you're welcome. When you're talking about. Across the organization. There are different levels. I, I like to say this when I'm on contract and like, I don't get to do this very often cuz now that I'm like a permanent employee, I get to say like that, there are different types of prioritization and they're all relevant. One of which is the person who screams the loudest. Yes. Another one is the highest paid person in the room like that mm-hmm different levels of prioritization. Like, I mean not, not good prioritization, but Hey, those are methods of prioritization. Mm-hmm the, the, the people who scream the loudest, they get this, this, the squeaky wheel squeaky grease. Yeah, yeah, yeah. That is a method of prioritization. whether it's efficient, effective. Good. Not good aside. We agree. That is a method so there needs to be a forum, where they are having a constant continuing conversation about these are the top priorities in the organization. These are the, the top business problems we're trying to solve that filters down through the organization, to the teams. Mm-hmm to the individual product owners on the individual teams. Or we talked about before, if you're Facebook, you're like this is a team for the timeline. This is a team for marketplace. This is a team for I don't embezzling money. What, whatever you do at Facebook, I don't know what you do on Facebook whatever, they are like the POS that are in charge of each of those little functional areas. They grab from the higher level strategy, what they can, that their teams can do. Mm-hmm so that, that that is kind of how you scale product mm-hmm, setting that up to be effective in your organization at a lot of places that I have been like that is not done well. Yes, I cut it straight to this because I feel in order to set this up effectively, you need effective agile leadership in your organization. Hallelujah. Absolutely. Can I please? Yes. It all starts at the top. If you don't have buyin, if you don't have a vision, if you don't have people from in and, and I heard you say filter down. I would argue that. I don't want it filtered down. Like I want, okay. We do need to work together to create that number one to, so to, to use kind of the the jargon that everybody's using, but that north star, we, as an organization, need to be, need to understand what our vision is, what the hell are we building? What are we trying to accomplish? Yeah. We should be able to ask anyone at any level in our organization, what are we here to do? And they should all be able to answer in basically the same exact manner. Oh boy. And if we don't have that, then what we have is confusion and a whole lot of with them, what's in it for me. What are my incentives , I'm gonna just get the biggest paycheck I can get. You just challenged 90% of the organizations I was gonna say, I know I did, even if you get just the senior leadership. And just, just talk to each of 'em and go write down what you think our vision is. why are we in business? just talk about that. Forget about, to get my quarterly bonus. Yes. So you don't get confused between what's the vision, what's the mission, right? Forget about all that. Just right now. What are we in the business to do? And then you gather their inputs, right. And you look at 'em and I bet you, they don't all align. They don't. And if we don't because of interests, right? Yes. Because that whole thing about building fiefdoms and kingdoms. Right. That's that's exactly what I see out there. Yes. At the higher level. So, well, the utopian world. Yes. You've got an agile leader who then interests other agile leaders. Not that they, they work for him. They, they all work together. Yes. In order to achieve a. Objective. Right. Can I just take a word out of there? Yeah. Just leader, right. No, but it doesn't even have to be Angard leader. Just the leader should of any organization. Should be able to convey and convince and have everyone in their organization. Organization have the conviction and the understanding of what they are there to do. Yeah. I wanna do a podcast specifically on. Being the, this is Trisha's podcast, by the way specifically on being the first product manager to a startup, when they decide that like the founder doesn't wanna do it, or the, like the founder is doing so many things, they need to delegate some things to save some of their time or to not work 80 hour weeks or whatever anymore. And they bring in a product manager because I I've done this twice now in my career where I've been the first product manager to a startup and separated the role from the founders. And what I found is you have to basically, you, you have to pull out of that person. what is the vision? What is, what is the future look like? Mm-hmm , you know what I mean? And sometimes you can pull it out word for word verbatim and you can get a real good idea in your head. Sometimes you have to kind of make it up and bring them along. Especially for companies that are, there are more than one founder mm-hmm they usually conflict on what they think the future's gonna look like. You have to meld the two together until all the founders agree. And then, then they're willing to delegate to you cuz until you are gonna carry what they want forward to the future, they're not gonna agree with you cuz they're like, well we could be doing more. We could do other things or whatever so I think kind of what you said you, they want a leader mm-hmm , they want, they want a leader in that position. where is that taught? In all your project manager classes and all your portfolio, whatever budgeting classes and all your little, get every nickel and dime and capitalize it over the next three years classes and whatever, like real short on leadership, all those programs, I think. Yeah, absolutely. That's that's not like, but, but, but that's the thing that propels organizations forward is we have the organization we're at now. We want to be three years, five years, whatever. In the future, the leader in X, Y, Z, we wanna have these specific companies or these specific industries or these specific types of businesses knowing that we are. The top person they think of when they think of whatever. And that that's the type of vision carrying forward, that your product manager, if I'm gonna throw a title on top of it. And a lot of times when I've been in that position, when we start to do the split, the way I describe to those companies to, to the people in those companies that are used to dealing with the founder, mm-hmm, people in support, people in sales, people, in operations, I try to explain to them, Hey, your founder is separating this visionary future thinking role from themselves. Like I continue to talk to them every day, every week, whatever the cadence is about where we are at now and how we get to where they want to go in the future. And that, that might be a little bit of the product owner versus product manager. If you were a startup, if you truly are a startup and you bring in a product owner for the first time, like somebody specifically to say, Hey, I have this vision of where we want to go in the future. I'm a CEO, who's also a founder of my company. I wanna bring somebody in who I delegate the day to day activity of working with a development. I have one development team, let's say one or two, maybe two development teams. I can't sit with them every day. It's taking too much of my time. I need to delegate that role off to somebody else. So basically I, the CEO slash founder of the company, I'm still the product manager, but I need a product owner to sit with my. Every day to carry out my vision of the product with that team, maintain a backlog, keep the backlog on track. You know what I mean, change, pivot as the vision and company and direction stuff, changes and pivots in that example, does that change anything we're talking about? Do you think? I think so. Are you saying, so I think the thing that's missing here is if we do not have the leader, the CEO and founder here also evangelizing and buying into this vision, then it's lost. I mean, no, no, I, yeah. Do you know what I'm saying? I mean, yes, you can assist this CEO and founder to hone that mm-hmm right. But that has to be owned and professed and just ingrained in, this is literally the foundation of the culture of your company. Mm-hmm and that has to come from leadership. Yeah. But in this example, I'm trying to go with the beginning of the podcast, the Mike Miller definition where like the, like the CEO obviously would talk to everybody. He talked to all the customers, they talk to all the business prospect. They talk to people who maybe would never sign up for the software. People that do sign up for the software, they're all over the place. Mm-hmm some of those conversations, they bring the PO with mm-hmm some, they wouldn't cuz again, when you're a founder of the company, Again, you're all over the place. You'd probably be in both camps. you you'd probably be laying down the vision for the future and you'd be a little bit and like, well, we need these key features. Mm-hmm to sell certain customers or whatever. you'd kind of be living in both worlds. So from, from the it's difficult from the Mike Miller perspective of, the PM is external focus. Whereas the PO is internal focused. It's a little difficult because. If you consider the founder of the company, a PM in mm-hmm embodying the spirit of a PM. Yep. They are doing both every PM from that perspective is both a PM and a PO mm-hmm . I would argue that the PO you, as the person who was hired on to take some of this responsibility off of the CEO, founder slash PM yeah. Are also a PM. So you are not going to be able to function solely as, as we have defined as a product owner that you would also need to be involved in those externally facing. So you would also be walking that line yeah. Between both roles. So then do we just call it product management, right? Yeah, yeah. Yeah. I would agree that the good PMs are doing both now we get into what what's, what constitutes a good PM. Well, you can't like like now we talk about incentives. Well, no, I mean, we're out of pocket for what, what we started talking about in this specific example. Like we're, we're talking about my experience in this example, in this example, it's the CEO and founder mm-hmm , but it could be anybody in the organization. It could be a salesperson actually a lot of, a lot of POS slash PMs, probably they couple with sales people probably more than they coupled with the C level executives and marketing. Yeah. In, in my experience in marketing. Yeah. Yeah. The topic of being the first. PM hire at a company like the, the reason that those C level people or the, the it's not even C level people. Mm-hmm, the reason that those founders, are working that long is because they are trying to separate that role. Mm-hmm , they're, they're doing multiple roles. That's why they're working that long. Mm-hmm , they're doing multiple roles and they brought you on so they can separate those roles. So the idea is you need to get in and wedge yourself between we, we started talking about this topic because we started talking about working with customers, stakeholders, use, whatever you wanna say, because usually the founder is the person who started working with those people. This, the founder is the person who started attacking the business problem, the customer problem. Right? And now you are. Kind of wedging yourself in between the two to say, Hey, you worry about like, if it's a CEO, for example, you worry about the, the, the general health of the business. And mm-hmm, , you know what I mean, other things and I'll worry about taking care of the customers and you have to kind of wedge yourself in there. Mm-hmm there, there are specific challenges as being the first P coming into an organization, especially a startup but I just wanna go back to an, using an analogy for that, right? Let's say you open a restaurant, it's your restaurant. You open it. You're the chef, you open it. You're you're also the restaurant manager or whatever else, 15 other titles, you're doing it all. And you work with your customers mm-hmm and you just don't have time to sleep. So you're gonna hire a, a line cook, right. So somebody comes in and does their stuff. so you've got some help there. Eases a burden on you a little bit, but now you need a sous chef and then you need a pastry chef. You just can't do everything yourself. But these people coming in have a challenge, these roles, right they have a challenge because they normally have to please you cuz you, you entrusted this person, you can't you hired them. Right. So they have to do right by you. But also they have to do right by the customers. Yeah. So same thing happens with, as a new PO into an organization coming in. You're not only trying to I guess not betray the trust Mr. Wood on you by the, by the CEO. Yeah. But you're also trying to win over those other people that are already there. Yeah. There's a myriad of people there. You're trying to win them over, say, this is a real role. I'm doing a real job. No, I'm not here to kick anybody out and no one's gonna lose their job. And I'll work with you. And you'll work with me. That challenge is unique as a first PO in an organization it might be there to a much more diluted level when you go in and replace a bad PO, because then people look at you and go, we've had one of those, right. It didn't work out. Yeah. Yeah same thing happens with agile coaches by the way. Right. Same thing. Right. You're not the first agile coach in, but oh boy, you're the end agile coach in. There's a graveyard of them, right? Oh boy. You're stepping over.'em to get there. And when you go get there, people go, oh, here's another agile coach. So it's unique that position I would, you've gotta pick your battles. Even worse, like agile oh man, you just hit on another podcast that we haven't even really thought about like that. We put it on this. Yeah. The graveyard of agile coaches, like interesting. Oh yeah. If you're burning through agile coaches is, Hey, let's talk about your organization for a second. We also talked on this topic, we talked about your agile leadership and that, that could be an oxymoron that has implications right there, that your leadership even cares about this. Well, so Stormy made a statement just a little while ago not agile leadership, but just leadership you said, right? I mean one and the same, but it doesn't even have to be Agile's. There's lots of leadership that is non agile. You're right. And that's the problem. Right? We talk about companies that we only know the names of nowaday. Sears Roebuck gone. Hundred plus year company gone. You wouldn't believe that 20 years ago, right? Kmart Kmart. I mean, there's a bunch of them. Yeah so when people say, ah it's brick and mortar. No. Yeah. That is not, you just didn't care about your customer, they weren't front and center for you. Oh boy. So anyway, so it's not, I, I personally believe this, that there is a distinction between a leader and an agile leader. Hey if you like this podcast like is described and if you didn't like this podcast send home nasty tweets. Yeah. Just include the $20 bill with that. That'll be appreciated. Let us know you thought of this podcast by the way that included some insights, but let us know down below