Arguing Agile

AA212 - Peak Product Management | Product Competencies

• Brian Orlando • Season 1 • Episode 212

Share episode

Who coaches PMs if Directors or CPOs don't understand how features get built? 

...or don't understand how to build a strategy?

Join Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel as we analyze Ravi Mehta's PM competency framework and debate which skills actually matter at each level of product management!

#ProductManagement #Leadership #ProductStrategy

REFERENCES

"How to Become a Peak Product Manager" by Ravi Mehta: https://www.ravi-mehta.com/product-manager-skills/

= = = = = = = = = = = =

LINKS 

  • Arguing Agile: http://arguingagile.com
  • YouTube: https://youtu.be/d9byEWuGbBo
  • Spotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
  • Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596

= = = = = = = = = = = =

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)

Hey, I'm wearing my flowered shirt. That's how you know that we're gonna be talking about something special today. It's gonna be a great discussion today. How do you become the fittest, baddest product manager ever? The the baddest dude. The, the peak-est dude. Oh, I prefer bad, bad, bad, bad dudes. Bad because they bad. There's that old like eighties video game. Well, we got off track real early in this podcast. All right, so we're gonna look at this article today. It was written about five years ago called how to Become a Peak Product Manager. I'm gonna put it on the screen for all you folks viewing it. Written by Ravi, Ravi Mehta not, not like Meta, the company spelled completely differently with a hundred percent less accusations coming to a podcast near you soon. But how to be a Peak Product Manager. In this article, he gives several competencies of a product manager and I figured that's what we're gonna do. We're just gonna basically peruse the article, look through the competencies, and kind of debate them back and forth. Nice quick podcast today. Ravi Mehta's background. Let's talk about that for one second. So his background he started his career as a program manager at Microsoft back in the, back in the dark times before the Empire. Well, the dark times were not before the Empire. Yeah, back in the dark times 1998. And then he went and worked for BCG. Then he was a COO Chief Operating Officer. Then he was an advisor. He jumped into a VP of product role. He cooked fries, made milkshakes he did his own stunts so VP of customer experience, and then he was the Chief Product Officer at Tinder. So that's the career path for everyone playing the game, listening along you need to do. That's quite a journey. Yeah, he kinda has worked everywhere now. He's an angel investor, so I guess that, I guess that's the LinkedIn way of telling everyone you are rich, cool beans. You're making the editing harder right now. Yeah. So, let's dive straight into his article. So he says, years ago he met an early PM at Microsoft who helped him develop what we think of product management today. Wow. That's a, that's quite a claim right there. But he says he says she told him that as a PM at Microsoft, which is a program manager, which is weird. So I guess program managers and product managers are the same thing. That's the statement. Mean they were back then. I don't know. I'm not even trying to get into the history lesson. He says you're like the mortar in a brick wall. Like mortar. You must fluidly fill the gaps between bricks to make the whole wall stronger. Solid. Great. So he says the best pm So this is his, his advice on the best PMs. So I don't know how sassy I wanna be in this podcast at Om. That's a, I don't why stop now. We're gonna get the opinion of someone who's never been an individual contributor, product manager in his life about what it takes to be a great product manager. What can go wrong? All right. The amount of times that this image has been reused by people though, and that the fact that it's permeated the, the, the meta. Yeah. Means that like it needs to be addressed. Like whether he actually knows what he's talking about or not, we're just gonna skip right over that and say it doesn't matter. This image is part of the culture. We're gonna talk about it. Okay? Yep. So let's dig in. He says he's codified the skills that it takes to be a really great PM into 12 competencies. He's organized those 12 competencies into four areas and those four areas. Again, for those people that are listening, i'm gonna go ahead and throw the image that he has in his blog here on the screen. The four main competencies are product execution, customer insight. Product strategy and influencing people in no particular order. In no particular order at all. So under that, he has three subgroups of topics. Okay. And we're just gonna follow his, we're gonna follow his outline here and we're just gonna go through the article 'cause he breaks each one down level importance. So I have a few questions to bound this podcast, and that's how we're gonna move forward. My questions are, do product managers really need this skill in our opinion?'cause he's saying these are the competencies. The wheel by which product managers are judged. You break a deal, you spin the wheel, that's the Tina Turner rules that we fall on the podcast. How, how, like, do they really need this skill? Like, is it real? Do they really need it? That's a great question. how often will they use it? In their position, bounded by their position, Do they have the ability to coach on this skill, which will be a less important question for individual contributor PMs maybe. Absolutely. Okay, Well let's go to the first category, product execution. So he says the foundation, the foundation of successful product management is the ability to work with a cross-functional team to define, build and launch well-designed, stable products. Peak PMs. Peak PMs. I like, I like it. It's peak. I'm peaking. Yeah, speaking PMs speaking's a journey. They strive to execute flawlessly. They know there's already enough risk in understanding customer needs and crafting strategy around those needs. They can't afford unforced errors, which is weird because that means there's such thing as a forced, forced error. Yeah, right. Exactly. That's weird. So execution. So we are going straight into execution and the way he laid out his thesis here is by having a spectrum of, I guess it's a spectrum of experience within product, Right. And then some kind of a color coding scheme, Where the colors fade out. I think it's either relevance or ability or expertise. I'm not quite sure. He never really gives a legend for the people listening to this. He has three breakdowns under the product execution category. We're starting with product execution.'cause that's like most people listen to the podcast. That's where they are. That's their, that that's their swim lane. Right. So he has three sub categories in here. He has feature specification, product delivery, and product quality assurance. So product delivery, that's exactly what it sounds like. Product, your ability to quickly deliver product functionality that accomplishes certain goals that have been spelled out. that's delivery product quality assurance is any Technical issues, bugs, that kind of stuff. keeping the software and the features that you're delivering. Quality. the last one, feature specification is the ability to take things that you're being told in store form and actually break them into larger containers of features. That can be delivered. The juicy stuff is asking. Okay. So for, let's start with product delivery that that's, that's the easiest one. Sure. Under product execution. Under product execution. Product delivery, he's got the, a PM sort of grayed out. The director and the senior director are sort of grayed out and the VP is completely, completely grayed out. Yeah. so he has several categories on here to, I guess also, well first to back up for a second and start, I'm showing on the screen now for everyone seeing it. he has six different levels on here. 1, 2, 3, 4, 5. He has seven different levels on here. Now, this probably aligns with the Silicon Valley leveling system where you come in as an APM out of the MBA pipeline through school, and then you become a solid individual contributor. You can sit on your own and do stuff and be trusted or whatever, but not that trusted. And then the senior PM is the real individual contributor. The group product manager has some kind of team lead supervisory function where they're Other PMs, They're not really a manager. And then the director is the people leader, hiring teams of people, that kind of stuff. Senior director is the director of directors, and then VP would be like the equivalent of our chief product officer type thing. So for the purpose of this podcast, we don't need 17 billion different categories right there. We really only need three main divisions of product management. We need the individual contributor PM no matter if they're a pm, pm, senior, pm, we need a product leader, meaning they directly supervise people, right? Whether they hire people or they're just in a lead capacity, it doesn't really matter if the group PM director, that kind of thing. And we need a VP slash CPO level, basically. Exec or leadership level, right? Exactly. We need those three levels. So we're gonna reinterpret on the fly for the future of this discussion. All of his levels to ic, product leader, CPO, those, those are our like simplicity level. So for product delivery, he says, this is mainly an IC thing with a little bit of the product leaders doing it, and then it's gone at the CPO level product delivery. I think if he's coming at it from the perspective of ability. A PM, they're green, basically. Junior people. Right. Okay. I can go with that. Ics we're, we're, we're looking at ICS here, right? Yeah. So maybe as you progress from the lowest level on the spectrum here, that is laid out a PMM toward PM and a senior pm, you're now becoming more and more proficient, is how I'm interpreting that at product delivery. I'm fine with his levels for product delivery. he says Hey, when you're an a PM, you're junior at this. even if we transfer to our levels and you lose a little bit in the translation to say a PM should be good at this. And then as you get further up into director or senior director or stuff like that, it's okay for them to not really know how to work with engineering teams, design that, , the Holy Trinity for Marty Cagan. Right. Right. So let's, we both agree we're, we're kind of in alignment with what he's saying here. Product delivery, he split product delivery into product quality assurance and product delivery as separate functions. And interesting is he has even less of the senior levels involved in product qa. That's interesting to me. That is interesting. But the flip side is interesting too. He has the opposite end of the spectrum. The darkest in in hue. Right. So, I mean, I'm kind of, I'm kind of with him on this one. I think he nailed this one. I think this is right. It's like the APMs, they're gonna make sure that everything that they're told, they're doing what they're told and they're gonna be ticking all the boxes, making sure everything works right. If you're not advancing in a lot of these other realms. This is where you could make an impact. You could Absolutely. That makes sense. you're just beginning your journey there. and then leadership at the other end really don't care about that. Feature specification it's interesting because it has, it has a very similar fade out to the QA track mm-hmm. Where once you get above, like actually even fades out sooner, where a PM pm, you know, the, the ICPM seems to have this nailed in his, in his estimation, and then it starts fading out in product leader quite a bit. Yeah. And then it's gone by the time you get to the VP CPO level. Right. So you're saying someone who's up here just throwing out strategy and like living at the executive level. He's saying like they, they just have no time to do this skill. I mean, maybe even if they did this skill in the past, they have no time to do it. They're not gonna do it. You know, that kind of stuff. Well, they're delegating it to all these gazillion layers underneath. Right. It sounds funny to say. I agree with this because the scary thing about this feature specification, like fading out at the group product level.'cause the group product level is, again, these are like your product team lead types of folks. Mm-hmm. And then he's even fading out of the director level. So what happens, like, who coaches the APMs? He's saying the APMs are really good at this. Right. I mean, who coaches them to be really good at this? Who's checking in with them being really good at this? I guess they're hired into it, I guess.. I mean, or APMs are typically green. They come in with no or little experience really. And they're suddenly hitting the ground running with.. Feature specs. Yeah. Defining functionality, setting goals. I don't know. I mean, or it's the senior PMs. This is like the, the I pmms are basically like keeping themselves on track, keeping themselves honest, you know, checking each other, that kind of thing. Yeah. This is probably the category I'm going to agree with him the most on that. Yes, these skills do fade out. I, I do worry though about the feature specification and like quality assurance being completely missing at high levels which is actually in line with my actual experience, right? These things are missing at high level, that they are, the people at high level are like, I just asked you to add this thing to the application. Why is it taking so long? I don't understand. I was like, actually, the thing you asked is like five features . it's gonna take us a month or so to deliver. And they don't understand because they, they truly don't understand, you know, because they've only ever worked sales in their previous career, or they worked as a chief revenue officer, now they got hired and you're a small company as a chief product officer. So you bring up a good point here, So when somebody's at a certain level is how they got there, right? Did they come up through the ranks doing the, the craft, the trade Yeah. And learning the stuff. And now they've evolved, beyond the day-to-day. That's one scenario. The other scenario is, yeah, they get hired in either out to B schools or other, you know, other venues.. Jump ship from one company to another. Cross roles like you said, you know, COO now you're a CPO or whatever. So , when you are in that situation, what happens to. Not only those immediately below them, but then, you know, the domino effect, right? Yeah. How do you get skills? How do you get mentored, right? How do you learn? So all of those questions are relevant here, the more layers you have like this. Well let me think about this.'cause I was gonna say, the more layers you have, the more apparent it would be, but now I'm checking myself thinking it might be less apparent. Right, right. Because there's more noise to get buried into. Well, I was gonna say, with this particular thing, when you hire a lot of people that don't have like, feature specifications, for example. In this, in this, like, we did a podcast on like, should I hire a business domain? PM or a pm Right. Sorry, I should go find the podcast somewhere, but I like, I'm trying to race through this podcast. In that podcast we said, okay, well most companies will hire a mix. You know, they don't wanna hire a whole bunch of people from the business, and now we've got nobody with actual PM experience and, maybe vice versa, right. In this one, I wonder you're gonna leverage those senior PMs that you have that know how to do the product management job and you're gonna lean on them when your group and director level folks can't coach. Right. So the problem is gonna get masked because your employees are gonna work between themselves. To figure out how to fill these gaps. just to be good, team partners, they're trying to be good team partners. And, people might listen to this podcast and say, oh, that's great. You're being cross-functional. Everything's great. But I mean, at an employee level, I'd like the level of frustration is like growing and be like, Hey, why do we keep hiring these people that I've gotta stop working on my stuff. Come over, help them out. And like come review time, none of that is reflected. I was, I haven't been promoted to group product manager 'cause we still got too many L whatever, we got too many L fours, right? And I'm an L three and blah, blah, blah. You know? Yeah. Yeah. So unless you're, unless you're measured on that stuff., Mentoring others, et cetera. This doesn't work. Alright, let's move on to the next level. So that was execution. That was, that was the excellence of execution. All right. Where's Brett Hard eye when I need him? All right. Where, where are we at? Here we go. All right. So yeah, I don't need his categories. So he goes on to customer insight, that's his next category. Product managers are cultural ambassadors for their customers. They understand customer needs and they represent those needs to the rest of the team. the very best PMs go a step further. They empathize with the people their products serve. And they care deeply about whether that product improves those people's lives. Okay. So there are three subgroupings under customer insight. And those three Subgroupings are number one, fluency with data. The ability to use data to generate actionable insights to connect goals to business outcomes, that kind of thing. Voice of the customer, the, ability to leverage user feedback to understand how users engage with the product and make better decisions. And then user experience design or ux, right? Working with the design team to help them figure out what ease of use, things to prioritize over other things. What boy, he uses a bunch of consulting speak in here. The ability to understand the modern practices of UX designers. Apply it to your application to make things easier, to use faster, less frustrating, make a more pleasant experience for the user. Yeah. Just reduce the friction for your users. Right? Right. It's much easier to summarize what these things are when I don't even look at the screen. Exactly. Yeah. So in here , let's talk about do they need this skill right quick? Yep. Fluency with data, he has this skill kind of questionably coming in as an a PM learns it, and then it's solid for every other role. Fluency with data is solid for every other role. and he has seven roles here, right? So APMs, I mean, if these are your college folks coming in, they gotta know the. Quantitative techniques at least, but they may not be fluent in how to interpret that. Right. And use it in your context. Okay, I'll go with that. The PMs, senior PMs, et cetera. Yeah. They really need to have those skills. Right. But then when you look at the top end of that spectrum, fluency with data at the leadership level has not been my experience. My experience has been they just wanna see a chart, basically. Or a dashboard. Or a dashboard. Right. Exactly. So don't deep dive in there. I just show 'em at a highly abstracted level, the data that basically forms a picture, right? Yeah. Don't show 'em the pixels. this one's difficult to play the old arguing agile game because I I hard pass. I don't agree that senior director, VP of the chief product officer, like, it's nice to say like, oh, they should be able to be read data and be very fluent with whatever. But like, my experience would been the exact opposite, actually. Show me a single pane of glass. Is what I get from like this. Right? Right. Yeah. So this one is easy to disagree with. We, you know, we both agree to disagree on the fluency data. Well, let's, let's get to it. Let's get to it. Actually, you know what, you know what before we move off of this one, let me hit one other category. I wanna highlight how like will they coach this skill and. I really disagree. Like I, I don't think I've ever heard coaching on fluency with data. From top down? No, I, I've heard like rambling is about like what widgets or whatever they want on their dashboard, but that's not fluency with data. Yeah, no, that's right. Yeah. I agree with you. So those people at the top end of this spectrum are possibly aren't even really familiar with the latest data analysis techniques, right? Right. They're probably not familiar with those. So how would they be coaching down? I don't know the way that all executives coach down just yelling. Yeah, yell and get it to me yesterday. That's right. The next category of voice of the customer, like, do they need this skill in the different levels? The ICPM, product leader, vp, CO vp, CPO I wanna say I wanna push back against what he has here because I think they all need the voice of the customer skill. And I think at the different levels you're dealing with different customers. Yep. I mean, to the CPO, their customer might be investors strictly. Where they don't talk to any users or whatever, they seem disconnected from the needs of the users. But if you want to get funding to keep, you know, if you want to get your Series B or whatever, like the CPO should be really in tune with those customers. And, , maybe you might wanna say like, well those are not real customers, Brian. Yeah. They kind of are sort of, but , if you really think about product management in terms of running the business, they kind of are. Yeah. This one is interesting because the a PM has the darkest shade here, which means that they have the ability, I guess, right. It says that underneath the ability to leverage user feedback in all its forums, like I, I'm gonna lean against that and say the a PM possibly doesn't have that ability. Yeah. Right. the IPM doesn't have that ability to the utmost level compared to those in the middle there. Right. Because you've had some days under your belt now, right. If you were a senior PM for example, yeah. You would be, I think your ability would be sharper there then it would be when the day you first came in. Right. That that's what I think. Yeah. Now then it fades out at the other level. Right. Again, I don't agree with that voice of the customer at like, to your point about different levels. So your executives are engaging with your customers at different levels, Than your PMs are. your engineering teams are, and you still need to be able to understand and relate to your customers. The big reason I disagree with these levels is because I feel strongly that the experience to coach. Voice of the customer. I think everybody should be coaching voice of the customer down to the next level below them, like the chief product officer, whatever, should be voicing their, like, oh, the investors this, the investors that, down to the director level, right? Folks. And then should be able to coach them on how to kind of talk to and elicit these opinions how to interview without bias. Like the things like this, you know, that like, I, I think everybody should have this skill. It's probably one of the more important skills. I agree with that. I think it's one of the most important skills because at the very top level, it's, it's not just about coaching down, it's also about succession planning. Right? You're thinking about who's gonna take your seat Yeah. As you, you know, as, as you move through, right? Now in reality. I think his chart's right. Yeah. So in reality, this is how most companies are set up, right? Except for that first piece, the ap PM, no, I think, I think in reality, I think his whole chart for voice to the customer, I think is right. I think the APMs are the people that read inspired, they just got outta school. They were just told like, oh, you know, be agile, pivot with what the customer like, you know what I mean? They're, they're the ones Oh, yeah, I see what you're saying. They're the ones that the, like the, the theory is ringing in their head and like the VPs are like, I don't understand. I told 'em every customer wants this. They should just build what I say. In reality, I think this chart is a hundred percent accurate. The further up in the company you go, the more disconnected you get with the actual people that use your software. Absolutely. And the more assumptions that you make, and because they were your ideas. And you think you're very smart. you wanna drive them home. Yes. I think in reality this is true, but if I'm gonna hold a mirror to this category and hold it up, I think if you're hiring a director or, you know, product management director or something like that, or a Chief product officer they should have some good solid techniques for really getting to the heart of the problem fast, identifying the problems fast. And that's all this voice of the customer stuff , when you hire them, you're gonna hire them. And then it's gonna be, I don't know how long until they learn that skill on your dime or don't Right. and they move on. Or don't, and they become a train wreck. But again, like think of what you could have had. In a chief product officer, if you hire somebody who had that skill versus didn't have that skill, and then eventually learn into, obviously like the worst case scenario is like you hire somebody, they didn't have that skill you thought they did, they never learn it. They're very arrogant, they wash out after a year and a half and you wasted a bunch of money and time and opportunity. The other, like the EI think the scarier side of that is the, the person that like you hire and then two, it takes them two years at a chief product officer level to grow into being able to ask good questions because like what could you have had for two years while this person learned that skill, that opportunity cost is huge or it can be huge. It's gone. Yeah. And the whole industry might have moved on. Right. So the UX and design uX design experience. Like when I started this, I didn't agree with his. Like he has a very niche area of career field expertise. Like, hey, right in that role where it's like the most senior of PMs and like the people that are like team lead, kind of like just moving into product leadership type of role. Like they're the only ones that are experts at this, can coach this. You know what I mean? basically he's saying also like, use this on a regular basis. and I said to myself when I first saw this chart, like that can't be true. Like UX has to be like, all these people have read Marty Ka and they know UX has to be like an integral part of your day. You gotta be a triad. or if you're someone selling AI tools on the internet, you gotta be an army of one, but you gotta be doing all this stuff But he's saying only these two are actually good at it, practicing it Yeah. I mean, the middle of the bell curve he has here, for me, the tails are a little bit wider. Yeah. I think at the PM level, it wouldn't be this faded out for me at least. Right. And likewise at the director level, again, we're assuming that people weren't just simply hired in without the appropriate experience and so forth. They actually know the craft well. I mean, some shops, , the Holy Trinity, the designer, the lead engineer, And the product manager, they work for different people on paper. Right. the tech lead works for the engineering manager and the product person works for the,, group PM or director of product. And then the UX person works for some ux, especially matrixed organizations. Yes. so from that perspective, I could see where this chart is implying that you only manage the product people. So your director of product, if they've never managed UX people, you know what I mean? Like, if a small shop, maybe all these people will be under engineering or product or something like that. Basically what I'm saying, what I'm arguing here is I could see his divisions here. I could pretty easily see, I've kind of come around to this. I'm still thinking that your PM really does need to understand deeply the ux. I think you're right. Design is, let's highlight the PM block a little bit more. meaning the individual contributor PM this is one of the first skills that you should be learning. collaborating with your UX designer to say like, Hey, I think this feature is important. What can we do to make sure we get adoption, make it easy to work with that kind of stuff and to really take their suggestions into consideration. I agree with that. you're contrasting with the voice of the customer we just talked about in the previous category. Just build this. Right. What do you, what do you, what you gonna do in ab test with these two different style buttons? One with a, a nice, you know, rounded corners and drop shadows and stuff like that. And then just like a, a blank 1997 button. Like, who cares? That's right. Just add a button. They can do whatever it doesn't, you know? Just build it and they'll come. This, the reality of this one is, it conflicts with the previous category. we're like, you have you, how dare I say? We're like on the, on the, on the. Further end of the spectrum where he has like VP slash cpo, like grayed out completely say, look, they're not gonna have this skill at all. Especially people that come in and are salespeople, they get hired into a chief product officer or COOs that get hired into a chief product officer position. they're likely, they've never worked with any UI design or UX experience tools or people. But they're probably not gonna respect it as a discipline. Maybe they do. I don't know., But they won't have the ability, I think this is what he's talking about here. The ability. So, And they won't be able to coach you. So, like I said, I started with this one where I saw his interpretation as very narrow, and I was like, it can't be that narrow. But in the course of our discussion, I'm like, actually, it can be, I think it can be that narrow. And I think it usually is. Pretty narrow where the UX folks have to really, and, and also if you're gonna shuffle user research, people under ux, those people have to fight for their salaries. When you have this person's like, ah, I know what the customer needs. Just build what I say. What do we need an army of UX researchers for? Absolutely correct. Trust me on this. So his next, his next category is product strategy. We've done many podcasts arguing Agile 1 0 3 on product strategy, mission, vision strategy He gives a little quote about product strategy. He says, unlike a standalone decision or goal, a strategy is a coherent set of analyses. I love saying analyses, concepts, policies, arguments, and actions that respond to a high stakes challenge. Not like a high stakes ca casino. Bet. Yeah, casino. Yeah. I do not like a high stakes poker game at the, at the casino Royale . But unlike a standalone feature or OKR. Good product strategy requires PMs to consistently deliver features that build towards a coherent roadmap that enables a company to achieve its overall strategy. That was tough to knock that out in one breath.. All right. Let's talk about product strategy. So I'm gonna, I'm gonna take, I'm gonna take some umbridge. Ah, that was a good one. I like that. Umbridge. Yeah. You like that one? From the word umbra where the word umbrella is derived from. Wow. Yes. I'm learning some today. I'm gonna take some umbrage with this one. I don't use the word umbridge lightly. All right. Like, I can jump into a, jump into a tree shadow and go to the nether realm or whatever. Yeah. My kids play too much Minecraft, Alright, so product strategy, right? That's the, that's the section product strategy. I think this is probably where I'm gonna start disagreeing with things. Okay. So he has three categories under product, strategy, business outcome, ownership, the ability to drive meaningful outcomes for the business, connected to product functionality and goals, right? Yeah. Strategic objective. So taking your strategy, turning into goals like going back to our mission, vision, strategy, goals type of thing. Right. Taking your strategy. Turning into goals, driving those goals into your roadmap and actually delivering things. Okay. His next category is product vision and roadmapping. All right? The ability to define, I'm gonna read his whole thing without editing it, just so I can align with what he's saying. The ability to define an overall vision for the PM's area of the product that can connects to the strategy for the team and the company. The ability to define a clear roadmap of highly prioritized features and initiatives that deliver against that vision. And I wanna read the final category, strategic impact. The ability to understand and contribute to the business strategy for PM's team and the company overall, the ability to bring strategy to fruition through the consistent delivery of business outcomes. Okay.. So business outcome ownership, like owning an outcome, not just a feature. Right. that's what I heard out of that one. I don't see that's different from the product delivery and the earlier, he separated them be, and I understand why he separated them because from his experience, he's kind of an operations guy , just get things done. Don't worry too much about like finding the right thing to do. Just kind of do what I tell you to do in the order I tell you to do it. That's like, that's what I think of as operations, right? So, but he's saying like, it's a different talent than just delivering things to figure out what business outcome levers to pull to make a real impact. I think that's the first category here. Okay, let's go with that. Right. But then all of the seven levels are lit up . i'm completely okay with this categorization there. So, business outcome ownership. Yes. For an A PM, how does an a PM own the outcome of strategic objectives here? I think they take ownership of it when they hear about the business strategy and the goal coming from that strategy, and they take the whole goal and say, Hey, I'm gonna make this goal my goal. And so they align their delivery to the goal. so if I were an A PM in a very large company, I would hook myself my whole career, everything to one goal from a strategy. And I would fiercely deflect. Everything that didn't have to do with that one goal, and I would just defend my little turf of my one goal and make a real deep impact on my one goal. that's how I would do it as a PM because again, I don't have a lot of experience, so I'm gonna make a lot of mistakes. So I wanna make sure that my mistakes are in line with just the one, like an APM think, I think what I'm saying, I'm, I'm a little bit facetious in this category, but I, but I think with an A PM, if you're being viewed as more junior, I think you can get away with trying to scope your work with a little bit of blinders on. Whereas when you're a senior pm, this doesn't really fly. Yeah. But you don't own the outcome. That's my point here. As an, as an a PM, you can't, you, you don't have the experience to own out outcomes. You alsot, you are basically producing outputs that you also don't have the, I mean, in reality, you don't really have the seniority either. You don't. You're just basically an order taker at that stage. An outcome for me might be to drive like, oh, I wrote the backend, API data endpoint, I need to drive it to one of my teams that has a product with a UI and a front end for them to use and call my API endpoint to surface it to customers or to surface it to more customers. Maybe my tool's tiny and I understand like, well, this is an experience kind of thing. Absolutely. It's partially, yeah. but I would say, I would lightly push back against what you're saying by asking, does the A PM need this skill? I think that's a yes. Like they really need this skill. They do need the skill, but they don't necessarily have it day one. I agree. I agree. So I, that's why I'm saying that the business outcome ownership for an A PM. Yeah, I can really align myself with that. I think for a pm Yes, sure. You can start to own things, right? Sure. But as an a PM, you're basically taking orders. Okay. Well is there anybody in this, in this swim lane IC-PMs product leaders, VP CPOs, is there anyone that cannot does not need to be able to coach this skill or be coached on this skill? I think, again, the, the highlighting here that he has, I think is great for this question is like, everybody needs to be actively seeking coaching for sure on this skill. so those that are up there in the upper end of the spectrum, If they don't have it, then they can't really coach those below them and so forth, business outcome ownership. This isn't taught in schools. You basically learn this through experience. Right. Which is why I say the a PM probably doesn't have it. They need it. They need to learn it. Product vision and road mapping. This is a tough one because I'm not really sure that this is a real category. the ability to define overall vision for the PM's area of the product that connects to the strategy, the ability to define a clear roadmap of highly prioritized features. so I think what he really means is the ability to create and maintain a prioritized roadmap that fulfills the strategy, right? Yeah. Yeah. So again, looking at this, the VPs at the top, they're just setting the strategies. They're not creating the roadmap. I'm with you already. Like, I would just, shift this whole thing. Actually, I would probably reverse. The way that he has this, so he has the first one completely grayed out. The APM is completely grayed out. I mean, maybe we can quibble a little bit about we, we've been beating up the APM in this podcast quite a bit. Yeah. I think at the CPO level product vision and roadmap, like even a strategy, I've seen very few VPs of product chief product officers who even can come up with a mission vision strategy. they even have a tough time, this is like director group, product manager level type of stuff. those are the people that I've observed that are really good at saying like, I think our company strategy is this. I think our product strategy, if you have a separate one, is this, I think our goals are these. And the goals might be a negotiation with the product managers, like the individual contributor product managers. But yeah, I would flip his chart the opposite direction. Yeah, I concur with that because even the apm, like you want to get the APMs and the individual contributor PMs involved in all the road roadmapping stuff.'cause they're the ones that have to carry out the roadmap. And they need to know how to craft those, right. So yeah, absolutely agree. Alright, strategic impact, the ability to understand and contribute to the business strategy for the PM's team and company. This ability to bring strategy to the fruition through the consistent delivery of business outcomes. I've read it twice now and I don't understand how it's different than the first category. It's the same thing in different words. Okay. All right. Well, I mean, that's what you do when you're in consulting professionally. You repeat the same thing over and over again. Yep. And you distill everything down to a two by two, give it a different score. So even if you, like, if we took for a second and just pretended that this was a standalone swim lane, strategic impact, why wouldn't every category be highlighted? Good point. Absolutely. Just, just like business outcome ownership. Like every category was highlighted. Everybody should be, I mean, why would you work on anything that doesn't have strategic impact? You're just wasting time at that point and resources. Right? So yeah, agreed. That makes no sense. Alright, speaking of no sense, let's move on to the next category. So let's move on to the last section called Influencing People. He says, peak PMs know that they're only as effective as their team. Like they view themselves as the connective tissue within the organization. Whoa, whoa, whoa, whoa. I, I do not view myself as tissue. Thank you very much. That was when I worked in the Air Force the, I would always hear like we need more bodies over here. We need more bodies over here. I'm like, I'm not, I'm not a body to be passed around. Thank you very much. I'm a nobody. Ooh, I ain't got no body. Where's David Lee Roth? Yeah, as they take on roles of increasing scope and responsibility to learn how to build and mentor strong PM teams, peak PMs I've said peak so many times. the word is starting to lose all meaning. Peak PMs are able to multiply their impact by enabling the people around them to contribute to and own the business impact necessary to achieve the company strategy. I, I really like some of this sentence, which is the best. Product managers are able to multiply their impact by enabling the people around them. Yep. They're force multiplier. He could have said that in one sentence, but the consulting version of this is to stretch it out because you get paid by words. It's very Dickensian is what I'm saying. So in the influencing people category, he has three subcategories. He has stakeholder management, team leadership, and managing up. Oh boy. These, like good categories managing up. that's salt in the wound managing up here. All right, so for stakeholder management, he says the ability to proactively identify stakeholders impacted by the PM's area of ownership and to work with those stakeholders to factor their requirements into product decisions. Okay. So for those of you, again, who can't see this. Almost every category is highlighted, but the a PM and the pm, so the, the low level well, actually the most of the individual contributor PMs are kind of like grayed out on this stakeholder management. Before you get in here, I'm gonna say I don't like this, I don't like this because I, this is another one of those categories I see in the opposite direction. Actually I see the VPs and the chief product officer, the more senior people, like they're the ones that don't really talk to most people on a regular basis. The people that are constantly just hammering stakeholder communication at an overwhelming pace. Yeah. Should be the individual contributor PMs. Exactly. That I was gonna suggest that I vehemently disagree with this, the color shading on this, and would flip it basically. Because the VPs, the senior people, right. They're not really worried about I, you know, identifying stakeholders. And, and how to make sure that the, the product managers realm, the product decisions as he says here, impact those stakeholders. Like that's, they're way above that. Right. So your APMs PMs, possibly the senior PM CPOs perhaps, that's the color shading that I would put on this. I sort of agree with that. I mean, there is a pushback here to say like, well, if they have to coach these skills there's an argument to say like, your chief product officer should be able to break down a segmented group of stakeholders. And identify their communication needs and really help you say, Hey, we're not doing enough here. We're not doing enough there, in reality, what I've seen is in fact quite the opposite. The people with the marketing skills and whatnot, like they're in marketing and sometimes you'll get a, you'll get like a, maybe not a chief product officer. You, you'll get a high level product person whose background is not in product management, it's in product marketing, but maybe the company can't tell the difference between product marketing and product management , and then those people were really freely identify those people really. Will be able to segment stakeholder groups quickly and easily.'cause they really naturally understand like, these people really care about this, and those people really care about that. And I'm gonna completely separate those groups. And they can help you a lot with your lines of communication. But how typical that is. I don't know, like my experience not, I've not seen VPs coaching down this particular skill, but I've, I have seen the occasional savvy, experienced veteran salesperson do this. Sure. Because they understand the landscape of, the stakeholders, right? So they can do that. And that's a great thing to point out. We normally look at people in that role, like people that only ever worked in sales and then became like a chief product officer. I normally will look at that negatively because there's a lot that is not on the table in that scenario. But if you're looking at it, if you are an individual contributor product manager and you work under someone like that, you have an opportunity to say, Hey, what can I learn from this person? Right. Well this stakeholder segmentation, like what actually could impact and hit the hardest with this audience? Yeah. Reach out.'cause that actually is in their wheelhouse. The rest of the stuff had to actually do product. Like they can't help you with that. So, right. I guess keep your resume updated and listen to your arguing Agile podcast. So the next category here is team leadership, the ability to manage and mentor direct reports. Team leadership, team leadership mentoring you know, more junior folks or helping out your peers, I guess, too.'cause again, sometimes maybe you've got a mix of individual contributor PMs. Some of them were hired with industry experience. Some of 'em are hired with PM experience that they don't have the industry experience. Yeah. So like you want that team working together, meshing together and teaching each other. Reaching across the aisle. I agree. This color shading isn't too far off for me. I think this is good because the junior folks there, well, they're not leaders, so,, they become leaders by being mentored by those that are Now we're in the middle of that spectrum. And likewise at the top of them. these people at the very top execs and leaders, They didn't become leaders just, through their technical skills or anything. They become leaders because they're good people, people, right. They know how to work with people. So if they coach down and mentor down that, that can work. So team leadership I think is pretty close to, you know, how I would've put it. That's interesting because I would, I would apply what you just said to the next category, to the managing up category. I would say the more senior you get in this track, individual contributor, product leader, CPO, the better you are at managing up. And I would say the only reason you got that promotion to that level is because you're really good at managing up. And I would say like the team leadership thing would be switched in the opposite direction. I would hope that it is the way that you're presenting it. Yeah. Well that's the ideal. I would hope that, like in the military for example, the people that are in the role of general or admiral or whatever, like, the flag officers. Mm-hmm. I would hope that they have the leadership skill where no matter what team they're with, new team, temporary team go to a conference and they get assigned with a group of people. They can quickly whip that group into a working functional unit very quickly just because of their honed skill at leadership that they've honed over an entire career, just naturally it seems natural to everyone else. it's not actually natural. It's honed over a whole career. That's right. Of, working with teams. But like in my experience it's actually not, again, in product that is not true. Only because the people at the most senior levels of product, it's very hit or miss where they came from, you know? Yeah. For product specifically. Yes. Yeah. Yes, that's very true. Some of the times when you look at these leaders at the very top in product specifically, and you wonder if they've worked on a product before. Well, where I got hung up with this one, with this team leadership category is with the graphic he has here, it implies the people at the most senior levels should be able to coach those skills down. Yes. But I've seen the direct opposite this, this is ideal, right? This is how we wish it was, but sure, the real life scenarios are very different. Yeah. So the last one, managing up. So I already gave away, I already played my hand with managing up. I already showed you all my cards are managing up. I think, I think the managing up track here is correct. Yeah. I think the, the, the people at the top of the organization, they become very good at managing up. And if I was to change the name of managing up to something else, they'd be good at that too. Yeah, we can't do that. This is a family podcast. Yeah. Yeah, I agree with that too. I mean, look, it is what it is, right? This actually aligns to what we see in real life too, right? People that are up there, they got up there because they know what to do. Right? Right. All right. So now we're at a point where we can summarize this whole thing. Right. Okay. I guess if I had to say this out loud, I'd say this could have been a one pager, probably, you know, that diagram. It didn't need to be so many segments. It didn't need to be so complex. We didn't need to have seven layers in there. But again, to your point, you know, this may be representing the Silicon Valley model. Well, he has some, in the end of the article, he has some takeaways to say like, Hey, you know, look at this, look at this chart and find yourself on here for what you're doing. Well, find yourself on here for what you're not doing well. And then kind of evaluate yourself and you know, ask for help where you need help. and then for people that are the product leaders here who actually hire product managers? You know hire better PMs, number one, hire better PMs, obviously, right? Like people have more of these skills, right? And then the other one is create a more balanced team because you want some people with, so let me present this and put this back on the screen. So , if you have this wheel. you have a lot of people that are really good at product execution and customer insight, but they're not good at influence or whatever. Like, well, maybe the next product manager you hire, then you'd be good at influence and customer insight. Yeah. Or whatever, you know, and then you can teach'em the other ones, right. Like you, you're looking for a balance between the whole team. Yeah. And you, it's gotta be realistic, right? You're not gonna find a unicorn that has multitude of these Right. Different areas right. Under their belt. Especially in your salary range. Very true. Well said. Yeah. So this, I mean this is an interesting, it's interesting graphic. There's a lot in here. some of these categories we probably could have spent a little more time kind of needling some of these categories and digging in. But again, at a high level, the dimensions make a lot of sense. And they're good to talk about and they're good to understand. Like, I'm weak at some of these. I'm stronger at some of these other ones. Like everybody is So it's good to see them, it's good to understand them and, and kind of be on the lookout. Yeah, and I think if you're a product manager looking to be a peak product manager, you could look through this. If you're already a Peak product manager though, you could look through this and come up with something else and become an Apex product manager