Are you a Product Manager or Product Owner?
Do you sometimes feel like you are an imposter?
Join Product Managers Stormy Dickson and Brian Orlando and Enterprise Agility Coach Hemant (Om) Patel as they talk about the reasons, and what can be done to minimize or overcome imposter syndrome.
#impostersyndrome #productmanagement #career
0:00 Topic Intro
0:12 Empowerment
1:33 Push-Back on Empowerment
5:12 Being "New" At The Company
9:48 Choose Responsibility
12:47 Future Leadership Panel Interview
14:38 Influence
16:34 Politics or Leadership?
19:58 Being a Better Communicator
23:59 Bringing People Together
28:27 Repeating Yourself
30:33 Money Metrics
34:17 AARRR Pirate Metrics
37:39 Being Responsible for Money
39:19 Dated Accounting Models
41:31 Challenging on Financial Literacy
43:07 Never Stop Learning
45:24 Wrap-up
= = = = = = = = = = = =
Watch it on YouTube:
https://youtu.be/lQCDVxGY_Fk
Please Subscribe to our YouTube Channel:
https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1
= = = = = = = = = = = =
Apple Podcasts:
https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Google Podcasts:
https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy5idXp6c3Byb3V0LmNvbS8xNzgxMzE5LnJzcw
Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
Stitcher:
https://www.stitcher.com/show/agile-podcast-2
= = = = = = = = = = = =
AA106 - Imposter Syndrome in Product Management
If you have imposter syndrome and you're a product owner or a product manager, this is a podcast for you. I don't often look directly in the camera let's talk about why you have imposter syndrome. Let's talk about what you can do to get over. Imposter syndrome. And I think the first thing that sticks out in my mind about getting over, getting or over around, imposter syndrome is, dealing with empowerment. Mm-hmm., like actually being empowered with product owner responsibilities does a lot to actually get you over the feeling of imposter syndrome. If I was a product manager at a feature factory where I'm just like fed like sales feeds me things and executives feed me things that, that would be one thing. cuz then you're always guessing where your next meal's gonna come from and, I'm just like, you're living on the street. That's what I'm saying. Right. if you actually are empowered to figure out solutions and prove or disprove why things will or won't work I think where I'm going with this long-winded summary, I think where I'm going with this is if you have the ability to ask, like what makes you think we should implement that feature and you don't get fired for asking that, I think you're pretty good. Yeah. I think some of that, kind of blends into product discovery and things like that. But Sure. You have to be empowered to your point. Right. and, and leading without authority can also, , I think gets into this. It doesn't matter what role you have, but specifically if you're product owners and product managers, more so, if you have no authority, , the real authority that you know, you can go out and talk to customers. You can bring their feedback in, figure out the, the why and then the what. If you don't have that, yeah, you may have imposter syndrome because you're always in self-doubt. So yes, potentially, but, you don't necessarily have to have that in, in place to have imposter syndrome. I think you can, you can be empowered at least to some degree and still have imposter syndrome. you think? You think so? yes, I do. I was gonna quibble with the, the, the word, um oh boy. I, I forgot the word now. You didn't say accountable or responsible, you said you have authority or something like that. Authority. Yeah. Leading without authority. Yeah, leading, yeah. Authority. And, and, and I was gonna push back against authority. Like, I don't necessarily think you need authority in any way, shape or form. I, I think you need empowerment to say, Hey, you can talk to customers whenever you want., you can uh, as long as you prove or disprove your experiments. And as long as you're showing evidence along the way, b basically an experiment, log along the way mm-hmm. Then we're gonna trust you. Cause you're, we, we empowered this piece of the business to you. I guess I'm trying to talk myself into agreeing with you, stormy. Okay. Because if you're empowered with that piece of the business, I guess you could still feel that like now everybody's counting on me, and now that is gonna lead itself into a positive syndrome. Yeah. I, I could see that. Even, even if you're doing good things, like even if you're having positive results Yeah. Mm-hmm., you're still, there's that, that, that potential for that the, that feeling of inadequacy. Yeah, I, I would stand pretty firmly on that belief that that imposter syndrome can happen with or without empowerment, may be more prevalent. I'm trying to think. I almost think, I almost wonder if this would go both ways, whether it be more prevalent if you're not empowered or if you are empowered, if you feel. Pressured. And you might even be more apt to feel inadequate. If you actually are empowered, like hey stormy I have this product uh, X product. Zed. I like saying Zed. Zed. Zeds a good word. I I have product Zed. I'm the owner of the company, founder of the company, ceo, whatever. I'm like I've technically am in charge of product Zed but I got other things to do. You are in charge of product Zed now. And I'm out like when you, when you need me for expertise or you need me for leadership or whatever to make a call in case you're not sure or whatever. Mm-hmm., come get me. Other than that, I don't even want to know. I don't want to, I don't wanna look at it. Whatever. Well, don't You want to check the roadmap or whatever? Nope. Don't want to do that either, cuz I'm really busy with the rest of the business. I could totally see where you feel like you're, whoa, what do I like? I'm in the middle of the ocean. Yes. With, with no piece of wood or life raft or anything. And I'm just swimming and that like, , it's ocean. Everywhere I look like, what do I do? I could see that. I think that you described it very perfectly. I think it, I think it's way worse when you're not empowered. I think that wondering if you're even making a difference. Mm-hmm. Uh I, I could argue both sides. That's, that's, that's the interesting part of this to me is I could argue the side of if you're just constantly being told what to do, hey, just relax, cash out, take the input. Know that you're making people happy with their deadlines that are all in the past, by the way. Cause that's the only when you're in that culture, everyone brings you deadlines in the past. So you're constantly disappointing people by succeeding, by the way, but I could totally see the panacea of everyone just tells me what they wanted to do, and then I don't have any imposter syndrome at all because I'm just taking request number one and implementing a request number one, and taking request number two and oh, oh, request number three came in is higher than two. Oh, stop working on two. Work on three. You're just a backlog person at that point. Mm-hmm., really? But what if you are a really good backlog administrator, or you think you are? You know, or maybe you are, but that's all you're doing. Really, really. And you're really good at it. Really good until they eliminate your whole division. right? All right. You have imposter syndrome for whatever it's worth. You have it whether you have empowerment or you don't have empowerment. You have it now. What? Okay. How do you deal with that? Well, we can't, well, my, my, my proposition was you actually need to be empowered. No one thing is gonna get you over there. Over, over the hill. Mm-hmm.. Over the . Yeah. What a terrible Over the hurdle. Over the hurdle, over the hurdles. Oh man. Terrible today. No one thing is going to be a home run for you. There we go. Oh, go sports analogies. No one thing is gonna do it.. I don't know. I mean, I've given up now totally trying to make my point. No one thing is gonna do it. It's gonna be many little things together. That gets you over feeling imposter syndrome. When we started this, we talked about there's just a certain amount of time when you start working at a company for the first time that there's nothing's gonna fill that void. Yeah. Like you just, you know that you don't know anything about that. Like, especially if you enter as a product manager with no domain expertise, now you're really playing catch up. You gotta learn the software, you gotta learn the customers and you gotta learn the business domain. Just Yeah. Stock upon that zantac, the German three, that's what that was. three things. You get the new the new person passing. You can you wanna, you, you wanna milk that for as long as you can, right? Sure. And that will, I think keep imposter syndrome at bay for a little while. Mm-hmm., right? You can kick that can, right. But then you come to the point, and then to your point, particularly maybe you're coming into a new industry, maybe you're coming into a product you're not familiar with and you don't have the domain. So you have a huge hurdle to overcome. A lot of learning. And you get to be newbie and not know what you're doing and not be able not have to fulfill requests and, and, and meet requirements for a little while, but at some point I would say usually around the 90 day mark, your first review or so, there's a, a change in expectations that is both in the company and on yourself right now. If you haven't overcome that hurdle or you feel like you have a long way to go, yet that almost is the melting point. It's not at the beginning. It's, and, and then a year from now, you could be that subject matter expert in that domain expert. You've got that domain expertise, but it's that middle ground. Woo. So, even in those first three months, even if you're new mm-hmm., like that's kind of where we're going with what we're talking about now. Yeah. You're new, even if you're new and you don't have domain expertise, two recommendations. Number one like there's no stupid questions. Like, like if you are if you're a PM in the PM career field and you're afraid of being perceived as stupid cuz you're asking questions, first of all, you're in the wrong career field. That and business analysis. Like you, you've, you've made a mistake, you need to fix something. But aside from like pushing that out hard outta the way what you can do in the first three months is you can spend a lot of time doing one-on-ones, climbing the the old corporate ladder, figuring out, who is in managerial positions, and then who the actual leaders are. Mm-hmm., and then basically between the two of them who actually calls the shots. Like, you might have a manager that says like, oh, well this, this manager decides when things get done, or this manager decides prioritization or whatever. But the subtext is, well, this manager always relies on this leader. Mm-hmm. this specific subject matter expert who if they don't like something, it basically doesn't get done. Like, that's not written in an org chart or a hierarchy or whatever. Even if you are, even if your teams are more agile than a typical top-down hierarchical corporation or whatever, it might be hidden inside of like one senior member of a team who's been there for a while, or but the point of this is politics for a product manager is important. You need to cast that net very wide and learn who makes things work. I mean, who has authority of that kinda stuff. Uh, and, and in your first 90 days or whatever, like in that period where you, you, while you were ramping up, On the rest of the business. There's nothing stopping you from doing this. Yes. Yeah. Definitely. Vectoring in with the right people. Yeah. From day one. That should be your objective anyway. Right. Whether you're in the same domain that you're walking into or not. Mm-hmm., even if you are people and politics and processes, the three Ps get in the way. So yeah. Figure out who really matters side with them. And they're gonna help you get over this. Right. The 90 day is just an arbitrary timeline really. I truly, it is. I, I just, I thought about that because that's kind of where I am in my job personally. Like, so yeah. It just came top of mind. I just had my 90 day review. Yeah. So I was like, huh. Basically the people you meet when you first onboard to a company like you are setting the tone for your interactions rather than letting them be set on somebody else's terms, basically. Yeah. You, you are choosing the, the, the, the Confucius, like you are choosing the field of battle rather than letting somebody else determine the field. And even if you choose a crappy first interaction or your first interaction is not that great, like you have one-on-ones, you have opportunities in the future, but the point is you're seeking to influence what you can. I think that, so number one, you're still trying to figure out when you're at a, if you're, if you're new mm-hmm., uh right. You're still trying to figure out what exactly you're responsible for. So ideally, ideally we kind of understand what we should be responsible for, but every company's different and every there's politics, we don't know the, we don't know those things yet. So we are still trying to figure those things out. Mm-hmm one of the things that, when you were speaking that I, that I started to think of was because we don't know what we don't know. That those initial meetings are thinking about them as opportunities for relationship building. Right. So really focusing, making that the agenda, making this meeting about how they can help you. Right. So be selfish as long as you can. Yeah, because, because, and the reason I'm saying that is because as soon as you have those one-on-ones and you've got the new product owner, the product manager, right? And you have a one-on-one, and all of a sudden you walk out with action items, blah, blah, blah, blah, blah. Mm-hmm., right In your first 90 days, you have now scheduled one-on-ones with all your sales people, all your account managers. Yeah. All your, right. So all your leadership team and your so customer success, all of those people, and all of a sudden they're going like, oh, oh, you could do, oh, can you do this? Oh, can you do this? And because I think I mentioned earlier that when you come in, you don't know what you don't know. And the assumption is if somebody's asking it of you, that must be something that I should be doing, with the assumption here that we don't necessarily know the domain. Right? Yeah. I guess, oh, is that something I should be doing? Maybe in a year from now, I might say that's probably not something I can help you with. But let me, I, I know who can help you with that. Right. So, but we don't have that knowledge right now. Mm-hmm.. So my point is, when you're kind of learning that political landscape and you are number one, either trying to deal with imposter syndrome or keep it at bay; be selfish. Make those meetings about you. Use that one-on-one time to learn. uh learn about what the company, what that leader does what their expectations are of your role and then communicate back. Anything that might not be aligned. I mean, this is your opportunity to do those, to your point, to there's no question, no stupid question. Yeah. This is the opportunity more than any other Yeah. When you can ask those questions. And I think that could help to build you up and, and learning the political landscape, but also to develop those relationships. You know, what would be a good like 45 minute podcast is A situational podcast like, Hey, that side of the table is like either leadership or stakeholders or whatever. And this side of the table is the new PMs or maybe a PM and Agile coach, something like that. I think like the exercise would be, hey you are new in either a scrum master slash agile coach. product manager, these are leadership roles and when you join a company in a leadership role, no matter how junior leadership is, or how buried in hierarchy you are what would be your introductory questions? Like I, I can think of a probably half a dozen questions that are not organized or even good questions like right off the top of my head Hey like how do you. what's coming up in the product in the next whatever month? How, how do you know what things have been traded off in prioritization that, hey, we're not gonna work on that because we need to work on this. Mm-hmm., how, how do you know when those decisions kind of jockey things up and down? Um, how, how do you know assuming your company has user personas that back up the stories. How, how do. Who, who we're building for? For example, if I was building only, cuz Stormy, here, I'm using this example if I was building software for healthcare mm-hmm. I got the, the backend billing people. Mm-hmm., I've got nurses the actual RNs. Mm-hmm., like I have software for them. I have software for the doctors. I as leadership I see that 58% of the features, I just pulled the number outta the air. 45% of the features that we build are for backend billing people. Why Right? Do we really need to optimize for this specific type of user? But the, the point is like can you break down the features that you're building to the user level and then show me a percentage that, cuz that there, there's a maturity there in your operation that I as leadership want to know what's happening. Are we actually servicing the users that it matters that make an impact? And that goes back up to my corporate strategy and my company strategy. It's gotta be aligned to that, et cetera. Yeah, I get it. Yeah, absolutely. That makes sense. I think that's the other thing we haven't talked about though, in your initial foray into a new company use the experts that are there to your advantage. Yeah. That may sometimes require some egos stroking life skills, right? Sure, sure. It may, it may just bloat people up and go, Hey, I know you could do this in your sleep, but you explain it to me like I too? Pretend that you're a product manager for like, for the first time. Like you got hired straight outta college, or maybe you moved over, maybe you were a developer for a couple years, you moved over, right. and you really feel the imposter syndrome. How do I even conduct a one-on-one? What do they even want to hear from me? How do I even connect with someone? The one-on-one topic by itself by the way, is like, how do you get influence in the organization? How do you build influence and get influence? Mm-hmm., you don't get influence. How do you build influence in the organization? I'm glad I worded it poorly because like, how do you how do you get influence? Oh, well, you get hired into a position of authority. That's how you get influence. Now let me tell you how to maintain influence and how to build influence. You maintain and build influence by connecting with people one-on-one; by doing things for people without asking for stuff. In, in return, right? So, okay. Back to imposter syndrome. Yeah. So you're new, these are new ways of thinking that you've never dealt with before. Sure. And a lot of times the assumption is like, this is simple stuff. Why would you like the assumption is that somebody knows something so simple and they may not, and that might have been the reason. So what I would say is are they aware of how to replicate that? Yeah. So, so the next time I get to do it, yeah. And anyway, are they engaging back with your responses? Are, are they happy with your feedback? That kind of stuff. Like if, if you're having a one-on-one where it's actual face-to-face conversation, it's a little easier to read if you're like posting over Slack or email or if they're responding to you or if other people are getting, if it's like an open form and other people are getting in on it and you see engagement, then you have some sort of feedback available to you. Mm-hmm. Everything we're talking about in the category right now is under the banner of leadership, like the, the politic politics and part of finding people in the organization that are making a difference or can make an impact. And then partnering with them to find out what they need and then like helping them and uh, going to them, relying on them, having them rely on you. All that is under the banner of politics. But I, I like, I like my challenge to this is like, all that is also under the banner of leadership. Mm-hmm., because like I, I tell people all the time as a product manager, I have to be, I, I have to be enthused about the product vision. I, and, and like to take that to the next step. I have to have a product vision of where the product's gonna be in a couple of years, and then start driving with that vision to where I wanna be. And then like, I'm like, I'm following a general road map, and then sometimes I get to the road and the mountain side's washed out or whatever and have to like pick a new road or whatever. And I don't get deterred, I don't get stress. And I'll let people read stress on me about that kind of stuff, cuz that is normal. But I could easily see imposter syndrome about like, well, hey, I'm building a path and everyone's beating me up all, every step along that path. And every, every time we have a tiny little hiccup, everyone's like, oh gosh, Brian, how come you didn't see this coming? The point of this category is that as a product manager, if you're feeling imposter syndrome, one way to help you out of that, out of that, around it, or, I don't, I don't know. Deal with it. Deal with it. You, you've fallen in a pit trap. That's what, easy - you take 1d6 damage! Lizards and Wizards! Is going back to our podcast. One of the things that helps you out of this is to learn to communicate, like leadership communicates. I don't mean management, no. leadership. I mean leadership. I wanna say that's an art more than a science. you don't get taught that in school or college or whatever. it's your, the way they perceive you, the their perception of you Sure is, is. Pretty much predicated upon that, very much so than anything else. It's no longer, I guess, if you are new, so first impressions, but in this way with communication, not visual impressions. Sure. Uh, and, and they are lasting, right? So you go in and you speak their language. I know that's a cliche, but it really isn't speak their language, what matters to them. This is where I think those people. They adapt the art of communicating this way are more prone to succeed than others that you say, but, but. Look at this. And it's just not connecting. It's not landing with them. But so for imposter syndrome, so you are, to your point, this is an art, which means it's, it's something that needs to be developed over time, but it generally isn't something that's, I think innate No. Could be. Could be. But I think it, it's something that's learned either through trial and error or by example and probably a combination of both. I think there's far less of an opportunity of those examples because of our remote work environments now. Coming into a new company or a new organization or dealing with imposter syndrome as a, a product manager mm-hmm. and um, you don't necessarily have those skills honed, or maybe you did and they worked at a different company, but now you're somewhere else and they speak a different language, which happens. Oh yeah. Enough, right? So now all of a sudden you're going like, wait, what we, the way we spoke isn't working here. Yeah. You know, what am I doing wrong? I'll give you an example of that at a company that I was on contract at one time, I was a product owner for basically all their products. I was their single product manager and I had multiple products in the portfolio. I had three products actually in the portfolio. Well, arguably two or three, but it doesn't really matter. So, so we'll just say I had two products, right? Each of those products was maintained by a separate team. So, I, as a product owner would go over to one team and they would, I'd have a backlog and a, and a, and a roadmap and everything for this team and their whole product. And I'd go over to another team in the same day, cuz I love having all my backlog refinements on one day sucker completely context switch and be like, everything we talk about over here, I'm gonna forget it and go over here. That stuff is tough. So I, one of the things I wanna say about communicating with leadership, coming into a new company, and you don't know how they talk, right? It's a new company, is maybe just get yourself invited to some of those calls and observe? Say nothing mm-hmm., and just watch how other people are doing it. Maybe partner with some other product managers and see Right. That, that might be good. So I'm saying, really what I'm getting to is, Reach out to your peers. Yeah, right. One-on-one I think. Yeah. Yeah. Partner with them. So, yeah. So yeah, I, I mean there's, there's, there is nothing wrong with going to another product manager and going to 'em and be like, Hey, I just wanna observe, you know what I mean? I just wanna ride along or whatever. Like the, that's not, that's not a bad thing No. Saying like, Hey, I don't under really understand how to do I, I, I, like the first five years of my career was, was doing business analysis and qa, so like I know how to break stories down pretty t Well I can't even imagine how someone who just jumps in from college and just starts doing the PM roll and is expected to have that BA skillset. I can't, I can't even imagine how they learn. I know how I learned, which is not necessarily the way I want other people to learn. I learned by sitting at like projecting on the screen what I'm writing and then the whole development team and everyone just be like, stop writing that. That's terrible. Like, don't write that. Write this. Like that's, that's the way I learned to write stories in front of everyone. You say you don't, that's the perfect way. Yeah, I was gonna say, you say you don't want people to do it that way, but swarming is brilliant. Yes, that is, you just have to have Less of an ego around you and go, I, I know I'm wrong, so what does it matter? Yeah, right. I'll be the hands on keyboard. You guys are the brains, I guess. So put something out there for him to knock it down. I'm a fan of that. Yeah. I can't, it a better way to do that. I, so yeah, we're trying, we're doing a acceptance criteria. We're trying to figure out we're, we're refining these stories and, and I don't know the, how Sure. I don't know the infrastructure. Sure you do. I've written this story and you're going like, that's gonna impact this or no, that's freaking enormous. Yeah. You know that. Yes. Oh my gosh. I can't think of a better way. And a better way to learn as well is to have that opportunity. And what I can tell you from being so fortunate to have worked in this industry in the before times. Mm-hmm. is. having that experience and knowing that that is so far removed from the experience that people have in general now. That as a product manager or even a product owner coming in and things run very differently. All, all, all of a sudden you don't, you don't have that you don't have the, the expertise to be able to ask questions of right at hand there isn't those drive-by opportunities. Yeah. And there isn't that opportunity to visualize and to have that group mindset where you start dissecting and hearing other perspectives? Yeah. Oh my gosh. I just, I'm getting goosebumps thinking about it because those were some of the best meetings ever. I learned so much and I felt as well that I was able, to give something as well. Yeah. So even though I wasn't a developer, I was able to give them something they needed. Yeah, be vulnerable, right? Just go in and say, I don't know. Yes. Maybe we could do this. And they go, no, that's dumb. Okay. Well the other thing under the banner of communicating like leadership is bringing people bringing people in, like sprint reviews is a quick and easy one that I think of when I think of this category. Communicating like leadership. I, I think of all the teams that I. Been on that did not have a customer representative at the Sprint reviews. That the, the first thing I did as a product manager on the team was, Hey, why don't we invite whoever we're building the, these pieces of software for, why don't we invite them to sprint review? And then like, okay, well maybe we can maybe, maybe for the first 10 minutes or whatever the, the, the, the people joining from outside the company will, we'll show them their features and they can drop off and then we'll segue into more technical deeper dives or whatever. And that's cool if it's mul multiple different personas that we're talking about in the, in the review, I would hope it's not, but, it's reality, so whatever. The example I'm talking about is like the team that never talks to customers. Yeah. That's easy to get over. But is it easy to get over or does it just lead more into bot? Like I'm, I'm inviting people potentially from outside my company now. Mm-hmm. to the sprint reviews. Does that lend itself more to imposter syndrome? I think maybe at first it does, but over time it does not, because over time you will, by inviting the same people to the sprint reviews and having people learn other people's personalities and talking with people and , you develop a relationship and I think the deeper that relationship goes, the less imposter syndrome you will have. If you are deeply familiar with people and their problems and their personalities and the issues they experience with the software or whatever. I would expect the, the normal biases. Well, I, I know these people, they're, they're not others anymore. They're my tribe. Yeah. You know what's near and dear to their hearts, right. By that stage. Yeah. But we're talking about somebody coming into a. Organization in that case, you don't have that, you don't have the relationships. I can't think of a better way to build them than invite every persona stakeholder into your review. Yeah, and start to forge that as a PM you could start to forge that relationship upfront. So I think to, I could, so from an imposter syndrome perspective, yeah. In your specific example where you're talking about bringing customers into a sprint review for instance, which I have found just change is a game changer. and, and isn't done enough. But I've also found that for the dev team that has never done it or you know, has been far removed from the customer. Oh, no, no, no, no, no, no. Oh my gosh. The fear and the it's loads of, and, and leadership too. Same thing. No, we wouldn't want, those are internal meetings. We wouldn't want customers on, on, on those. Well, that's that, that, that's a, that's a level of imposter syndrome right there. So it's, it's, I think, well, it's a little different. It's not exactly imposter syndrome. So I think this is another, this. Something a little different. But if I'm thinking about from the product perspective, who the product manager that has imposter syndrome inviting the customer could actually help, I think, to alleviate so some of that. So initially I think there may be you know, that hurdle that you need to get over and you understand that there's that hurdle, particularly with dev, at least this is my personal experience.. Because you are a little bit separated from Dev, it's a little easier to kind of force that change, and watch the relationship build. To see the success happen and to feel that right, to have to, to be able to demonstrate that even to leadership and say, I have never seen anything but positive outcome from bringing from, from getting as close as we can to that customer in regards to feedback, but as often as we can. Uh, so I think that this may be a way to to help this, the one other, one other aspect of that is you are also indirectly at that point, building relationships with the customer. Who is also then kind of building up your confidence and helping you to kind of maybe overcome some of that. So there's a lot, there's a lot going on there, but there's a, there is a to your point, some time that needs that, that needs to kind of Yeah. Happen over. You just walk through how to get over imposter syndrome. Like, you, you have to build up your relationship with the customer. Yeah. And over time, you, you feel more free to kind of exchange information back and forth. Like, that's again, all, all that sounds like communicating, like leadership to me. The, the other thing we didn't cover with communicating like leadership is le like I do this with my product vision a lot a lot like annoyingly to all my stakeholders, a lot. Like I'll repeat the same thing. over and over and over again. And I, I told Om, , I had a CEO that his leadership schpiel . schpiel. schpiel. Is there a S C h I, I don't know. Anyway, there is now, like he, yeah, there is now um, his German version, his, his, his spiel, three, um was, when you optimized for one group in the company, you suboptimized for all the other groups or something like that? I thought it was nonsense when I heard it originally. I still think it's nonsense to this day, but I know he really believed that because he repeated that that tagline as often as he could. And you, if you read the working backwards book about Amazon and how Amazon kind of came. Um, that's one of the things they tell you in that book is you need to repeat your vision. Whatever your leadership vision is, just keep repeating it over and over and over and again., and like that will hold influence just by itself, which is crazy to think about. Like, I just say the same thing and I keep saying the same thing. People will start believing Yeah, the same. Like, I mean, not in my, I gave you a really terrible example of people start, because I still to this day don't believe it. I'm not saying it's not a genuinely influential tactic to deploy. Yeah. Like, that's a, I want, I would like to do a whole podcast on the Robert Chialdini influence book where he outlines a lot of little tactics like this. That would be a great podcast. Yeah. I mean, it would be long cause that that book is not short, like mindset and that book is not short. Like Marty Kagan Inspires and stuff like that. That's a long book. It'd be a two-parter. Um, but, but there's a lot of dirty tricks and context inside of that book for, for to help product managers definitely to help them. I prefer the term guerilla tactics, yeah. Boy. Yeah. Than dirty tricks, dirty tricks. on the old Agile podcast. we can do a whole podcast on communicating like leadership. I think the, the, the most effective thing we can do in the time that we have that doesn't get edited out of this podcast, is to talk about, metrics. One of the things I'd like to bring up is all metrics being tied to money. Not proxy metrics, not things tied, indirectly tied. Oh, these things are tied to hours or these things are tied to whatever. No, I'm talking about metrics that tied directly to money. One of the things I feel is in order to present the cleanest metrics that get you immediately as a leader in the organization, one of the things you can do to bring people along with you is only talk about metrics as they tie directly back to money. Don't ever talk about proxy metrics. We were talking about this the other night. If you're going to be a representative of leadership, you have to talk in terms of money. Mm-hmm.. Yeah. Anything else doesn't really land with them. I feel, I mean, if you're a leader, if you're a higher level leader and somebody comes in and talks to you about these other metrics, All you're thinking about is when's he, she gonna shut up? This is really not meaningful to me. Yeah. Like, tell me how it matters to me. So that WIIFM-ism again, right, right, and to your point yeah. Distill it to the dollars. Are you saving money? Are you making money? What's going on? There are some notable exceptions to that, right? When you bring in some ideas that potentially might warrant investment, but still turn that into like, what is the potential benefit? Use all kinds of financial metrics if you want, but ROI gets banned the bottom an awful lot, there are other financial metrics. Oh, no, , I kind of wanna cut us straight to a real example so we can talk about something that will help people punch through imposter syndrome as a PO or a pm. If you have a balance sheet, if you have some kind of p and l Like, let's talk about like monthly recurring revenue. Let's talk about any of the pirate metrics, and I'll pull up the pirate metrics in a minute. The A A A R R or a A R R, whatever metrics, like any of those metrics. Are great. So if you're gonna talk about, Hey, I'm gonna make a change in my software, I'm gonna bank on making this change will have an impact, and that impact should be a monetary impact. I want to be able to show the impact of my change on the monthly recurring revenue. So I'm showing you, Hey, I implemented this software change, this new feature. Mm-hmm., you don't care to hear about the details. You don't care to know how we're deploying the application or whatever. But what you do care about is. What is the impact of that change on our monthly recurring revenue? whatever change I make, I need it to roll directly up to money. I absolutely agree. And look if you're in that role where you really have just come in and you don't know the depth, fine. Make assumptions, make them clear. Sure. You know, if we get a thousand more people to click on this, a thousand is an assumption, right? Mm-hmm.. Sure. Yeah. But but you're saying that too. You're not saying thousand people will, you're saying if they do, then this is what it means. And then use the power of extrapolation. What, what if it's 5,000? What if it's 10,000? Right? And show that. I think that gets you mind share. That gets you to start talking about this with the right people in the right way. and be ready for the negative connotations too. What if only 50 people click on it? How much are you spending putting that feature in? And what will you do? So go in with those scenarios that, okay, if all goes well, this is the conversation I want to have, but I also have as backup in my pocket. What will I do if there's only 50? So maybe one of the tactics might be, well, we're not gonna immediately roll this out. Maybe we just do that with a focus group or a pilot set of users just to validate the assumptions. If you're going in and having those discussions, I think you might actually have a better chance to succeed. A couple of things I wanted to mention in regards to tying metrics to money. From a health caregiver perspective, that's uncomfortable. Yeah. So understood, but still uncomfortable. Yeah, right. So I can say that personally. That said, if what I have learned is even when we're talking about metrics like you know, improving healthcare gaps. We can still tie that to money. If we're measuring it, there's almost nothing that we can't in some way tie to money. This is where I want to be with the pirate metrics. You're welcome. It's acquisition, activation, retention, referral revenue. That's the model. A A R R R. And the idea is I don't want to implement anything that doesn't fall under one of these categories as improving. The money that comes from acquisition, activation, retention, and referral revenue. Back to my healthcare application, Brian and Om's healthcare application, don't worry. We're, I like that we're 18 months away from selling our company again. Hey, listen we wanna boost retention in our application because the idea that we're going with is users who use our application more and for a longer period of time will become advocates and they'll, they will be the people that help us sell our application. we'll search for things to build and we'll talk to those type of users to figure out what we need to build next. We're going back to the imposter syndrome, right? Via via metrics. If you have a guide like this, so like, oh, well, well what is this feature that we want to implement? Oh, oh, sales. You want to implement a new feature that helps us sell a customer or whatever. Well, which categories this fall into? I mean, does it, does it, does it help us get more referrals to the application? More signups in application. Okay. Well, our application's not really you don't really get signups in the application's? Not really. That's not our business model. Okay. Well, it must help activate cut, like people who sign up and sign in for their first time and then never come back or whatever. It must help with that. No, it doesn't help with that. Well, does it help with acquisition? No, it doesn't help with that. Or does it help with like referral, like bringing people in to the ecosystem from other applications or other places on the internet or whatever? Well no. Well then it doesn't fit into my vision for my product. And now you're back to like, oh, you have your arms around the product., you have your metrics directly tied to money. You have your vision and you've built off of all these things and now you're saying yes and no to features based on where you think you're going and where the money is leading you both, because those are very different paths. I just wanna say absolutely fully agree first of all. But there, there's also another side, right? So there's the, there's what you just said about where's it gonna mean revenue sources for us? There's also the cost saving part. Right. Um reduce attrition for example. So this feature is going to make sure that we lose fewer losers. Yeah. Yeah. That's still adding to the bottom line acquisition on there. Yeah. Yeah, yeah. Yeah. So, so it's just it's not churn just what's gonna Churn churn. Exactly. Yeah. That's the term. Yeah. Um, just be mindful of that for those, those people out there that just say, well, but you know, my, my system doesn't do that. Or My product, my product's geared towards, or my features are geared towards saving money. They're equally valuable. Yeah. You're saving money. Just have a good case for it. what I was getting to is that, I mean Money numbers. Being responsible for that is really intimidating. No doubt. Yeah. Oh my goodness. I'm just saying not that you, that that's part of your job. Yeah. As a product manager. But it's scary and coming in new, it's super scary. It's like playing a roulette with somebody else's money. You don't know what the outcome's gonna be and there's high stakes usually and you don't understand yet. You actually don't have an understanding. of you know, there's, there's time that you need to be able to learn and hone your skills and understand what numbers matter, what money matters, where are those pools, where are those buckets? How do I prioritize those things? And, and money is one of the, as a hu one of the biggest, influences in that prioritization perspective. Mm-hmm.. Mm-hmm.. But it's also calculating that and then understanding it is, is in, in intensely intimidating and there isn't necessarily black and white when you're dealing with money and numbers. Like when you're dealing with money is some like No, we're talking about We're arguing agile school me, like I, I I don't agree. Um I, I, like, I, I don't agree because like, depending on the financial model you're deploying in your software development organization, especially with companies that I see making like deep, like 10%, 20% cuts. When I see that from like across the room, I'm like, oh, you're deploying a cost, cost-based accounting model to an organization where throughput is more important Basically what you're thinking is I have my cost of inventory. And my cost of payroll and my profit from sales, and you will never balance that number because that accounting model will never work for you because you, maybe your industry is changing at a pace that you can't keep up with, with this crappy accounting model. Without going into a completely different podcast. You're trying to cut headcount to make up for losses in other areas where like the accounting model you're deploying is failing you because all you have is lagging indicators. Yeah. Okay. In quarter, whatever, we punched out 25% less profit, oh, oh snap. We need to run out and fire 10% of our workforce to balance those numbers back, to make it look like we're doing good in the next quarter or whatever. Why not? Why not fire 50% of your workforce to make yourself look great in the next quarter? Because you're just dealing with lagging indicators. That's not great. Like you need to deal with the throughput immediately so you can see if your demand increases. You can see that daily and respond to it daily. If your throughput drops , in the week over week, you can see that weekly, and you can respond to it weekly if you don't get a chance to change your business. But once a year. Once a quarter, yeah. That's ludicrous to me. We're talking about metrics being tied into money. That's what we're talking about now. Yeah. So the time element that, that you refer to, right. How many times have we seen supposedly very stable companies on that slow death march . Right. To uh, basically obscurity. I mean Sure. We've talked about that before. Right. Some household names not necessarily because of this, but this is a big part of this. Sure. Right. And then the, the other part probably, I don't know, just as big, I suppose, is ignoring the customer. Right. Which is a guarantee. Oh boy. To slide down that path and, and yeah. So I think that's a different podcast. This is, this is why it's important to tie metrics, like every metric you follow as a product manager to tie it directly back to money, because that is a language that, that, that's leadership's love language. Well, so Brian, you have brought up a lot of great points and absolutely agree. What I, but when we were, we were talking about imposter syndrome and maybe starting at a new company or in a new domain or complete, and we've talked about getting a, getting a feel for the politics, understanding leadership, all those things. This is a whole new level, a whole new language to your point, this is the leadership love language. Right. But it's a completely different mindset. A completely different, like a skillset, I should say. Yeah. A completely different skillset that also needs to be learned and honed and be, be able to understand how to tie your product to that money. It's easy to feel inadequate. You've not gone to school for finance. You might inherit another team involved in another like an exploratory line of business mm-hmm. that you might have to learn quickly and that like, that's cool. Like there's obviously gonna be imposter syndrome in that there, there will be for your whole team when you're doing something for the first time. Yeah. There certainly will be something I think that's natural, right? Sure. Maybe so, I, I don't know. I mean, imposter Yeah, maybe so that feeling of inadequacy or the, the even so I, I think even in the face of a good work, so the, that you don't deserve, like that's generally the imposter syndrome is like you don't Well that's that is negative self-talk. That, that is the Carol Dweck mindset podcast., Hey, go listen to our podcast, episode 100.. There it is.. YouTube. People will tell you that's a way to promote your podcast. I think we might be now kind of drifting to that last bullet. Right. Never stop learning, because I, I think that's where it's going. Yeah, in our recent discussion in regards this never stop learning is that there is never an opportunity where you can stop learning. You must continuously learn and you must be proactive about that to be relevant and to be successful in product. You, you must, and so we had mentioned, for instance, a lot of the certification factory kind of going, going around that people study and they read books or whatever, and then they pass and they get their certification and they're like, cool. Done. All right. Got my job. Yay. All right. I'm the expert now. Right but this is a craft that has to be honed, and I would say particularly now because we have moved to away from co-located work where we don't have the opportunity to work with other people and really learn kind of, really on the job. Yeah. That you have to be very proactive, and, and getting involved in your community. You know, in regards to agile business being a part of that community learning, investing time giving back to that community as well, to your point of you know, of, of not just learning, but providing learning. Feeding our culture feed, feeding the the, the younger generation and the people coming after us. Yeah. But yeah, I think that's my point is that the journey never ends when it comes to learning. And I think that probably is with everything, but, oh my gosh. Anything to do with product or, or software. Yeah. It just is a given. Yeah. The learning never ends. So the organization should be designed from the perspective that the learning never ends. You're talking about the organization being a learning organization. Yes. Right? Yeah. Or growth mindset organization. Growth mindset. Yeah. This goes way back to Peter Senge days in the eighties when he came up with it. First. The concept of the learning organization. It's real. I mean, yous real. You see some organizations that foster that culture. Mm-hmm. and they do so much better. And it's not just like, oh, they're seem to be better. No, they do better in terms of their bottom line. Quantifiably. Exactly. These organizations do better, do better. Yes, they do. Do. So. So in regards to learning when we're talking about bringing this back to imposter syndrome, there's no single solution to i imposter syndrome or lack of confidence or Right. But. What the what knowledge can do and you furthering your understanding can increase your confidence while increasing your skills, while building empathy and understanding for the leadership, for instance and, and then when we understand that our, a company is relying on us, teams are relying on us. This lines up to my thinking is that when you're in the product owner slash product manager role, you are empowered for the business to own own this. I was doing air quotes for people listening to the audio, this segment of the business. So if it fails, it's on you. If it succeeds, it's also on you. Mm-hmm.. So do whatever you need to make it succeed. Oh, I like that. Did you hear that? You're a poet. Do whatever you need to make it succeed only. Yeah, that's a great tagline. I think we could possibly end this podcast on that tagline. All right, well, we're done.

