AA160 - Onboarding New Product Managers

Onboarding New Product Managers

In this episode of Arguing Agile, hosts Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel dive into the challenges and best practices around onboarding new product managers. 

Topics include:

• Communicating the company vision, mission and goals 
• Mapping key players, stakeholders and decision-making processes
• Aligning the new PM's goals to organizational objectives
• Building and owning the product roadmap 
• Understanding customers, segmentation and building empathy
• The importance of mentorship and coaching for new PMs

Whether you're a product leader looking to optimize your onboarding or a new PM wanting to hit the ground running, this episode provides actionable tips to set up PMs for success from day one!

Roman Pichler's Stakeholder Management Article referenced in the podcast:
https://www.romanpichler.com/blog/stakeholder-management-tips-for-product-people/

= = = = = = = = = = = =
Watch it on YouTube
= = = = = = = = = = = =
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

Spotify:
https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3

Amazon Music:
https://music.amazon.com/podcasts/ee3506fc-38f2-46d1-a301-79681c55ed82/Agile-Podcast
= = = = = = = = = = = =
Toronto Is My Beat (Music Sample)By Whitewolf 
(Source: https://ccmixter.org/files/whitewolf225/60181)
CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Transcript

0:01

welcome to the arguing the Agile podcast where enterprise business agility coach Om Patel and me product manager Brian Orlando debate the real world challenges Agile professionals will face. We are not here to sell you anything. We are here to argue about Agile so that you don't have to. So you're a product leader. That's what we call people who hire people in product management. Now we call them product leaders Om. Didn't know if you knew that I did not but that's enlightening. We're starting the podcast by turning off product leaders. So if you're product leader and you're hiring a product manager what are some steps to get them set up and started in the right way? That's a great question. Cause I don't know if there's a whole lot of Artifacts out there that help product leaders. I think people struggle with this generally in the field. That's my sense of it. So in this podcast, we're going to unpack that and figure out like, what are some good things that they can do? I mean, right off the bat, I can think of applying the same principles you would apply onboarding anybody new, right? They're coming into your company or your organization as a new person. So. It stands to reason that you would you know, you would explain to them what the organization is all about. What is your, what is your org vision, mission, et cetera? And what are you in business to do? And explain to them, this is how, you know, this is how the company is right now. And that's what you're walking into. Yeah, A book I keep going to many, many times on the podcast is Gino Wickman's Traction because in the, in the book Traction, he delineates working in the business, meaning, you know, your day to day work versus working on the business and not a lot of, not a lot of businesses, quite honestly, not a lot of businesses take the time to say, Hey, are we stopping to think about how we can do these work processes better? Not a lot of people are even doing that. Stopping to think about that. And an overview of how our in inter or intra team practices work. You know, in overview of your mission and vision of the organization. Again, assuming that exists. Yeah, well that's a big assumption too. I agree. I think a lot of times this falls on HR packaging it. You know, this is your onboarding package. Oh no. That's what I found. I mean, you know, go visit these websites, or go listen to these or watch these videos, and you'll become indoctrinated? Aware. Aware of what we're all about. You can't ask any questions, of course, when you're doing that because you're just consuming that, right? I was gonna say you had me at HR is like you you're not allowed to ask questions You're not allowed to think on your own. You're not allowed to stray from procedure. Welcome to dealing with HR, right? I'm already out when as soon as you mentioned HR, We've hit on problem number one in the podcast we're going to assume that you have a mission for the organization and a vision for the organization written down somewhere, right? The same thing when we go into like the next thing we're going to say is, okay, as soon as you understand the mission and vision for the organization, we're going to assume that your product. Has values and has a vision that you have a product vision. I guess if you're now you're on the onboarding, the being onboarded side, the onboardee, the onboardee like you find out you don't have those things. You still have a resume that's fairly updated. Yeah. So let's move on from there. That's right. Hopefully you still have other people offering you jobs. That's right. Yeah. Right. I think a lot of organizations though Tend to have something when it comes to, you know, vision and mission. Even if it's on a plaque in reception they, they pay lip service for the most part, right? When a new person joins, you know, they're doing that when they point at something static, right? Whether it's a video or a website, something that they expect you to read and agree with, because there's no, there's no opportunity to ask questions. That's red flag number one. And we do in this podcast have a collection of red flags. So this is number one. Right, when that's happening, you have no idea who to ask questions to, you've just been given a link or a bunch of documents by HR under the guise of onboarding. That's not onboarding, for me. Yikes. Covered a lot there. I, I mean, onboarding, like that, not good enough, I think about like your day to day in product management, your team the other teams you interface with, that you interact with, like they're super important to you. Like that, that, that, that makes or breaks you in product management and like your, your cross functional team, whether they are cross functional, I guess we're assuming at this point in the podcast, cause I have a development team and I have a QA team and I have whatever, like that just makes it. 10 times worse than what it is now. But assuming that you have a cross functional team assuming you have a designer, assuming you have a tech lead, assuming you have everything like all, all the ilities in the Marty Kagan book, right? Assuming you can actually tick all those boxes, hopefully you have people that can clearly delineate that for you, clearly detail it for you. And it's not like, well, sometimes I don't know, you know, sort of. I think of we're on a shared services model. You have to kind of just beg for these people's time. Learn to speak loud because the loudest voice wins. Right. So yeah, definitely. Look, org design has a lot to do with it. I know we're going to have a podcast on that at some point. But definitely. So are you coming in? You have no idea. You don't know left from right. And you need help. You need help to succeed, even to be placed in the position where. You can run from there on and be successful, but Typical onboarding initiatives that most organizations leave a lot to be desired, I feel in this arena you know, they, they drop you in it and you either sink or swim, that's typically what happens in practice. And it's just not good enough. Like you said, well, another part of this that's super important is a stakeholder management. Because again, if you're talking about cross functional teams, most likely it'll be like, you may talk about like development teams or, or, you know, you and another, like we talked about. QA is a separate team like, well, you gotta have QA, but you know, the other teams that I've gone through that, that the organization. Basically had very little power to say, Oh, we're going to do this or we're not going to do this is we had a team, I was on a contract one time where we had a penetration testing team and your work, anything you wanted to put out through to production before it would be deployed, you had to get the sign off of the pen testing team. To say it was I don't remember what they're called security team or something. I don't remember what they called Basically, they were a penetration testing team. You had to get there. Okay, the the point of this category is, in product management, regardless of how many teams you have to go through, it's all just stakeholder management, you know, and it's up to you to build relationships with people on those teams and to understand their work processes and stuff like that. and, and a lot of this is heaped on the product manager. You know, and, and yeah, it is something your product manager should do, but as a product manager here, like I'm kind of thinking about this category and saying, I don't know, it's not really product management. Can your developers help with this? If you have a scrum master, can they help with this? Is there, is there ways that you can delegate this where you don't have to deal with so much um, definitely. That is the case that people can help with this developers. Yes. Anybody really look BAs, but these people. Don't have the influence they need with people like app sec. You were mentioning, right? Whoever it is, compliance, regulatory, whatever it is. So I, as an incoming product manager, if you could understand the lay of the land and get to know the players. That's only going to be helpful because at worst, what will happen is you can empower your team and say, go reach out to, you know, Fred over there, Mary over there, but if they get inaction, if they get nothing, right, then you can do something. You can talk to Fred or you can talk to Fred's boss or whatever it is. So I think it behooves you to understand who the players are. And that's part and parcel of the bigger, the stakeholder management piece, right? I feel like that is at least a Why wouldn't you want to know that? Right. As a product manager, you have a wide berth. You have, you have a lot of things to cover and, it's people that will help you or people that will hinder you in either case, you need to know who they are. Right. But who's going to help you introduce, you know, who's going to help introduce you to these people when all you've got is a document with a few hyperlinks in it? Well, also stakeholder management. To me,, it's the Roman Pichler two by two that maybe in the editing and throw up on the screen right now. Cause I'm far too lazy to do it right now. That's it. That's easily far better than, you know, either being handed or being told to develop an elaborate RACI. Yeah. I can't think of more things that are kind of contributing to more business rigidity, the opposite of agility, then an elaborate racing. Oh yeah. Yeah. I was going to say, I can't think of a more useless artifact than a RACI chart, like, Oh yeah, basically all this is going to how would decisions get made? It's going towards that, that question. How do the decisions at this workplace get made? I mean, if the, if the product manager just makes a decision based off of what they're hearing, okay, that's fine. But also like, is there a building frustration? Off of the, off of, you know, every decision that the product manager makes, is it just building more and more and more frustration? Like, how are you keeping track of that? Somebody is for sure as an incoming product manager, you're probably not a, you know, given a whole lot of latitude to make those decisions because people don't know you. They don't know you. They don't trust you. You're new and it's probably mutual to be fair, but you're new. They hired you for a purpose, right? So I think the onus is on the organization to make sure that your onboarding is As effective as possible. Even if it is inch deep and mile wide, that's okay. Cause you can always deepen later, but often it is inch deep and inch wide. If that, and that's the problem, right? The problem I find in product management is that you, you, when they finally bring in a professional product manager, they start to learn that the, their knowledge of the customers, was limited in the first place. And you bring in this person that's starting to kind of, they're starting to take a peek behind the curtain and like, what does the wizard actually look like behind that curtain? In reality, what you're doing is you're putting evidence to some of the assumptions and the, the, the sticky part of this is that may not be. Appreciated in some circles, for sure. I mean, in some circles in those same circles, you, this product manager would be labeled as a troublemaker because they're asking questions now. You know, how dare you? We've always worked this way, right? Customers can like it or lump it. Right. It's like. You hired a professional product manager to come and take you to a different level. Yeah. You've already been suffering, but you just don't know you've been suffering. So yeah, absolutely. You're right. It's, it's a uphill battle from the onboarding step onwards. So what is a you know, what is a newly newly enlisted product manager to do in this scenario? If you're flipping to the side of the person who is just coming in, what do you do when you're not getting what you need, right? What you are getting is the quote unquote official onboarding, right? This is the formal piece. If you go through all of these in the next day or so, now we deem you as onboarded. As opposed to, there's a parallel track, I feel whether it's recognized or not. I've always seen it. And that is the unofficial onboarding, which is you align with certain individuals, you talk to them, hopefully they'll open up and tell you how things really work that aren't written down. And yes, it doesn't happen at work necessarily. You know, it happens at lunch or, you know, at the cocktails you know, after work, but that is important. So if you're an incoming product manager, use any avenue. You need to, in order to unearth these things and not all of them will be official. I would think that I would suppose that this is an area that a lot of people have difficulty with because now you're talking about, like, you're not talking about product management from the perspective of. Software development or, you know, putting out a certain feature and measuring its impact or whatever. Now you're talking about running a business. You're talking about being a GM at this point when you're saying, well, just do whatever you need to do to make your business successful. You know, go to whatever meetings like if the, if the, if the real meetings happen over golf, like now you, now you gotta learn how to play golf. Like, I mean, this is like real nitty gritty. I mean, some of it could potentially sound like, I don't know, I don't know what I'm thinking about how I want to say what I, what I want to say. What I want to say is , the more unrefined the forum is where the real decisions get made, the more you have to try to crowbar yourself into that forum, whatever it is, if it's golf games, okay, well, I guess you're going to learn to play golf if it's, you know, after happy hour afterwards, like, I guess you're gonna. You know, like to go to happy hour or whatever and get one drink and then just ask for extra ice and have it watered down or whatever. And like, I mean, there's like, this is not like people might listen to this and be like, well, this is not advice that I want to take hold of and deal with, but. But you may need it. Do you want to be successful? We can't put this in a bottle and sell it for a thousand dollars for a two day training. What we're about to say here, you know, that, that's a, that's, that's about this, like, you want to be a true general manager, like the business owner is going to be like, The business owners are only going to look to hand this segment of the business over to you when they believe that you're the person that can do it. And if handing off the decision making in the form that decisions actually get made, whatever that might be, however distasteful you might see it, like, I don't know, man, there's a lot of like, there's a lot of come to Jesus in what we're saying right now you know, I dislike about what we're talking about now is this is meet them where they are, that's what we're describing. We are. We are. Decision making, business decision making, meet them where they are. If meet them where they, if the place that they are is dirty and dingy, you still gotta go there until you can take control of the decision making process for that product, and then pull it out and put it into a, you know, a better place basically. Yeah. And, and look, we're talking about this from the perspective of a new person joining, right? Right. So definitely like pull on your glosses, put on your, oh boy, put on your long gloves. You are coming in and, and you are not even swimming. Right. The tide is going, you know, against you. You have to do all of these things and any of these things. Too much mud to be swimming. There. There is, yeah. You're waiting. There's a lot of mud. Keep that snorkel handy too, then I guess. And the resume updated. And the resume updated. But you look, you have to do this, because if you don't do this, and you're just simply hagging along or moseying along, don't forget. You're a new person. You only get a finite amount of time that's granted to you to make a difference. It's not the difference you make, it's the, it's the perception of the difference you're seen as making. That, I believe in that, right? So if you're not seen to be or perceived to be making a difference in a short period of time, you're basically not effective. And we'll get questioned and we'll appear in someone's crosshairs. So yeah, do all of the things that you need to do in order to get beyond the official onboarding protocols or whatever you want to call them. And if it means, yeah, you're right. If it means going to, you know, weekend golf games, whatever it is, do it. You don't have to necessarily play golf. Just go do it. Be vulnerable. So I don't know how to play, but you know, I'll go. Yeah, you're talking product management now. So again, it's like, what, what, what type of product manager? Are you in this instance? Like again, if you're in a giant company, maybe this, maybe the decisions get handed down to you and you're just kind of playing the role like, Oh, we haven't done that in product management. Play the role. Yeah. Oh boy. I feel good. Yeah, absolutely. I mean, effectively you're a glorified or to take her at that. Yeah. Backlog. Backlog manager. Yeah. We have a backlog massager, but I mean, like in that case you still have, you still have The responsibility to track where the real decisions are getting made. And if you don't have visibility to that forum, like, well, welcome to your new job, finding visibility, finding where it is and figuring out that form. part of what we're talking about is figuring out how the org sets goals and how you can align to those goals like that. That's, that's this category. So the product leader would want you would want to set goals, product goals. And to make sure that what you're doing is in alignment. So if you're the employee, you want to make sure that what you're doing is in alignment with the product goals is in alignment with what the product leader thinks you should be doing. That's, that's goal setting and alignment. And also like alignment is like a, one of those four letter words that really like, I mean, it can be used and abused. I don't really know, you know what it means, but It's up to you to figure out how to craft alignment. Go create that with them because they may just simply be from a school of thought where they say, Here's somebody new I'm going to set out arbitrary goals for this person 30, 60, 90 days. Right. And what they prescribe within those categories might align better to just practices as opposed to does, does the person really understand our customers? You know, how often do they talk to them? Things like that. You may not find them there. You may find things like you know, does this person work well with their teams? Are they attending the team meetings? I mean, all the practices, if you're seeing that then be vocal, co create your own agenda with the product leader, right? I've seen some pretty weak product leaders, unfortunately in my time where they just don't think beyond practices. Well, I mean that, that the product leader role, first of all, is generally speaking, it's a, it's not really new, like new meaning like a new position because uh, management. In, in and of itself has always been, you know, has been around for a hundred plus years, the idea of management, but the idea of a product leader in, in the, in like the Marty Cagan term of product leader, that is pretty new because it, it, it, what it's basically saying is , you have somebody who knows what a product manager should be doing and is coaching them in terms of how they can improve their craft of product management. And the problem with that is it assumes that the person doing the coaching actually understands product management and the problem with that is my experience has been the higher up in the organization. You get the less that person actually understands the role of product management. Usually when you get to the chief product officer level, those people have never worked as a product manager. That is gold right there. Absolutely. I agree that that's the, that's the prevailing majority of product leaders that have never actually worked as that, not, not necessarily everybody, but a lot of product owners, CPOs, they got ordained that title. They got into that job without having to actually. Perform the roles as product managers, right? Well, I mean, like now we're at a point of the podcast where I don't even know where we're going to, where we're going to go from now. Cause like now we're talking about people who get hired in at the top of the organization, they get hired in because they look like slash sound like slash think like the C-level executives or the c-level executive just came into the organization and brought along with them. Sure, yeah. A bunch of people. Yeah. That, you know, were his Yeah. Inner circle and you were one of them. Yeah, absolutely. You're, you're my buddy and, you know, yeah. You've read a product blog and we play golf on the weekends. You, you've read inspired and like now you're the product. Person, even though your background has nothing to do with product. Yeah, but I mean, I mean, like, but sadly, like I easily 80 percent of the chief product officers I've seen in my career have been like that. That's a big number. They have no experience. It's disappointing to say that it's a big number. 80 percent you're probably right. I'd say, I mean, maybe it's, I mean, maybe people like, if your experience tells you otherwise, like, please comment on this podcast, like, I would, I would like to hear from you about this category, but again, I would easily put money on a solid 75%, you know, whatever, 80 percent same, very close. But it's been way more than 50, 50, way more than 50, 50 is just, the people that I've seen in that role, they would, because they have no product management experience. They would never know what a good product manager looks like. And maybe they know what a good product leader looks like. So I guess you could say, well, maybe if they're real, they've been a really good salesperson or a really good chief of operations in the past or something like that, they can hire good product people and it doesn't exactly translate because they don't really need to know what it takes to build a good product. To hire good product people. It's going to be a bit hard if they're not directly involved in the hiring process. Right. You could say that for CEOs as well. Well, how are you going to be a CEO and hire a good chief revenue officer or chief operations officer as a CEO? Because you've never been a chief operations, the chief, whatever. And they mean, I could come along with that type of, you know, pushback. But only so far, I mean, even if you've not been a CFO and you're a CEO, you've worked with, you know, CFOs, hopefully over time, you should be able to tell apart a CFO that just speaks the speech. The talk and you know, versus somebody who's done the work. So yeah. So coming back to the the category was or organizational goal setting and alignment. So how, how do you know, how do you know if you're, again, if you're a, if you're a product leader and you're hiring in a product manager for the first time, how do you know that they're doing a good job? Coming online with organizational goal setting and alignment with your organizational goal setting. Do they even understand your organizational goals, right? For this is again, thinking from the product leaders perspective, thinking from the the newly ordained PM's perspective, it's how effective has, have the goals being communicated to me, right? Do I see that? Do I, do I buy into it? And there's something going on here, which, which I think. applies generally, not just for product managers. The product leader is here a, the leader who is actually, you know explaining the purpose, et cetera. People buy into the person. First, before they buy into their vision. So if the product leader is of the, you know, the characteristics that they portray are more like you will do this, you will do this. They're kind of like setting out, let's say in our example, they'll be setting out goals in terms of percentages, etc, etc. Revenue numbers, whatever it is, and not really talking about the other things, right, which is, you know, here's our purpose for being, here's our customer base, here's who we serve, here's why we do what we do. If they're not doing that, People buy into the person first and then their vision next. And in this case, it's a lose lose situation. Yeah, while you were explaining that, I was kind of thinking in my head if the organizational goals are not written down somewhere, it's going to be super difficult for an onboarding employee to, you know, figure out what they are. You know, to, to, to vet out what they are and then to make their goals and their product goals and their, you know, product vision and all that kind of follow it. It like, it's a lot easier if you're the product leader in this case, it's a lot easier. To follow your product leaders lead, then to kind of assume you're following their lead, but really be kind of making it up on your own and then kind of adjusting. Cause you have a bunch of stakeholders are beating you up. Like, that's just not a good situation at that point. I feel like we started with this category talking about like, Oh, how do I know that my people are following my lead? Well, I don't know. Are you, are you like, are you laying out a good story for them to follow? Are you being a good. Are you being as a leader? Are you being easy to follow? Are you being very hard to follow? Yeah, are you being obtuse right whether it's on purpose or not? I'm not i'm not going there, right? But if you're being obtuse or difficult to follow not on purpose You know, you you don't even this is the danger right? You don't even know that you're coming across as, I'm going to try this, obfuscatory. You're, anyway, you're not being clear. Your purpose isn't clear and chances are if that isn't happening, it's because it's not clear to you yourself as a product leader. You yourself don't have that clarity and then how can you expect to, have someone else Understand it because you don't really have it up here. So it goes up another level. You just outlined like a three quarters of a product management challenges right there. And that statement is like, Oh, please tell me what business goals or organizational strategy we're supposed to follow. And then business leaders throw their hands up and say what I don't Oh, well, they point at targets. Right. This is what we're supposed to do. Yeah. Year on year. You, MRI, blah, blah, blah, blah, blah. 25% more revenue than last year. That's useless. Useless. Totally useless. I wanna move on quickly because, because I'm only gonna get frustrated by this category, A lot of this will be expressed when you can't build a roadmap. Like, if you don't have a certain, if you don't have a strategy, you don't have goals, your business doesn't have a strategy, your business doesn't have a goal, this can be very difficult to build a roadmap. Now, I'm gonna pivot, To try to stay away from the, like, the bottom of the barrel scenario, the, the, the worst 25% you know, the, or the, I'm sorry, the worst 20 percent of cases that will take 80 percent of our conversation and effort, I want to stay away from that for a second, and I want to pivot to the best. 80 percent case, which says that you do have goals and I can build a roadmap and a, and a product portfolio off of that, off of those goals. So the first thing, if I'm a product leader and I'm hiring you welcome to Brian Ohm Ohm and then you're joining us. I'm going to ask you, like, the first thing I'm going to say is, Hey, in your first, you know, maybe not your first 30 days, but you're definitely your first 90 inside that window you're going to own the roadmap at some point, you're going to take over the roadmap is going to be, it's not going to be my roadmap, I hand it to you and you have to figure out what's on the roadmap and kind of vet it. And, you know, Whatever along the way after 90 days, I'm going to look to say, well, it's, it's your roadmap now. You need to lobby why everything is in the position it's in and why it's there and the actual writing the things that are there and then telling me why they're there. You know what I mean? Why they're there, they're there. What a terrible way of explaining that. Anyway, you get my point, the current product offering, the potential new product offering, the potential new markets we can move into, how we're going to deal with competition. Like all this expressed via the roadmap, like it's now over to you. So what is like as a new employee, you don't know anything about our roadmap. Out to 90 days, 180 days, where you've now taking complete ownership of the roadmap, walk me through that process. How would you come on board as an employee again, assuming we have good practices, we have a strategy, we have a product vision. Yeah, I think it all starts with that vision, right? You have a product vision and it's clear. So as an incoming product manager, I would want to really understand that product vision. I would want to understand why the company is, why does it exist? Not just. what, what the offerings are and who our customers are, but why does it exist? What difference does that make, right? To, to, to, to the industry, to our customers. If you understand that, then the next level down is going to be, okay, in my little microcosm, I'm a product manager for a product series of product, whatever it is, product line. I need to understand how that contributes to the overall. Organizational strategy of what we're trying to do in this particular period. It could be a quarter could be a year. If you understand that you're well on your way to now, not only you know, understanding, but also crafting your own road map, right? What? How things fit into it. So then you'll be able to Confidently stand up and say, here's the roadmap. Here's how it contributes to our strategy for our current timeframe. And here's why the items are there are where they are on the roadmap. I mean, there's a lot there, right? There's a lot there. I've covered a lot of ground in that statement there yeah, there, there is a lot. I'm, I'm, I'm thinking of, there's assumptions built in as well. Like you really. Take the time to understand your customers. You understand your market, you understand your competition, right? The whole landscape. And figure out where you're positioned in that. Are you a market leader? Are you a laggard? You know, what are you leading on? What are you lagging on? All of those things. I'm also thinking about product managers coming into the foray. Like there may be. There may be historical trends that you may not be aware of. They basically, you may, you may need to dive deep into the data. Assuming that your product has that right to, to, to figure out what's going on with the market, right? With the market you may be taking over specific initiatives that your product or your business or whatever has kind of kicked off that you're in the middle of things that, you know, they weren't your decision, but they're in mid flight. So like we can do fight against them. I mean, probably not, right? Yeah. And then any upcoming milestones that have been kind of promised, you know, the, cause you might be in that, but we did a whole podcast on like, Oh, deadlines and agile and like people fight about them or whatever. But I'm like, yeah, you, but you can totally do deadlines. It's super easy. Yeah. You know, let's just talk about, you know. Yeah. You're right. You could have, you could have inherited somebody else's product. You really could have. Yeah. Right. Somebody moved on or whatever happened. And that assumes that that assumes that. Also again, if you listen to this podcast, you, you, you probably have some level of expertise in business agility. Again, like this assumes a level of business agility with your organization, but you might be stepping in talking about your product portfolio or your roadmap or whatever, with the assumption that like maybe your roadmap has drawn up in a way where. It is taking account for non cross functional teams, you know, Oh, QA on this date and this on this date and whatever. And like, so there's a whole process thing here that needs to be figured out to say, Hey, we really shouldn't be working like this. This is not the way the roadmap should be created or, or, or, you know, when you, you know, even like, I know we said we were going to stay away from this and this podcast just because we didn't get bogged down, but it's, it's too juicy not to get into Your roadmap is featured delivery on a, with milestones and deadlines, not business outcomes. Yeah. How many roadmaps are like that out there? I wonder, right? It's not a trivial amount for sure. I, we talked about, I got into this talking about understanding the product, the vision, the market the competitors, it also works the other way to your point, understand how your teams are structured today. Whether it's the way you like it or not, doesn't matter. Understand where they're coming from. Where are you today? I guess I'm going back to meet them where they're at. That's, that's part of the process that we just called out is, is you need to understand , we know that we all read the three Marty Kagan books. We know that we should be doing business outcomes in our roadmap. How come? All of my, like at the roadmap I look at and I grab all says deliver X feature by y date to z Zed customer. That's right. Z It's ZI learned, I've learned on the podcast. That's right. The Z customer. Yeah. Why is my roadmap like that? Oh, oh. I mean, it's like it that that's your first red flag to let you know like, oh, well, because you're product leaders now. Like they, they either don't wanna fight about this or they really don't understand. About , what a business outcome facing, you know, now, next, later modern style roadmap is maybe you found yourself with, it didn't come out in the interview process and now your first, you know, week of work or whatever you realize, Oh no, these people don't understand now, next, later they, they want everything on a deadline. Yeah, without testing you know, the, to without testing the appetite for that or whatever test. Yeah, that's a previous one. It's a d different podcast. Yeah. But no, because you've read all the Marty Cagan books. First thing you tell your product leader is Let's fire all our coaches. No. Oh no. Don't do that. No. Seriously though. Question everything. That's what it comes down to. You are handed things or you're, you are driven toward existing roadmaps, et cetera. Maybe you inherited it, but question it, question it, and look for quick wins because you just got on boarded. You're going to have to provide some evidence that, you know, you don't, you know, that whether it's 30, 60, 90 or not, you have to prove that you are adding value. So question it, ask questions and make small pivots and try and get some wins. You know, the interesting part about managing a product portfolio and or managing a roadmap. is managing the products finances. I think this should be something that's in your interview questions is, do I manage the P and L? You know, the profit and loss for this product, the top to bottom up to me to manage. And if the answer is no you have a red flag that you have to talk about in the interview and you really have to, you really have to think about this for a second before you accept the job. And a lot of people, I would say a lot of people, product managers have not, have not had P and L responsibilities. So they probably would be okay taking the job because they would say, well, at least. It's not as bad. It's, it's on an equal footing with all the previous responsibilities that I've ever had that, and, and they would look at it that way. Like, it's like, Oh, well, it's not that bad. Where I'm questioning it is if you're not in control of the finances, again, this is just my experience. I have found if you're not in control of the finances, that the slippery slope downhill slide to you're not in control of prioritization is super quick. It is extremely fast and, and that stuff can spiral out of control very quickly. Yeah, look, I agree with that completely. Right. If you're not, if you're not aware or, or in control or in charge of the finances for your product, you're not really a product manager, are you? That was contentious, wasn't it? No, really you're not right. Because what are you managing the product aside? Are you simply you know, in charge of formulating requirements? You're glorified BA. I'm sorry. Yeah. Right. You have to be responsible for the viability that the PNL, the PNL piece of it. If you're not the, and if you're just simply saying, you know, that's handed down to you, then that's the product manager, not you, whatever title they hold. So, yeah, I agree. It should be part of the Interview process. If you're interviewing to be a product manager, you really need to own the PNL process. Sure. You need to own whether the product is profitable or not. How can you do that without owning the accountability for it? I don't understand. I'll just tell you. Yeah. Dear product leader. I'm just a product owner then don't pay me as much as a product manager. Come on now. Yikes. Well, well, in, in the same vein as owning the PNL, let's pivot to something else. It's equally important is owning the customer experience. So customer experience, user experience, user insights, whatever you want to call it, like the, the, when you come on board in the early part, in the early part of coming on board as a product leader. product manager learning your customers talking to them, figuring out who they are, how they use the product, like what their problems are, you know, especially if you don't come from the domain business domain I think of putting yourself in the middle of whatever customer feedback processes that you have in place now, I don't know if they're surveys forms, you know, input like in, in app feedback, if that's a thing You know, I think in the inspired book, Marty Kagan talks about visiting like 30 customers in the field where they are. I mean, that, that, that was sort of like a, I don't know if it's exactly the same. He was, he was obviously talking about a B2B type of solution, right? But sessions to, to, to basically watch and sit with customers as a user product in whatever capacity that is. There's no substitute for that. Honestly, there's the only way to learn is to, you know, walk a day in their shoes. You can start if you're just onboarded to a new organization, you can start by working with your ops and support people. How difficult is our product to operationalize? And then once it's out in the wild, what are the issues that customers are reporting? You're just learning at a distance still, but you're learning, right? And then that would be hopefully a stepping stone to going out there and spending time with customers, right? Right. There is no substitute for that. Yeah. And until you start doing that, you can't really start segmenting your audience to say, well, these users use a product like this and these users, you know, like, that's like the, the, the, the stereotypical, like developer experiences that we didn't, we never expected this group of users to use a product like this. Whatever this is. But you know, the other thing that you didn't mention sales. Mm-Hmm. can help with this if, you know so like sales is like the on one end of the spectrum and customer solutions slash customer support is on the other end. Sure. Of the spectrum. You know, one is at the, you know, forefront when you're just. Touching when you're just talking to users to start and the other one is the users, you know, you are have been using your product in your experience for a period of time, potentially. So that's interesting. And these are all internal employees. So theoretically, you should have free reign to, you know, Go everywhere. They're accessible to you. Right. Completely. Yeah. Yeah. Sales is interesting because after you've been in the organization for a bit, you could actually accompany them on pre sales or at conferences. You should. And ask the questions of customers at that point, right before the customers even signed, you know, an LOI or MOU or whatever it is right up front. And that's a way you can learn about those signals, right? What's important to the customers. Well, in addition to what's important to the customers you have what's important to you, you, the person being onboarded, the, the, the new product manager in the organization What's important to you is the, that, that this is a position that you continue to develop your career and your, in, in, in your individual contributor skills, or even if you're a I guess you could be a product leader of product leaders, right? I guess, but not really where this is targeted, but the point is the same, whatever role you're in. You have to make sure that, that, that you have mentorship and or coaching. I read, I can't remember what book it was. I read recently. Oh, I actually, it might've been the, it might've been the transform Marty Kagan book where he was talking about product leaders. Like coaching is a big part of the product leaders job and really any manager's job. Like coaching is a big part of it. And if you're not doing coaching as a product leader what really are you doing? I think of the same thing as, as, as technical leads, any of the people in the leads position like coaching is a huge part of your job and if you're not doing that or you're not good at it or you, you know, you, you're too busy to do it or whatever, you know, coaching sessions. I don't know. Like, I don't know what you're really doing with your life and your job at this point. This is true. I absolutely, but you know, in some organizations those leaders are quote unquote too busy. Those coaching avenues just don't exist. In that case, if you're a new product manager coming into an org like that, look for things like product managers, community of practice. If there isn't one, guess what? Put your hand up and say, I'll start it. You're not the expert. You don't have to be, but you are initiating something as a forum for other people to come in and help one another out. Right. So I think that's a, that's what I would do if I was in a company where there was no such Avenue and I didn't have access to, you know, mentorship, coaching, right. From the product leadership you know, that, that, that strata I would say, just open up and say, let's, let's get together. Yeah. You know, let's just meet over lunch. Yeah. Let's talk about things. Yeah. I mean, if you're not, if you're not asking like you is the new you know, being on boarded product manager here, if you're not asking, you know, Hey, help me identify my skill gaps or areas that I can improve of what I'm doing day to day. And, off the top of my head, I think of organizations that you're just not, you don't want that, you don't want to. Expose that vulnerability because the, because the culture is the type of culture where, you know, Oh, that person's vulnerable. That's looked down on. Yeah. It's a sign of inadequacy and failure. You know, that's just not, I mean, what you were, what you were outlining participation in workshops and conferences and internal training programs and kicking things off and just be the first person to raise your hand and say like, Hey, it doesn't seem like we have a program for this or whatever. The way that that's perceived, it's just not in a positive light. That might be an organizational thing. And like, okay, that might be a problem with the organization. Let's put that aside for a second. But if it's just like, we're all too busy. Like this is where I've seen it more often is we're just too busy, right? We want to have a community practice. We have several teams with several different product managers and all the product managers kind of are a little bit different in the way that they. Approach. The situation, you know, approach their, their, their day to day. Maybe we should talk about our wins together in one forum. Maybe we can, you know, deploy like a lightweight lean coffee style, you know, approach, like it doesn't really require a lot of prep. I mean, like maybe a simple tool. You have to go find, you know, spend five minutes Googling for a lean coffee tool. You could, you could use anything. Literally. You could use Jamboard until the end of this month, which is the after Jamboard is being discontinued. Anyway, the point is you could use a collaborative you know, Word document, Google docs, whatever. It doesn't matter what you use, but do it. Cause it's the barrier to entry for that is so low. It just takes the willingness for someone to say. Like you were saying, you know, be vulnerable. Just say, let's set this up so we can help one another. And I think that's very powerful because it offers, it can, it can offer opportunities like, Hey I really don't know what I'm doing here. Has anybody come across this? Or can I shadow somebody for a bit who has done this before? There could be people at the org that have done, you know, product management for a bit longer than you just joining. So you can, you can take advantage of their. Tutorship their mentorship, right? But you have to start that if it doesn't exist and they would exist and be part of it, don't miss out. Shadowing is one that I call out a lot of times because I, I again, I, like I tell people, even when they're interviewing, I tell people If you were to pick up the scrum guide and read it, you know, all, whatever, 12, 12, 14 pages of whatever it is in all its glory, I was like, then you would be completely ready process wise to take over my teams as product manager, because I'm not doing anything that's different. I don't have any extra things plugged in than the scrum guide. And the, the, the biggest thing that I would, I would want to. Impart on a new product manager would be backlog refinements because the, the activity of backlog from it. That's right. I call it an activity. I didn't call an artifact. The activity of a backlog refinement is completely different on my teams than the sprint planning. And a lot of teams don't understand what the, a lot of developers I've talked to don't understand. They're like, I don't, I don't, I, They both look like playing sessions to me. I don't see a difference. Well, and I say, well, give it, give it a month or so you will see a difference. Yeah. Look, first of all, backlog refinements, not in the scrum guy. Right. So it's an activity and. We always tell people it is not a meeting, it is an outcome, right? Backlog refinement is an outcome, meaning, at the end of the meeting, people should have a better shared, better and improved shared understanding of what you're doing and why you're doing what you're doing. Unless you're doing that, backlog refinement tends to be one of those things where people just say, you know, I gotta drop after 30 minutes because I have another meeting. It's like, they're not bought into the concept of learn more about, What you're trying to do and why you're trying to do that. So I agree with that. I think there's a lot of, there's a lot of people that hide behind, and this is mainly the scrum master, but also a part of people, they say, if it's not in the scrum guide, we shouldn't be doing that. We'll just follow the scrum guide. It doesn't say how to do this or why we should do it. Right. Backlog refinement is one of those things and it's not an activity there. So they're like, well, you know, it's written down. They can ask me questions if they're in doubt. That is so wrong. Because they're not, not everybody's going to ask the questions. First of all, people are going to assume things. They'll have their own interpretations of what a written word actually means. As opposed to having a dialogue and having the opportunity to go back and forth. Or just even as a passive participant in that refinement meeting, you're Listening to questions and points that other people are making, which is improving your understanding, right? All of that is gone by the wayside if you do away with the activity. Hmm., the interesting part about this is that coaching, coaching, I would expect from my product leader that, that, that should just be a normal part of having a product leader. If you're going to call yourself a product leader, you know, which this is not the podcast to dig into the term product leader, because a lot of product leaders. Our managers, but I want to crowbar a part product, the role of coach and the role of mentor out of product leader. Because there may be product leaders out there that are not capable of being your mentor. And like a mentor is someone that to me, mentor is someone that you seek out and a coach is like a role your manager may or may not. Be able to play. They should be able to play, but may or may not be able to play. Do you understand where I'm I do absolutely understand where you're coming from. I'm glad that you don't, I'm glad you know where I'm coming from because I'm not exactly sure where I'm going with this. Mentorship is something that I think a lot of product leaders can provide because it's all about, here's what's worked in my experience or hasn't worked regardless of what their experience has been. That's mentorship, coaching is, let me help you with this journey. Yeah. Right. And mentorship could be a subset of that. Yeah. If the coach has gone through that themselves, but they don't have to have gone through that themselves. Yeah. This is not the destination that I had in mind when we had this podcast as an idea but since we're here let me walk this road a little bit going back to what I said early in the podcast, where a lot of. Quote product leaders, meaning people that hire product managers at the highest level in the organization, the chief product officer, they're not capable of mentoring product managers. Now they may be capable of coaching. Hey, when I was with you in this meeting, you know, you need to talk to the stakeholder. You need to be better at communication. You need to be better. They might be able to give you some, Some general coaching advice, but is that, is that also mentorship? Like. I don't, I'm not sure. No, it's not by definition. Look, if these CPO level people can not mentor you, it's because they've not had the experience themselves that you are either going through or about to go through. And we said earlier in the podcast. That's quite a lot of CPS out there that haven't done the work themselves, but they have the position, right? So in that case, they're not qualified to mentor you because they haven't gone through it themselves Now to your point about them being able to coach right on Things that they can do that after the fact and say, you know in this meeting you could have handled this this way, etc Okay, I mean that's fine, but it's really not Not it's really not coaching at that point. Right. Not even sure what that is. I think it's post event facilitation kind of feedback is what that is. If they were coaching, they would say when you did that. What did you expect to happen? And what, what actually happened? How could you have done it? So it's all asking more questions than giving directives, and then letting you figure out what you could have done differently yourself. And then leaving with a commitment. What are you going to try different next time? That's coaching. I don't see many CPOs doing that either. Unfortunately, I could see them doing that, but it wouldn't be on product practices. It would be on operations practices or, or, you know, sales or interpersonal relationship building or something like that. It would be things that are adjacent to product, but, but they would never, they would never coach you on something to say like, Hey, when you said that I need X feature over Y feature, or that we need, you know, all customers need to be able to perform X functionality. Don't you think you could have posed that as a question or an A B test of some side, some type to say okay, everyone on the development team says we've got to do functionality X before functionality Y, but how do, how do we know that functionality X or Y are the things that we need to do? Maybe we need to just test functionality X and depending on what comes out of the test. Then we try Y or Z or AA or AC or whatever, like a million other options. Like they're, they're not coaching you on product discovery practices. They're coaching you more on general. I'm not going to say life coach, cause that's not what it is, but they're, they're coaching you more in general, interpersonal skills or sales skills, or, I mean, related skills that were related to product management, but they're not exactly product management. So I don't know. I don't know. I don't even know what point I'm trying to make anymore is that kind of coaching is not I'm not saying that kind of coaching is doesn't have value, right? It still does, but it's just not product management. Correct? Exactly. Let's just call it what it is. I'm with you on that one. All right. Well, you've you've turned me around and I'm on your side now. So Successful Arguing Agile tonight. I'm super interested if anyone listening to this, Has a hot take on you know, any, any of what we're talking about, especially the, but what we, what we wrapped up with is mentoring and coaching. And, when you're quote leadership and quote, quote, cause I mean, really it's management we're talking about when they basically don't have the skill to coach you. Like I mean that they don't have the skill to coach you in your primary role. I'm not trying to make a statement that is, that, that, that says that, that, that coaching is not valuable. Right. It certainly could be. But like if you're new. And you're onboarding and they giving you general advice like, okay, that, I guess that's helpful for you as a person in all of your, you know, interpersonal communication and everything. But when we're talking about like, well, how do you, how do you choose to make bets in the market and test those bets? And, and, and how do you know, how do you identify that something is an assumption versus evidence? And how do you choose what evidence to pick over other evidence? Like they're not coaching you on product management, specific things, just identifying when, when, when things are not exactly equal and kind of understanding like, ah, you know, maybe this person doesn't have, doesn't have the exact right skill. That I need to advance myself in my career. Now you've got to go pound the pavement and go look for a mentor on your own. Yeah. It would be great to hear from people with, with, you know, that kind of feedback as well as if you are or have onboarded and your experiences being that all you're getting is advice that your grandma might give you and not necessarily product management related advice, you know let us know. We'd love to hear from you. Awesome. We'd love to hear about your grandma. Yeah. And also your grandma told me you should like, as described to this podcast. That's right. Ring that bell down below. She said yeah.