AA77 - Technical or Not? Backgrounds of Product Managers or Owners

I'm gonna read a few things here at the start of the podcast. Just kick us off. Right? So the person said they came from a nontechnical sales background into a product manager role. It was their first product manager role with no experience. They've been in the job a few months. They're feeling real hard imposter syndrome, they say, for example, sometimes I have trouble grasping what my developers and engineers are talking about. What they're saying in meetings, what particular technology or service or API or technical topic that they're discussing. They have a hard time following it. They feel like they should be doing more. They feel like they're left out. They feel like they can't follow. you're not from a technical background. So you can't re you feel at least that you can't hang with, the technical folks on your team. When they're discussing things, et cetera., but then you, you've gotta pull it back and say, why were you hired in this role? Were you hired to become part of the team as a technical representative, right? Or are you brought in to handle the job of a PM? Yes., fill in the blanks, scrum master, but you, you don't really need to know the technology because there are people on your team that know the technology. You need to trust that they know the technology over time. You'll learn by osmosis. Some of the concepts, you won't be an expert like they are by any stretch. but during that time, and it does take some time, you're gonna feel this way. You're gonna be, an imposter in your mind at least. And feel like you don't know what they're talking about. Therefore you're somehow not they equal, right., that they're not adding value. Let's put it that way. But the contrarian view to that, , is. You really are because you're coming in and asking those questions that are not necessarily siloed into a technical bucket, right. You're asking the business questions, the whys, and , the what, right? Those are the questions you're asking. The team is just so deep into solving things. Cuz developers are they're prone to solve things. Architects. when you ask the whys, it kind of puts a pause on the conversation about the technology and starts the conversation around not just the immediate solution, but surrounding the solution. So to take that example, right? So the, the developers might say, well, we can make this happen in this way, using this, this, and this filling all the technology they can use here., and you can come in and say, is that going to be scalable for a thousand users? How about 10,000? That's a different way of thinking than somebody who's just saying, well, just make it work. Well, this'll work. Cause the technology is sound. We know how to do. We have access to the technology and the knowledge. So things like resiliency , scalability, all the -ilities that we know about. Those are things that a product owner can ask and often they get disguised as NFR, but Hey, they're not so NFR as, as far as the customer's concerned the most elegant of solutions, if it doesn't scale. Right. What good is that?, so that's just an example of how you can add value, even if you're not technical, but that doesn't preclude,, this experience where you're feeling somewhat inept, somewhat incompetent throughout this technological discussion. Yeah, you, can realize the business didn't bring me on to get involved in the how, and I'm going to not get involved in the, how, however, when 90% of the time you're talking to the team, they're bringing up technical discussions and issues or, or they're taking your, this is what we should do and immediately going straight to solutioning. You're talking about how to do it. If that is the majority of the dialogue between you and the team, there's gonna be conversations where you feel that you can't hang yeah, for sure. I, I think this is where a prudent. PO/PM you know, scrum master would try and build out those skills from the team, by asking them to explain to you in plain non-technical language, what they're doing, right. Cause the team might be saying, for example, we're gonna implement this messaging solution based on kafta. Just to take an example, you have no idea what Kafka is, right? You could say to the team, explain to me what this thing is and why we're using it in plain language. And they say they might initially might struggle. That typically happens. They might say, well it's a messaging framework that we're using and blah, blah, blah. So at least now you learn a phrase, it's a messaging framework. So your knowledge grows over time. Well, I'm anchoring back on imposter syndrome because in the case that you just brought up, Hey we need to expose this feed to other customers in the business that they can consume it. Other teams can consume our output okay. We're gonna go with a Kafka solution and publish, the feed through that. Yep. Okay. a more realistic scenario as the PM comes in mid project, Kafka's already been set up and has already pushing out there, either enhancing it or modifying it or doing whatever. and they have to ask what is Kafka? And then the response back is, oh, well, it's a platform where we have consuming APIs and we publish topics on APIs and consumers around the business, pull those APIs in. I'm sort of digging deeper into your response, but sort of also accusatory in what I'm asking. Sure. On purpose, because I could see the development lead answer to the non-technical PM immediately be it's complicated. Just don't worry about it. Yeah. It's an API solution. Well, what's an API. Don't worry about it. And people might be like, oh, well, that's like, you're being a little hand wave or whatever, but I don't like, I don't know, in my experience, if you have a deep, especially a solution architect or a business architect or whatever, or, or, or a development lead , and then you bring in this PM, especially if you're a PM for the first time you're going to encounter discussions, attitudes of why do I have to explain this to you? Seriously? You don't know the minimum technology that we're dealing. Like, how do you not know this? And you're gonna try to be in the middle of my conversation. You're going to deal with that attitude and people from outside, who, who may be listening to this podcast maybe, maybe not, might be like, what? That sounds ridiculous, Brian, but actually you're, you will deal with that. You will absolutely a hundred percent you're right. You will deal with that. I think it, it is up. A smart individual is coming into this who encounters this to say, look, a customer could ask you that same question that I asked you, right. Ultimately, are you able to explain in plain non-technical language? What the heck it is that you're doing basically? If somebody says, yeah, we got this right enterprise bus or what, so I know what a bus is. I know what enterprise is. Explain to me what you mean here. Right. And if they cannot relay that, then I'd say that's a deficiency in your team. I like where you're going with that one. because it's challenging some status quo here which is we do that a lot here, by the way. Should, should your developers have to have the business acumen to explain to the business why they are doing what they're doing and how it works in clear non-technical language? I don't know. A, I don't know a way to cushion what I'm trying to say. They, I think I personally feel, I want your opinion on this too. I personally. Yes, they should be able to do that. Here's why think about the medical profession, right. And it's where storm is pain counts bigger than mine. a physician can explain to the patient in plain language, what the heck it is that's going on. They do not have to get behind the medical mumbo jumbo, which is usually lost on most people. They don't have to get to that. and that's a skill that a physician has to be able to say, we're going to do this instead of we're gonna shave the lateral aspect of your meniscus or whatever the heck it is that all of those words are lost on the average patient. I love meniscus. Meniscus is a good word. Meniscus I mean, this is something I can speak to because it's where I come from. And I'm going to speak to my personal experience in the organizations that I've worked at, every one of which has been very unique. In , their problems, their organizational structure, their culture, the way in which their teams are structured and built. Right. So all unique and all that does need to kind of come into consideration. First of all, as a product owner coming in, assuming without technical knowledge so assuming then that you have some domain experience and in the example that you gave this product owner was coming in as a product owner with no technical experience, but came in from sales,. So, or a product manager, I think but sales does give them some domain knowledge, which could actually be very useful in that role. It also could be detrimental if they don't kind of walk that line so pretty carefully or understand their role as a product manager and, and, and make sure that they're kind of, yeah. So, so just saying, but they do are bringing some domain knowledge here. Right. that said, I recall coming in as my first product owner job and within the first, probably three months, I was. Lost. Oh my gosh. With all of the acronyms and the things that they're throwing up on the board and Mongo database and angular and Kubernetes and microservices and all these things that I didn't I started to get a bit of an understanding of what they did. but I would say that it was really important for me to collaborate as a part of my scrum team and when needed to communicate with my scrum master in saying like, if I, so number one, I didn't ever have a problem speaking with my, my team. Right. They knew that I was coming without number one. I was very, very transparent about the fact that I'm not coming from a technical background. I'm gonna be leaning on you for that. You are the experts in this. And I am trusting for you as my team to be the experts in this. Okay. Number one, number two, as questions come up. Number one, I don't, I don't pepper them constantly, but as questions come up, I'll make notes to myself. I might have a conversation kind of afterwards, or say, Hey, I need to understand this a little better. Or I think I need to understand this a little better, but to your point, I never had an issue with anyone on my team. Pushing back who didn't immediately get up and go to the whiteboard and say, all right, here's what a microservice is. Here's what Kubernetes is. Here's where Mongo kind of fits into that. Let me show you the connections. This is why we do it this way., very simply put, and I will tell you the benefit of that. So it allowed me to your point to speak to for instance, a customer. But I think the bigger benefit of that was when it came to planning. All a sudden, I had an overarching general understanding I'm not coding. Right. But when we're starting to speak with the dev team in planning, all of a sudden I'm going like, wow, is this a bigger job? You know, how big is this? How many pieces of this does that this actually incorporate? And so then I start thinking about, all right, let's think about this as a team, how can we divide this up? How should we is, is this story actually a story or depending on how you how you're set up, is it a, a feature or is it an epic or should this story be split out in some specific way, but it helps me as a product owner to help kind of guide that conversation. I don't need to have a full on understanding, but what I do it really, really helps me to facilitate that meeting going, like, let's think about this. The other thing I found is that asking those questions and particularly in the context of a, of a team meeting or a team event of some type. So planning, for instance, if I'm asking a question, help me understand this better, because that's, what's gonna help me to collaborate with the team on how how do we split this out most appropriately so that we can give a deliverable piece an increment. So then all of a sudden I have multiple. People on my team up there talking about it, and collaborating, going like, no, will have you thought of this? Wait, about what about that? Wait, what about we have these regulations? Are we actually capturing that? all the sudden things discussions are being had just simply by virtue of them explaining simplicity to me and then going like, Ooh, it's not quite that simple. Yeah. So there's some real benefits to that. And then I would say as well, every organization I've worked with has different tools, different applications and utilized in very different manners and segregated across teams in very different manners. So every place that you start, you are starting green again, and you have to start not understanding much being confident to ask questions. Building , the relationship with your scrum team to be able to have them comfortable in answering those questions without feeling like they're being trampled on or dictated to. Right. Truly, I'm looking at you as the expert, particularly as someone non-technical tell me how this works Cliff's notes, version layman's terms, and that helps me to understand the overarching vision and potentially also makes me start thinking, okay. Ooh, have I not thought of maybe some , some dependencies here? Do we need to get some other teams involved here? Yeah. Now, rather than later. Yeah. So there's some real fantastic things that come from those conversations. And I think that they must be had maybe planning is the best place to do that. It could be something else. I'm not sure. And then what I would say is that the first couple of weeks you're gonna be clueless. The next couple of weeks, you're gonna be a little less clueless, three months in, you're gonna be feeling a lot more confident, six months in. You're gonna be like, you know what, I'm following everything in this review. I can see when they're pulling up this API and I see the call and it's successful, you know what I'm like? All right, I understand that, right. I don't understand how they did it, but I can see they showed me that they went out, , they were successful in the call. my point is, is there's a learning curve, every single job that you work at dependent on the tools, the makeup, the culture, and the way in which the teams are divided and in regards to their responsibilities. So those are the, those are some of the things that I would think of initially in my experience. I guess the what's sticking in my mind now is I've been a part of organizations don't have product people and try to bring them in for the first time so they have a very strong development centric organization that is shoulding. Usually the like the development lead or the CTO or the director of development, somebody like that, like shoulders, the product responsibility. They're, they're the one kind of jockeying, like what do we do in what order? The prioritization of the job. And they're looking to offload that to a professional product person. Like they, they're very happy when a professional product person comes on board because basically my, my one, my, one of my first one on ones had companies in that position is with people in those roles to say, would, would it make you happy? If you never had to answer the question? When will this be done? How come you're working on this and not this? And you never had to answer that question ever again. Right? Cause basically that like here I am, like, I'm here to take you out of that conversation, that position of being in that I'm not, I'm not here to take you outta the conversation, right? We're gonna have the conversation together, but I'm here to take you out of the position of being the one that the business pins down to be like, why are you working on this? Mm-hmm why aren't you working on this? When's this gonna be done? How much longer until whatever, what can you stop to? You know what those conversations. Yeah, yeah, no, that those are, those are very good points. I start off something similar by just asking them what keeps you up at night, you know? And they go, well, We don't know what we're releasing when et cetera. And yeah. So then you come in and say, well, what if we take that off of your plate? Cuz your plate's already full, you have a role that you're working on right now to fulfill. So yeah, I agree. they're very thankful when you go in and take that off of their plate, but also at the same time, if you're not careful, it becomes one of those. Well, so off my plate on someone else's but that someone else is now coming in just to go back to the imposter thing. Mm-hmm you are not brought in as a technical expert anyway. So going in, you should sit that expectation, like in your interview, just say, look, I'm not the expert on the technical side, I'm the expert on the product side. You have experts. I will be partnering with those people. Yeah, yeah. I guess now is the time to put the asterisks in this conversation to say, we're not talking about specifically a technical product manager, that that type of role would they, they do bring you in I remember going through some job interviews for technical product manager slash owner. I don't remember which one it was where the, the, all of the products were APIs being consumed by developers, not internal developers, external developers. So you actually had. But all those customers were developers at other organizations. So any questions that they might ask you were going to be technical in nature? So you, as the product manager needed also to be technical in nature, to talk to your customers who all were technical. So it like, that's a very specific yeah. Yeah. You know what I mean? but, even in that situation, I feel like I've heard this a, a bunch of times on podcasts I listen to and, and, and articles. I read especially the Silicon valley PMs or PMs that are like very early in their career, they'll say, well, in that situation, you've gotta partner with your technical lead or your architect or your solution architect to kind of help you along and explain things. Or if you, as PM are dealing with a topic that requires you to dig super deep into a technical solution to talk about, like, for example, if you're maybe migrating to a different. Or if you are upgrading a major version the accomplishment outta the other side is we do all this work and if we do it all correctly, then we are better positioned for the future. We have lower business risk, but the users see no difference. I was once part of a project where the, the backend was all file based. And we added a database to the middle of the system and replaced the, the files in all the different folders. And that was the heart of the system. So we went from that to a central database. So it was like, basically we were like pulling the rug out or pulling the foundation out from under the house and replacing with the new foundation. And the measure of success was the customers didn't see any interruptions. Yeah. What their normal. Yeah. So like that as a PM in that situation, it's not super glamorous. The takeaways from that are all in the reduction of business risk, which is not a super sexy feature to sell to customers, but important, but for the business where they wanted to be in the super important. Super important. So internally, no, there's no problem. No pushback from a customer's perspective, it was like, well, why are you not delivering features in quarter two? Like I don't, I don't see anything I care about in quarter two I bring this broad category up to say the advice that I've read on blogs and podcasts and stuff is just partner with your tech lead, and they'll kind of help you through these things. Okay. the issue with that advice, just partner with your tech lead is that's a rabbit hole. I feel it's like, where does that end just partner with your tech lead? Cause cuz I, I have seen companies where the product people basically they, they get in the mode only talking to the tech lead and they never talk to the team. And then they basically like now, now you're waterfall, I'm just gonna hand off the tech, Hey, I need Tina do this upgrade, figure it out. Mm-hmm innovation's been stifled. You now have like circumvented the whole purpose of having a self organizing team, right? Yeah. I just wanna add to that point that there are some industries where you kind of cannot escape knowing some technology. I'll give you an example., when I was on my gig at Boeing, the customers were other technical customers right. People that buy components. Yeah., so they can kind of Lego brick, their own pieces together. As a product person, anybody really. You needed to know something now, did you need to know the mill specs and all that? No, but you needed to know what the thing does, how it works, how it's useful, where it fits into the bigger ecosystem. If you couldn't talk to that, you have no choice, but to bring somebody else in a luxury you don't always have, right? Because you're brought into these meetings where your tech people aren't there and conversation comes up and a question comes up and it's directed at you. And if you're not able to answer that, I mean, your answer cannot be, let me get somebody else in here. So in those situations, you need to learn at least the basics of the product. And that happens over time, but it doesn't happen. By osmosis. I wanna tell you that because I've seen that fail. There's a lot of turf protection, et cetera, going on, people don't wanna share. So the poor product person or PM, or scrum master whomever, they can ask in all earnest, , they're not gonna get the, the cooperation. So what they have to do is take it on themselves to learn. That's where they have to go the extra mile and say, I'm gonna learn about this product, cuz then I can stand on my own two feet and talk about it. There are very few industries. The other one I can think about is perhaps pharmaceuticals, maybe you need to talk about some things around the product that you are, you. Manufacturing or whatever. So I would say if you're on a team where you have people who are protecting, and what I heard was a complete lack of transparency that, that literally engaging in lack of transparency, then that's a problem that actually needs to be resolved. Right? Absolutely. So that ends up becoming and, and festering becoming a much larger problem, particularly over a period of time. Yeah. absolutely. In regards to just getting really quick back to the psychological safety in the original example you gave, I would argue that the salesperson coming in and this, this plays into what you're saying does not, and should not be expected to be technical. They aren't initially. Okay. remember when I said earlier that every organization that you work for is gonna have a unique set of applications of procedures of ways in which they're organized their teams of responsibilities, so on and so forth, which means no matter where you go, you're going to start with a learning curve. And yes, it is up to you on the scrum team to learn about the product that you are responsible for. Yeah, I do believe that that should be very open., and we should have a very collaborative and, a team effort amongst the entire scrum team, scrum master product owner and the devs. And if that isn't what's happening, we have people who are hiding and protecting things that tells me, Ooh, we've got some issues here, far larger that need to be addressed upwards. And those aren't gonna be things that I'm gonna necessarily fix from the ground up. I can attempt, and I may be able to make some segue in my little team, but that tells me that there's a far larger issue going on. So you don't need to be technical in the beginning, and you do not need to be a developer years into it, but given time you should be exposed. And some of it does come by osmosis, but a lot of it's gonna come through just curiosity. And the need and, and the the necessity to, to your point, understand the application, the product, whatever it is you're responsible for and collaborating with users, marketing leadership, absolutely your, your developers. and then when it comes to potentially some issues with culture, I I'd be talking to my scrum master, my agile coach and going like, Ooh, we've got some issues here. Like can you help me out with this because I'm running into a wall here. And then I'll just tell you in my experience the best experiences that I have had working for companies was, were ones in which the scrum team was involved. In my interview, now it wasn't the initial interview, but the scrum team was involved in my interview. And what that did was give me the opportunity to immediately set expectations. They knew what I was coming in with. They were permitted to ask questions. They were permitted to explore. They were permitted to get kind of my work ethic and see how I would typically maybe handle a particular situation. And they had a voice in, if I was a product owner that they wanted on their team and that's what I wanted. So I was accepted in with the understanding that I didn't have that technical knowledge, that that was going to be a responsibility of theirs to help, to impart on me. And that's something that I made clear on that. And I think that that was a fantastic way again, to start immediately to create trust in involvement, relationship and ownership. Yeah. That's I agree. First of all, that's awesome. You know, I think when you first are introduced as that non-technical person in that environment, the first thing you should do is go in there and tell your team. They are the experts, right? Mm-hmm and you're gonna partner with them. Mm-hmm so then it's clear and the other thing I would say expectation, one B would be to say over time, they will bring you up to speed with this stuff. To your point, it's up to the individual to go seek out that or those opportunities cuz they don't present themselves. And if, if I'm going to add anything, especially add anything in a passive aggressive manner, passive aggressive, he's not gonna the theme, the podcast technical or not technical, not having a technical background. Doesn't absolve you of having a responsibility of learning your own product. Mm absolutely learning and using and testing your own product. I think immediately of all the products that I've been at PM for, like I had to learn them all. Usually it's the testers on the team that I'll go first because I, again, my background's in testing, so they I'll go through them first to say, Hey, how do you test the product? And I found, that's an easy segue into figuring out how to use the product, finding their test scripts and figuring out how to walk through them, or if they, or if they're mainly an automation shop, maybe I'll go find whatever variables are stored to figure out what I should put in and what fields or whatever you that's, cuz you're technical to begin with. You can do that. Yeah. even the example I used before where you you're, you are like, you are in like the FinTech space and all your products are APIs. I mean, you, your product person, I mean, would they benefit from just sitting down and learning how to use postman? How like out, like, think about like how long would it take them to sit down? Not everybody's wired that way. They, I, now I was not an expert, but this was something that my dev team helped me yeah. To learn so that I understood when we were developing APIs so so postman was explained to me, I guess the reason I brought all that up is to say what concerns me about being nontechnical and saying, okay, it's okay to be non-tech you don't need to dig deeper. You don't need to do that, just pass it off to the tech lead. that worries me because I've been in a lot of environments with, developers who basically are code monkeys or offshore teams that, that is where I've seen this the most quite honestly is you hand off the offshore team. You're basically not allowed to talk to the offshore team. You go through a develop and lead, and then they most. Message to the offshore team, or relay to the offshore team. Yeah. That's why most horrible experience I've ever, ever experienced as a PO so bad. I so bad. I agree. Yeah, I agree. Absolutely. If you're a PM without a team, I'm very concerned of like technical or not. I'm very concerned. Right? So no team. Yeah. Yeah. Well, I mean like the way your company will describe it is, well, you do have a team it's just, they're they're this technical person is gate keeping your team. That's a stage gate in the traditional project management world. So now you're introducing waste let's pivot to the PM without a technical background, some pros let's pivot to some pros the immediate pro that I think of is you're. When you have a separate product organization inside of your company, I would expect the product organization to be building and owning and maintaining and updating the roadmap. Right. When I say roadmap, there's people out there, like no roadmaps, like I'm not trying to get into that conversation. That's a whole different podcast. No. Yeah. It is a different podcast. When I say maintain the roadmap, what I mean is like the, the, the I almost don't even want to name it, like the epic level and above like the higher than a story level higher than the team level is what I'm saying higher. Higher is not even a great way to phrase it. Like not refine enough to be consumed by any one team in its entirety, a product plan, a portfolio plan. I mean, all of those things. Yeah. So, I mean, depends on what organization it is, how it's defined, but, well, I like, again, like now we're in another podcast, another, another podcast. Cause planning like a planning is another podcast. It's not quite a plan. It's, objectives at the business level. Mm-hmm that have not been broken down into achievable segments yet. The reason I bring that up is because I consider it a pro for someone who does not come from a technical background, I, this is my hypothesis. I have no evidence to back this up. I think that they are in a better position to stay in the goal, objective oriented mindset and not dig into solutioning to say, oh, you want, oh, oh, you, you want more engagement for raising engagement of our website by some percentage, it's a significant percentage. Cuz the business probably won't give you a real percentage. So you'll say, oh. Well, that means I need to go add this function to my website and go put this move this around or whatever. Yeah, you'll go. I think of the businesses I've been in that have not had product people and they've just had developers and the developer will hear a request like this and immediately go into solutioning and hand that solution to a team. For sure. I need you guys to redesign the website to change this and move this here and do whatever, because I think if this is here will have a higher engagement rate. Yeah. So immediately to solutioning. Yeah. You, you spot on there. I mean, an architect or a tech lead would definitely be thinking about that. Right? Whereas somebody at a higher level would simply focus on the problem at hand, which is the what, right. Mm-hmm what are we trying to do? Mm-hmm and then they take the, what they take it to the team and say, here's the what? And by the way, here's the why mm-hmm right. Without that, the team's kind of left wondering, so you need both, you need the what and the why, and they completely stay out of the how, because that is the purview of the team. Let them figure it out. You have some smart people there so they can figure it out. But that's hard if you are, and this is the flip side of it. So if you're a non-technical person it's to your point, it's a lot easier. To do it that way. Right. But if you're a technical person and, and let's say you're in charge of not just the, the architect level, you're in charge of the product level. So you're still on the product side, but you have a technical bent. Yeah. It is so difficult to not go into solution mode. You're immediately saying, Hey we should do it this way, this way, this way. Right. By doing that by every single edict that you put forward saying, we should do it this way. Mm-hmm you are blocking out an infinitely large number of other possibilities that the team may come up with. Mm-hmm right. You're never gonna even have the discussion of what could we do. That's right. You are bring, it's kind of the same back to like, just partner with your tech lead. Well, I mean, when you partner with your tech lead and you give them the business problem, Hey we need to get more engagement on our website. The danger there is that they're gonna turn around to the team members. Again, it's even more dangerous of the team members in an offshore team and they won't come to the team members and say, Hey, we have a new business problem. It's to get more engagement on the website, what do you guys think? What could we do? Let's let's pull up a whiteboard and put just throw some brainstorming solutions up there. the more likely thing that I have seen only, only in my experience is the go between. Will design a solution themselves and then hand the tasks to do that to the team members. Absolutely. I've seen the same thing too. Mm-hmm they prescribe to the team members, whether they're offshore or not. Yeah. This is what we're doing now. And the team members, then aren't even afforded the opportunity to question why mm-hmm , which means we're building that person's solution period. Exactly. That's so frustrating to me. Yeah. Yeah. So I'll tell you, so one of the things that I thought of is that so this both of you mentioned something and that is kind of the, the what and the why, and you mentioned specifically, we need more, what was it? So more engagement engagement on the website mm-hmm so is that really a, what so is that, or a business problem? So I would actually go, is we need more, right. So what I would wanna get to is the problem. Why don't we have the engagement that we need, I would wanna understand that what, and that why and dig deeper and, and dig deeper and deeper sometimes uncomfortably, so the lack of in customer engagement, isn't the problem. Why do we have lack of customer engagement? That's the problem. Then we, then we can start working on a solution. If we understand the why, then we can start getting into the actual problem. So that's where I start really, as a product owner product start picking apart because a lot of times business comes to us and say, we need this and I'm going. So I, and I do, I I'll try to pick that apart, which can be uncomfortable., but a lot of times that does unearth some, some more granular issues that fundamentally we are trying to solve, which are gonna lead to ultimately the increase in customer engagement. Yeah. That's excellent. Point. I believe you can only do that. If you come in from the stance of you non-technical person, cuz the technical person will go down the other path in the decision tree, right? Say we need this. Okay. This is how mm-hmm . Whereas to your point, you would come in in and say, why don't we have that now? Mm-hmm right. Let's look at the causal factors there mm-hmm and see if we can remedy some of those. Yeah. in the spirit of arguing agile or in the passive aggressive spirit. I don't want make one, it could be anything at this point. There's three different cases. This is, this is the German three. Yeah. But yeah, there's three different cases is the PM who comes from a technical background, the PM who comes from a non-technical background and then the brand new PM. Mm-hmm, straight outta school, brand new PM. I feel the case you're talking about now of the, the person who's like, oh, I'm gonna go straight to solution or, oh, I know how to solve the problem and jump to, it could be the PM with the technical background, but it also could be the PM. Who's straight outta school, or has very little experience being like, well, they told me that this is that's right. It must be true. Right? Yeah. They don't question it. So the non-technical PM with industry experience in with domain experience in this case, I would hope it, like if I had to put money on that's, I guess that's where I'm going with this example. If I had to put money on the person that was willing to question the status quo. In this example, I would put my money on the PM who doesn't have a technical background, but came from industry domain expertise to say oh, you, you think the answer to this problem is to increase engagement on website by 20%, 50%, 80%, whatever it is, show me what leads you to believe that that is the solution mm-hmm okay. because that like the bravery to ask that question again, we're going to the principles now we're going back to the principles, right? Right. The bravery to ask that question I almost don't even want to get into this cuz Ooh, look, I can't go 82 minutes again. the bravery to ask that question. I almost wanna say like, that's not necessarily related to any BA PM background, domain background, technical non-technical it's we've come to another level now the most effective PMs that I have worked with are willing to Wade in and question, whoever is asking for things at every level to say like, please show your work. But not every not every customer who's given you a lot of money, not every VP. Who's got a big, shiny title, not every highest paid person in the room. They may not take kindly to being questioned, I guess that's my, It's my opening to this topic. Yeah, no, this is a great topic. I think it takes a certain amount of how should I put this? Chutzpah, to question that, right. I think if you have that technical background, you automatically don't question that because leadership's telling you, this is what they need. So you're gonna just go ahead and say, that's a given, right? They're saying they need this. Let's go make it happen. As opposed to somebody who comes in and says, do you, why? Right. Yeah. Well, I mean that like not, not cool to interrupt, but like the, no, that's fine. The arguing point to that is like, if you can deal with the low hanging fruit and knock off the quick stuff and get some quick wins, especially in your first 90 days as a PM, your first 90 days, you're looking to knock off the low hanging fruit as fast as possible to prove that you can do, especially the, the more dangerous the environment. the more you're looking to do this. Like, let me knock out some quick wins and prove that I'm the go-to guy. And that is reality to new PMs. And almost everybody will tell you in a new PM, like go after this stuff, that's low hanging that you could deal with quickly. Yeah. In order to establish your credibility. Absolutely. Yeah. You're right. And that's just human nature. It's gonna happen no matter what. But that's still short lived, cuz say you are in now, 90 days are over. You're at 180. What happens if you continue the same behavior, you're just gonna fall in with the rank and file. You're not really challenging the status quo. And that might be okay in certain organizations where they don't want you to. Yeah. they hire you because they want you to just stay in your lane. Right. Yeah. And that's, that's where you say, well, 90 days are come and gone and under 80 yeah. Time to dust off their resume. Yeah. And I would say that there's a lot of organizations that actually start and never give you that 90 days. Maybe, I mean, low hanging fruit may be a great way to prove your worth, but might not in all situations be the best approach. But even I think more importantly, my point is that might not be an opportunity that's given to you as a product owner who is really not an owner of anything. Oh, no doubt. Right. So your example earlier was Hey, you're the product owner of, and, and I've been in this situation of a completely offshore team, which I've worked very well with offshore teams in this particular instance, it worked horribly because I was only permitted to have contact with that one lead dev who divvied out and was the leader and was making his mark. And so this gets back to as well as thinking about, okay, what incentives are driving these people for these actions? And I was seeing that left and right, and the incentives were very self-serving and , damned be you Hey, you're if you're not serving my purposes that sure. But there's a couple of things I wanna just say in regards to the three stances and that was PPO new to technology completely, but has some domain expertise versus, so a technical background coming into P NPO mm-hmm versus new to the industry. Graduate has some certifications, no experience in either. I would say that so much depends on the organization you're working with. You mentioned mentorship and, one on ones and guidance psychological safety has come up multiple times trust culture but what I would say is that every one of those three types of PMs and POS can be absolutely and wonderfully effective. Sure. Yeah. Like, right. So, the product owner with a technical background doesn't necessarily always delve into the how, right. So it may be something initially, particularly as they're learning that PMPM role, that might be difficult, but if they understand their role and they understand that's not what they are supposed to be doing that may be a practice in understanding your role, understanding overstepping, you're probably gonna make mistakes because it's in your nature, learning from them pivoting and becoming a better and better product owner as you go. Right. Additionally that new to tech. Domain experience, they can actually come in with some real bias in regards to the needs of even though they can be very enlightening, they can also be very biased and potentially be guiding based on their personal experience in the wrong direction for a product. Sure. Right. So there's some, I mean, it really just depends. And then that new to the industry completely can be somebody that happens to be mentored by someone that is absolutely fantastic, that understands they're new to it, and that are guiding them absolutely fantastically. And here's someone that is on the path, none of those are going to be perfect all the time. But as long as they're in a culture that has the opportunity and the safety to fail, learn, and learn from those mistakes and iterate from those. Yeah. They're all gonna get better as long as that's what they're, they're wanting to do, and they have the culture to do it. And it's not just this control and command kind of situation. Do you think that any of those stereotypes would be more prone? To being affected by the loud, loudest screaming, stakeholder, highest paid person in the room. You know what I mean? Like potentially. Yeah. Cuz like we talked about the, we talked about the, like the bravery in a culture of saying like, Hey, show me your evidence. again is assumption this is not based on anything. I think that the the person straight outta school that was hired into this PM role or whatever, like I think they're probably the least likely out of these three pools to say oh, show me your evidence, Mr. Importance, stakeholder or perhaps, or Mr. Director or development or director of product, for example, like they could be questioning their own boss, a VP product. For example, to answer the question. I would say that , I have known people new out of school who are so freaking full of themselves. They are 20 something year old. They know everything there is to know in the world. They did their interview and know more than everything that everybody interviewed with them for I mean, so I think it depends a lot on the personality. So extroversion versus intro introversion versus certainly culture plays into this. I just, I don't think that there's a stereotype that you can peg down that there's too many variables. I constantly question to the point of my own detriment have always been this way, like Sunday school, they saw me coming. They're like, oh God, stormy here. So, I mean, never been afraid to ask a question. And never been afraid to kind of speak truth to power, which has been, has served me well, but has also been very detrimental. We have this discussion all the time about we have it about Agile Coaches. We very rarely have it about product. People of there's a personality that like there, you have a natural talent to being. an agile coach, scrum master agile coach. The same for this discussion. If you mainly think about yourself in conversations and self-interest is a top of mind, you're probably not gonna make a great agile coach. Mm-hmm if you really actually care about people and it, like, it bothers you to have bad relationships with people, like you're prob you're probably on the right track. Hence my recent decision to really pivot in, in concentrate on scrum mastery and agile coaching and, trying to figure out where I fit in that realm, because I from a personality perspective, I feel like that's just a better fit for me, perhaps, you know? So we'll see. I mean, we'll see how, where that goes. I don't know, but oh, scrum master is a better, better fit you think? perhaps the other thing is actually, I mean, the other thing that I've actually done a lot of soul searching over is user experience, user research specifically which I very much enjoy it's worth trying out one or both of those to see what really resonates and I would say, it's not that I don't enjoy being a product owner. I do. I love it. I think it has to do with just the turmoil particularly right now. Like it's, it seems to have come to a head, at least for me since I've started. And I think we touched on this , there's just such a disconnect and, and no consensus as far as what a product manager versus a product owner, are they together? Are they separate? Is there hierarchy? And it's just, there's so much confusion and so much politics with it that it's, that, that is what's disconcerting to me. And it's not, it's impacting the ability for me to do my job properly and well, and I think that that's been my motivation to say, how can I pivot and make myself valuable and happy?