AA211 - Communication Is Product's Only Job, OR IS IT?
Arguing AgileMay 07, 2025x
211
00:55:0337.84 MB

AA211 - Communication Is Product's Only Job, OR IS IT?

Listen or watch as Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando debate whether communication is the primary function of product managers. 

We explore how and if PMs can balance effective communication across stakeholder groups while still delivering results, in addition to other topics, such as: 

  • What percentage really is communication
  • The power-interest matrix for stakeholder management
  • Balancing narrative leadership vs technical excellence
  • Creating vision without authority
  • Making the invisible turn visible
  • What makes a good one-page vision documents

#ProductManagement #Agile #Communication

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

REFERENCES

  1. Arguing Agile 201: Mastering Stakeholder Communication and Management
  2. Arguing Agile 205: Debating Impact versus Visibility in Product Management
  3. Arguing Agile 123: PRDs
  4. Who Moved My Cheese, Spencer Johnson, 1998
  5. Geoffrey Moore, Crossing the Chasm, 1991
  6. Working Backwards, Bill Carr & Colin Bryar, 2021
  7. The Power/Interest Grid, Eden & Ackermann, 1998

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

LINKS 

Arguing Agile: http://arguingagile.com

YouTube: https://youtu.be/MEKYApOb4xc

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)

We did a podcast where we read the real cynical version oh, I'm a burnt out product manager. And all that matters is that you play golf with the CEO. Yeah, we did. So are we gonna delve deeper into that today? Yeah, I think we should do a real version of that podcast where if we wanna be helpful to the listeners we should probably do a real version of that. I agree. And we do wanna be helpful to listeners.. Let's do that. Well, they get since when they get what they pay for. we did a podcast not too long ago. It was arguing Agile 2 0 5, debating impact versus visibility in product management. Where we talked about the false dichotomy between being good at your job versus being seen as valuable by leadership? Yeah. Playing the part, right? And being seen to play the part, or playing the role. Playing the role. Yes. Anytime I can get playing the role in it makes me feel like we're in our first 60 podcast where I didn't edit and everything was terrible. But on this one, I wanna make a real earnest effort to help people kind of understand that. A way of looking at product management is that communication is your primary job. if you look at product management, I can easily see, like at this point in the podcast, I haven't decided what side I'm gonna be on. I think I might be on the opposite side of this, but I could very easily see if you peel product management all the way back to the, the, if you take the skin off the banana and you peel it back first of all you go, Ooh, my goodness, what are we doing here? But when you get done with that I think you'll find at the core of product management is a, stripped down business leader role only without the equity of course. Because we ain't got no money for that. That's right. There's only so many yachts to go around. That's what I'm saying. All the responsibility of the founder. None of the equity. the responsibility parts of the founder, a big part of that is communication. Communication with users, communication internally, communication with your investors, Stakeholders, basically. Everybody. Upstream, downstream. Correct. research shows, I'm told that 68% here, 68% of product failure, stem from poor communication. That is a completely made up number to be 69. I don't know. Well, hey, you've calmed down. Hey, calm down over there. Yeah. So, so today we're gonna talk about that, right? What is the primary role? What is your primary, like responsibilities? Is it communication or is it working at the product level? what are you doing? let's start there. let's make the claim the product manager, the majority of their role, like 51%, minimum. Minimum. We're drawing a minimum, right? 51% communication is your role. 51%, right? I don't think there is a book like reference to go back to on this one. product management, the product space. Is scattered to the winds on this. There's no standards basically. There's no best practices here. surprisingly, even though most of the books focus on the tactical aspects of Product management, there's still not this kind of thing out there. So if you are a product manager and you are on the. Other side, you do communication when it's needed here and there, and you're mainly focused on your product, you have a fantastic product, right? people don't know about it. You're not communicating that out, even internally. Internally, you have to do a lot of communication. This is what I mean by downstream, if you're not doing an excellent job at that, it doesn't matter what your product does, it doesn't matter how good it is. I'm going to take the opposing side. So you'll be on the side. That communication is clearly 51 plus percent of your time, regardless of whatever condition you're in And I'll be on the other side. As crazy as it sounds that there is another, well, Brian, there's another side. How can you dare say there's another side? Like I would say the other side of this is, okay, some like you do need, like communication is something you need to do - communicate with stakeholders, but that's just a tool like reducing technical debt, doing strategy and planning for the future, working with your development teams through issues, monitoring logs, gathering data! Communications here, it's just another tool in the toolbox. sometimes you have to flex and do more of one tool than the other. But it's just like the claim of that's the only thing. And then everything else is optional. Well, yeah. Not the only thing, but a large part of what you do. So it's not a hundred percent we're saying, but it's more than 51. probably somewhere in the sixties, who knows, but probably not in the nineties, maybe. Right. Product managers are those translators between customers internal folks, right. Your own company, whatever you need to, to communicate. So if communication is not your strong suit, how can you succeed? Well, first of all, if communication's not your strong suit, and you're a product manager, you have some issues there. You need to look to the left and look to the right and figure out why you're working on that job. I, I think like on your side. I could see someone looking at this saying well, communications like it is important, but how much time does that take? I could see the finance bro like the private equity bro, looking at you and be like, Om, I understand you're saying communication is your mo most important thing, you're just sending some emails and stuff. communication is also meaning, you're taking time to decide things. how long does it take you to actually make a decision? Like what is that, like 10% of your time that someone asks you to make a decision and you make a decision? Like, how much can, how much time can that take? Making a decision itself isn't gonna take time. But it's the groundwork that leads up to it. that, cannot be done unless you're communicating really well. You could still make a decision without doing that, but then the quality of your decision can be brought into question. Right. Well, I'd like to take a moment to point out arguing Agile 2 0 1, mastering Stakeholder Communication and Management. Why is it not stakeholder management and communica? Anyway, it should be mastering stakeholder communication and mastering Stakeholder Management. Management. Yeah. That it's two things in one, which is crazy because the podcast is not even that long. because the idea that. just blasting out a marketing release takes two seconds. that idea is great. However, it's great for one block of the power interest grid, which we talked about in that podcast. But you have three other blocks that need more attention So that's not enough. And on the other side really focusing just on the communication portion may well lead you to gravitate towards creating endless PowerPoint decks and things like that. There is a point at which you have to figure out, is this too much information? Sometimes less is more, This is where you see the six pagers or the one pagers that people do and not the 30 page PowerPoint deck that no one's gonna finish in a half hour meeting anyway. Yeah. So this is where , the awareness in a product manager kicks in, communicating, but for what purpose and how much time to devote to that, how much energy to devote to that. And it comes with experience. one of the things we haven't talked about is your product your story that you're telling with your product. Mm. the narrative of where we're going in the future, how we got here, what pain points we solve, and where we're going in the future. that's, we didn't really talk I know we're gonna talk about that later. So I don't wanna go too deep into it now. Right. But that is the part that's essential here creating a narrative for the product. And building a future in people's minds, I'm not supposed to be arguing against this. I don't think I'm doing a great job. I guess if I'm arguing against this, I'm saying that's just another tool in the toolkit. you're just email blasting out these are the things we accomplished and this is what it unlocks for us in the future. And letting people come to you I'm trying to save you the product manager time for crafting a completely different message every time you do a release for a different audience and then spending time with that audience. at that point, you won't be able to talk to customers. All you'll be doing is driving around being , the hype man of the development team. You'll basically be doing marketing at that point. Yeah, exactly. But that's the extreme, right? So neither extreme is really desirable here, right? Absolutely. No matter how good your product is, it cannot overcome poor communication. It just can't. That's the takeaway from this category. Your decisions on the product. Like they'd be the best decisions in the world. But if you don't drive them out to the proper audiences. Again, going back to our podcasts on stakeholder management, yeah. There's a way to drive them out to different audiences if you don't drive them out to the audiences that need to hear the thing that they need to hear, again, listen to our other podcast. we laid out a framework there for you actually to hit all four quadrants to tailor your release. There's a way to do it where you're doing it in a mass media style. Like it doesn't take you a ton of time.. But also each audience is getting exactly what they need. The executives are getting how does this help position us with certain key customers or position us for the future? The user, high interest, low power users. They're getting like, here are the new features that help you save time. You know, there's a way to craft your message depending on the different audiences. Go listen to that podcast. I think it was oh 2 0 1. Yeah. Mastering Stakeholder Communication. Good podcast for this. your product decisions, don't mean anything unless you can properly communicate them to the audiences that make decisions or impact. Yeah. you can ignore any one of those quadrants at your peril, basically. Right. They're all important. At some point in time, you may vary the amount of effort and energy you spend on any one of them, but it's a continuum. you've gotta be on top of that. So for the scoring for this podcast, we're gonna go with the Facebook 2008 scoring. We're gonna give a thumbs up, is what we're gonna give. So for communications is your primary job. You should be spending majority of your time on it versus it's just a tool in the toolkit we're gonna give two thumbs up for, and one thumbs up against, because they're very close together as those arguments, but I think your executives will agree, more communication is desirable rather than, hey, be effective. But, you know, maybe occasionally people dunno that you even did a release. Yeah.'cause the damage caused by that is a lot worse, so let's go to a category that I think will be a little more challenging for me to defend, as a product manager, you have to create a vision and direction for the product because your executives are too incompetent to do it. Sorry, I, because your executives are too busy with other things. That's what I'm totally mean. What I heard is they're delegating that to you. They're delegating it. That's what it means. So which side are you on in, this one? For or against? I will be against. Okay. So we're on the category of, the idea that creating a vision without authority, without executive backing. Like the grassroots creating a vision like our team is gonna figure out what the customer needs and back into that as a company into our priorities. I don't know if that's a great way to go about things, that's my pushback against this category to say like, hey, the, the the like communication, it's the majority of the PM's job. And I will say, that's true. Communication is the majority of the PM's job. But the point where the company has no clearly expressed strategy, and then the PM just starts deciding strategies. I think, you're basically throwing a bunch of knives out on the ground and seeing who wants to fight you at this point. I think you're just inviting yourself into this world where another executive picks a knife up and is like, how dare you come up with a strategy? the big important heads are gonna go off on a retreat and hang out with Brian Chesky and talk about how they went on a hike and come back with a strategy. So a product manager who is emboldened enough to create a strategy like that, they could say, look, market opportunities, don't wait for people to come back from a retreat. I'm gonna have to do something quick and just do it.. 'cause , I've seen the data. So be data driven and go for it. The alternative is, well, you missed that window. I don't know which side I'm on at the moment, really, because if you have five product managers deciding strategy, you're gonna have a muddled strategy to say the least. Well, let me bring you to my side Om. Let me bring you to my side on this one, because I'm having a good time arguing against this one. normally I'd be arguing for this one listen, our vision needs to be on the same page. Otherwise, if we're in a company with several product managers, there's a lot of risk here. The risk is we could end up building the same thing for the same customer. Now we're all stepping over each other. Now we have duplicative effort. I love that word. Duplicative. Duplicative. That's a great one. Yeah, the arguing point against this one is pretty strong, most executives, as far as strategy, if strategy's a light in the dark, they couldn't find their way out of a paperback. They're chasing money no matter where that money comes from. if the money comes in the form of a customer saying, just do this one thing, build this one feature. And then that doesn't lend itself to your broader strategy, the direction your company's going. You're gonna spend 4, 6, 8 months building a thing with your development team, and then at the end of that 4, 6, 8 months, you're nowhere closer to your company's goals, to your vision, to a future state at all. You just did that so you can cash in on that opportunity. And then that customer at the end of the year, renewal season, whatever, they're like, ah, I'm out. Well, they get a better offer. Absolutely. and then your company will be like, hey, we gotta pay the bills. And this was money now. they'll make a lot of excuses. But, the product manager viewpoint here is, we should have said no. Actually the founder viewpoint here is, it might've been painful in the short term, but we should say no to that money. So that six months from now, eight months from now, we could be further towards the future we need to get to. It doesn't align with where we're going. Large companies, don't have this option. You have the vision laid out for you, right? Absolutely. So while I agree with you in real life, very few companies will say, no to the low hanging fruit. Right. this is kind of like talking about two extremes, but there's probably a middle ground here. the product manager could be autonomous enough to make strategy decisions, but not veer too far away from the organizational strategy. Yeah. Right. and that'll be okay, but if they do, then that might invite disaster. let me throw another one out to see if I can bring you closer to my position here This is the great one about product management. I love hearing people say, well, product management is, it's like the founder role, but without authority. So you have to lead by influence right? Without authority, like your vision, like your direction and your vision, you pull together, you go meet with customers, you talk to them, craft a vision, pull it all together, Without authority, that is just a suggestion. Your well researched viewpoint becomes just in opinion. Yeah. With without authority. This one's hard to argue against, especially when you consider multiple product managers potentially bringing their own strategy. Right. It's hard to get organizational alignment behind your strategy, because people are not gonna listen to you. They listen to the execs, if they don't do that, then you're not working in unison towards a strategic goal. Right? So this one's hard to argue out of. I'd say without authority, what would be better is to create the strategy and reach out to one of those people that are on the golf course with Brian Chesky and say, this is our strategy. Please blast this out. That's all they have to do. They can do that from their phone. So I kind of can't argue against that one. what's our scale today? Whatever the scale is, this one gets equal. Yeah. We're gonna call this one. I, I wrote two in one. I forgot where our scale was. Two and one. Sounds like scores of a soccer game. Sorry, I'm gonna give this one An equal amount of bunts and burners. I wrote little beakers on my pad with bunts and burners underneath them so it gets an equal amount of BTUs. That's right, that's right. BTUs. All these kind of like, tangents made me just want to do a live podcast. the next category I want to talk about is. on the podcast we did not too long ago, 2 0 1 of mastering Stakeholder Communication and Management Arguing Agile 2 0 1. We talk about the power interest matrix. breaking down your stakeholders in different segments of the quad. And in this category of stakeholder mapping you need to handle each segment differently, like completely differently, different framework, like in the low interest, low power, you're just blasting out to a Slack channel or over the internet or adding to your release notes and throwing into the application. Yeah. Whereas the high power, high interest folks, you're having a one-on-one with them like every week. Where you, like you were talking about like the different interviews that you're doing and what you're thinking, before you even made a decision, giving them a window to say Hey, I think I might make this decision I want to challenge that in this category if communications is your main job, you're just gonna manage this quad, like 24 7 and are you gonna have any time left to, to, to do any real work? Is there a way you can just send out decisions to the squad? is there a way you can spend less time doing this navigation of the quad and then get to real work? the flip side of that would be just don't bother, just send out. Communications to everybody, right? Maybe you can automate your communications at the quadrants where you're sending a more detailed message to your executives a less detailed message to your external users. And a, you know, a message with some notes to your internal, like, something like that, you know, y Yeah. Yeah. So doing that need and take a large percentage of your time if you can use the automation tools we have now, right? I still think you need to pay attention to your stakeholders needs and map them.. These people could make or break. What you're trying to do, especially those high power, high influence people. Yeah. Those people that segmentation, is needed, but not to the point where all you're doing is figuring out what to tell whom. We have the four quads, right? a power interest matrix and what do you do in the situation where, how do you keep the comms, because you're communicating out to those groups, those four separate groups. Four separate messages. Right. And inside those groups, it might be several, subgroups but let's just skip over that for a second. Yeah. And say you're communicating out to those groups and those groups are interacting with each other. So like in the case of high power, low interest. Mm-hmm. Those are like peers to your high power, high interest people that you work for. the high power folks, regardless if they have low or high interest, they're talking to each other behind the scenes. Yeah. So they're gonna talk to each other and they need to come to you to find out what the ground truth is.. Again, this could eat all of your time. It really should not if your communications are of a decent level of clarity in your preempting what they're really looking for from your comms, it need not take all of your time. Okay. So are you saying like the consistency of your messaging is not like. Good enough, like not detailed enough. So if a situation like that happens Where, oh, I talked to this person and they said they thought you were doing this or whatever. okay, well, I, the product manager haven't consistently put out a thorough enough message to all my groups. I need to refactor my messaging and send out more detail more detail or more clarity. I think that's true. or a larger horizon than I'm broadcasting possibly. Right? So at the end of the day, it's the WIIFMs, think about each of the quadrants and put yourself in their shoes and say, what's in it for me from here? So those people that are low interest but high. Influence high power, right? Yeah. It could be your CFO, they're not interested in the intricacies of your product, but they are interested in the financial side. Right. You could give them a little bit of information around the finances. Which the other people don't care about on the opposite quadrant, but also be open to follow ups. Right. Because that's nothing worse than simply sending out comms in, in almost like a one-way blast Type of situation. So put avenues up delegate some of the work. there's no one solution to this in real life. What will happen is you'll spend time on certain quadrants. Right. Some of the times. And then other times you'll spend time on other quadrants. Now you might think it's a waste of your time to go in that low lobe. Right. But they're important because they have strength in numbers. There's a lot of them there. The opposite quadrant, fewer people, but they matter too. So you gotta figure that out. Maybe you delegate some of that, you know, the actual comms part. the interesting part here is I have a note that says, executives should understand tactical constraints as well as the engineers understand business goals. So the idea is one group understands the other group's concerns equally well. from my perspective, you just have to be a wizard to be able to, I mean, it's not really being, a wizard. I'm being a little bit ridiculous. really what you have to do is, be empathetic from one end of the spectrum to the complete opposite end. So that everybody understands everybody else's view of the situation. That's really what's happening here. I guess I'm talking myself into losing this category because you need to spend enough time to build this like end-to-end bridge that everyone can walk on, and then the rest of the time is just maintaining it. But if you're starting as a product manager in a new organization and this level of communication doesn't exist, it's not gonna be 50% of your time. No, I got, I gotta, I got a wake up call for you. It's gonna be like 90% of your time to set up all of the Email blasts and release announcements and release notes and automated, pipelines or whatever that send this stuff out, until, the cross section is built. Where people are starting to unsubscribe from your comments to be like, look, Brian, I get it. Enough. And then you can pull it back and equalize on a like, okay, cool. Everyone understands now I think what you just described is reality, but today you can take advantage of automation. There's a lot of tools available to you. That can be automatically sent out based on conditions, you can do a lot there to expedite things, but , you have to build the bridges, right? So if you are new product manager, you've got to start there, build a bridge and earn That trust, with your stakeholders, that what you're sending out has merit and they can reach out to you if they have questions. If there are enough questions, instead of reaching out to each individual or each quadrant even, you could do a town hall type of meeting where everyone can come, so you're only spending half an hour to an hour across all of them. So you could use those kinds of, I guess. Techniques for want of a better expression. Yeah. To try and expedite things, but when you first go into an organization, you are starting from scratch. the bridges have to be built. All these bridges don't have to be built with, concrete. Some of these are stick bridges, you can get across it. Sometimes you don't have to build a bridge, it's a pontoon. Throw things on there and shove it across the river. There it goes. Just because I can't deal with this category without laughing anymore. I'm gonna give three London Bridges for stakeholder mapping, like for actually going through listing or arguing Agile. Two, only if you give arguing Agile 2 0 1 your time and attention. Three London Bridges for actually building bridges between yourself. And actually it's four, it's four stakeholder management categories. So Four London bridges. Each one, each for each category, each bridge that you're building between your stakeholder pool and yourself. I'm gonna give a London Bridge each, for each category. So four London bridges. And God saved the Queen. That's King now. That's right. Oh, oh, I can't deal with myself right now. point number four is that invisible work that you work on as a product manager or development team, you need to spend intentional time making that work turn from invisible to visible. Oh boy, why would you do that? Who cares? So that's the other side of it. Who cares? As long as I'm being effective, my work speaks for itself. why do I have to, toot my horn saying, look what I'm doing here, nobody cares about what you do to facilitate things. Customers don't care about that. Business value comes from releasing products. Shouldn't that be the measure of success for me? I mean, sometimes working on things that are invisible is enabling other teams. And sometimes working on things that are visible, like you are focusing on business outcomes rather than playing turf games. You know what I mean? Like winning internal points or scoring yards or whatever internally. sometimes you have to be a team player, And take the l for your own team or take a, like if we're doing flow internally, like, oh my team looks like we haven't released anything 'cause I've like seeded two team members time to this other team to get something over the finish line. Like, okay, well I look bad for a sprint or two. What am I gonna do at that point? am I gonna make a big cheerleading thing to be like, oh, my engineers are helping this other team because the way that's gonna sound, is this other team is terrible and I had to bail 'em out. That's what it's gonna sound like, but, what we're saying here is when you do that, you need to make that visible. So management can see only because Brian's team helped this other team was it possible for them to be successful because it's so incompetent, like Yeah. Yeah. That's, we just, it just sounds bad in my head. it does. And that's great if you are as a product manager or playing for brownie points, it's not for the greater good at the end of the day and senior leadership aren't even looking at this stuff. So it doesn't matter. You can jump up and down all you want. No one's listening. They only care about product success. Right? So that really is your measure of success. If you are a team player and you're making your teams better that's helping the team mature, right? It's not directly contributing to the product. Of course it is indirectly, but no one sees that, So should you make a big deal about that or just say, this is what I do? I'm gonna flip the tables on you and pivot to the for category and say like, what if you're a product manager who understands org design or if You have a particularly strong scrum master on your team and you reach out to help another, team, like, why should you not promote that to leadership to say like, Hey, only because we proactively knocked down all these cross team dependencies, or maybe we did this cross team architecture type of thing. only because we did that are we able to now in the next quarter really fly and deliver these things that the customers really care about, it's super easy to defend this category for me to say listen, results speak louder than any kind of release announcement or demo when you can show your executives, Hey, because I proactively made this decision to knock down this technical debt thing. Now we're able to do x y and Z feature and bring in revenue. if we didn't do that two months ago, three months ago when none of y'all believed in it. But I pushed through anyway. To hit my ROI and took it to my roadmap I deal with my did it with my team, because none of the other teams wanted to absorb it. Now all of the teams and all the products are able to accelerate. I feel like I'm being combative to all the decision makers now, saying, listen, trust that I know when it's time to put time. Into technical debt reduction and punching us through to the future. developing enabling features that help many teams. Those kind of like back of the house things like they are you, the product manager being effective over communication. Lots of teams need that like every team needs that. here we're saying if the majority of the time is spent communicating, that is less time away from doing things that actually make an impact. that's my arguing point in this category. I'm gonna take briefly the other side, even though I do agree with you, like please. I already know the other side is gonna be like, well, you can do that. And also communicate too. And also work 70 hours. That's where we're gonna end up as a product manager. For me, that's where I'm gonna end up is like, well, I gotta do that and I gotta communicate it and I gotta get ready for the future I'm gonna end up working 65 hours this week. that's what it really takes. Yeah. Unfortunately, right. To do all of this, that's true. Also, senior leadership only care for results. They don't care about operational difficulties. as a cynic if I were a senior leader and he came to me and said, listen, I knocked down all these things, reduce technical debt, et cetera, et cetera. A cynic might say, great. Why don't you do this sooner, three months ago? Yeah. Right. So it's like you can't catch a break because that's all they care about is the end result. So that's the other side of this, right? Yeah. I think there's a medium in there somewhere, like the messaging to senior leadership is, we did this because, but don't dwell on that because thing, right. Just move on. Mm-hmm. Just move on and then use the success that you have internally below that level. To evangelize, here's how we we're solving these things so other people can benefit from it. the arguing case of like, senior leaders only care about results. they don't necessarily care about how hard it was to get, or how many obstacles you overcame to get to that point. Doesn't that argue for my side where I'm saying making the, the, the, the value of this hidden work. Like making it like shining a light on the value of this hidden mark. Does it though, your peers may care about that.. But senior leadership, do they have time for all that organizational dysfunction? They don't wanna know how the sausage is made, it's just how many thousands of sausages have you made. Right. right. and why haven't you raised the price? Well, I think we're done with this category. I think we both kind of settled in the against category. We did. You need to make work visible, but the easiest way to make the work visible is to just do the work and be effective. Right. I guess my problem in this category is there are people that are ineffective but communicate regularly and effectively. those are the people that get promoted versus the people that inefficiently communicate. But slowly get work done that's like the boring sausage making process that consistently makes sausage. Yeah. And, that doesn't get immediate. Like you're right, you're not getting clicks on the internet for that. That's absolutely right. But the people promoting it, what you outlined. Yeah. I don't know. there's two sausages against it and it's hard to give any points in this category. May I'll give one sausage, one sausage, a burnt sausage. Oh, it's, I, lemme put lines on it. That way we know it's burnt. I mean, it's gonna get eaten either way. with sauerkraut and mustard on top of it. You can't tell if it's burnt or not. that's what I'm saying. That's right. I can tell how I eat mys sauerkraut and mustard. It's a big sausage. I wrote it on the paper. I'm gonna stop talking about sausage now. Let's talk about the experience recognition gap. Oh boy. I want to talk to you about another category, which I find real close in my heart. Okay. And the category, I, I call it the prove it first category. Oh, yeah. And here's the way this category works. I'll let you know what side I'm on with the way I describe this category. And the category works like this. I used to work for A CEO and his, his I'm, I'm, I'm broadcasting a potential future podcast right now. His viewpoint was a very, who Move My Cheese Viewpoint. Oh yeah. And it was basically, if you want a promotion, you need to start working that job that you wanna be promoted into. For like many months, right? If not years, many months. And when you've proven you can do it well in that job, and you've been working in that job for a while, only then will the executives choose to be the queen with the sword and bestow on you the rank of that job. Yeah. And that, that is the experience slash recognition gap. So this is one way organizations can get real good work out of people, but not pay them as much, right? Because you're striving to get that promotions, you're gonna do whatever it takes. And for a duration they deem. Is the price to pay. So, you have to put in the time, Brian, put in a year, two years, before you're eligible to be promoted. Unfortunately, this is also quite prevalent out there, especially in larger companies where everybody's like going after that, you know promotion in a cutthroat environment, no one gets promoted for a long time, but everyone's working hard. Sorry. I'm looking for the points and I can't find anything. Leadership qualities are only evident once you're doing the position. So the other side, right? Where perhaps the grass is greener, is you go play golf with those leaders. You don't have to necessarily do that work. none of this category applies when you play golf with the That's right. That's the nice thing about this category is like the idea that, oh, you gotta be doing the job before we promote you into it, and you've gotta be proving yourself , like the chief product officer. Who is like a sales guy that, has sold the contractor to Getting promoted to the, product thing, you know, to make sure we're building the quote right. Thing that our customers really need who has no product management experience, , the problem with this category and why this category gets no points with me, and there's absolutely no way you can convince me that this is a real thing is because there are people out there that get a job with no qualifications. Absolutely all too common, unfortunately. Right? Yeah. We've seen that, especially in the product management field., I talk about this all the time in the podcast. I'm not gonna go out on a limb and say every CPO in the world, but I will say most of them, a lot of CPOs never managed the product man. So, so against like three CPOs. And an R 2D two over there. And and a frowny face, a R 2D two. Wait, wait. I wrote, did you see what I wrote? I wrote two DI like RR 2D two, there you go. That company is just disguise this under, what do they call it? Probation. You're on probation. I thought you were gonna say exploitation. Well that too. Yeah. My bad. Narrative leadership versus technical excellence. this is a good one. this category, narrative leadership. Versus technical excellence. separates the seniors from the juniors when it comes to the PM realm. What it means is technical excellence. What it really means is like ex like the execution, the excellence of execution. I don't wanna be like the hitman over here, , yeah. The, the, it's, that's the first, pro wrestling Brett Hart reference. I'm wanna make! What it means is your ability to tell a good story versus your ability to execute as a person that works with a development team Yep. Into production. So I guess it's like storyteller versus operator is really what the category is. I'm not really sure. I'm willing to have my mind changed in this category because. I'm not sure which side I'm on with this one. So your ability to craft a narrative and then to spread that narrative to leadership, right? Sure. And then to everybody else, that buy-in for that narrative versus your technical and analytical excellence. Meaning like looking in data. This category is becoming the intuition versus evidence category, right? I just know. What they're gonna say. Yeah. that's starting to become this category. it is. But I think this is slightly different in that people that have that skill to weave and craft these stories from, what the customer's requirements are, their needs, their wishes, their desires those skills are special, right? Yeah. People listen to that and you can come up with all kinds of charts and point to those on the other side of the equation be data driven. Right? Yeah. That's great because , you are not just coming out with opinions, you are supplanting your stance, With actual data. Mm-hmm. But I don't think that trumps the other side tell story really? Yeah. I don't think it trumps that because. You get engagement upfront from hearing initially what's going on. So that typical thing that people say, what's your elevator speech, right? If you're talking to leadership and you have a great pitch and you can tell a story, you have skills. You can do that at each level in the organization, right? With your peers, with your teams. I think that's definitely valuable. I gotta tell you I'm supposed to be taking the opposite viewpoint and there are, things that I could point out here a focus on storytelling and telling great stories, just like they do in Silicon Valley, they tell great stories like, oh, my Theranos product can tell from your blood whether you're gonna, go to the moon or whatever. It's like the ability to tell a great story like marketing success. It doesn't necessarily come from telling you a great story. Product success doesn't necessarily come from telling a great story. At some point you have to back up your claims. but at the same stroke that I am disagreeing with you. I also am thinking in the back of my head of times in my career where a great story trumps evidence a hundred percent of the time. And, not even like it trumps evidence, meaning it forces everyone to take a second look at the evidence they have or whatever. It just blinds people. To the evidence at hand. Yeah. Completely of like, oh, I know that we're not getting any money in, but this sales pipeline, we feel real good and that there's some oil flowing through the pipeline and we just, you know, oh, it's such a great pipeline. And then we do that until the company goes bankrupt. I've seen that Too many times the people capable of weaving that narrative and telling that story. And bringing everybody along. I've seen it strongly portrayed, overriding every bit of everything I could argue against too many times to very seriously argue against this one. So first of all, you gotta recognize that remarkable stories, Stay with you for a long time. Data points don't, yeah. Right. So that's one thing. But to your point, if you're just telling stories. Not following through. Yeah. Then you're not gonna get any more VC money You can go only so far and say, round one, we're not making money. We don't even have a product, but we're getting mind share, maybe you don't need to. the funny thing about this is like all the AI companies that go and lobby the president and be like, oh, we could just be the best AI industry in the world if we just had 500 billion extra dollars. Please miss the president. Give us $500 billion. And just using your narrative on a different audience, that's just called marketing. I almost want to not talk about this category anymore because I don't think I'm gonna cover any extra ground because this strategy works. I guess my strongest pushback on the strategy is it works until it doesn't. Until it doesn't, until it doesn't work. And then you gotta pick up your carnival and move it to a new town to get money from them because the old town's not gonna come to your carnival anymore. Yeah. So it works until it doesn't work. I completely understand and seed all my points. One point for you, zero points for me. I'm perfectly willing to take that loss because, this is a personal failing of myself. I don't know how to combat that in that the storytelling like power in the human brain just can't, I don't know a way to overcome that. Yeah, I agree with that. Well, that's number six. Luckily we only gave one point for that, so we can move on quickly. Number seven, inheriting organizational chaos versus creating order. I think the point here is as a product manager, your job is to create order from the chaos. And my point against this is every minute that you are creating order better team structures, better communication structures, breaking down silos, every minute you spend doing that is a minute away from doing real PM work. And, you can be like, oh, Brian, communication is your real PM work. But I would say like, no PM work, like talking to your customers, figuring out better marketing schemes, better business models. That's PM work. Figuring out why your organization is. As poorly designed and scaled as possible. All the stuff that you think a scrum master and agile coach would do, like, I think this is a waste of time for a pm I can easily argue this one. Yeah. Listen, two things here that I want to talk about, ? If you're a PM and you're in an organization that is, say suboptimally designed and you have ideas to improve things here and there, but you don't do that because you're just too busy doing PM things, you're complicit in continuing that status quo, basically. Some will turn that around and say, but oh, that shows adaptability. We can even work in this crappy culture. Well, hang on Are you just doing things for the short term? Or do you want things to be better for the longer term too? Right? rather than say this is kind of heads or tails, black or white binary thing, you could do a little of this. But leave it to org design experts to come help you with that and do more on the PM side. it's not black and white in my opinion. I mean, creating an in adapting existing structures into better structures shows potential for you to become an executive leader. Yeah, I'm with you on that it does show that you're ready to become a, a founder entrepreneur, like, you know, original thinker type of deal. And also it shows that , maybe you should move on from this company who has no interest in bettering themselves, right? so that you can have more time. To actually do your job. Yeah. that's my problem with this category is why are these systemic problems from arguing Agile 1 99, the Deming podcast. Why, why are these things continuing? If everyone sees them, why doesn't someone intercept and deal with these problems so that you as a product manager can be free to do product management? I don't know. that's a fair point, right? I mean, product managers are elastic first trying to put the rock up hill. Yeah. we always give that advice too on this podcast, Rick, keep that resume updated because at some point you've gotta decide enough's enough. All right. Well against gets two rocks and four gets no rocks. Let's move on to the next category. Alright, the category that I'm excited about is self advocacy versus the work speaks for itself. This is a little bit similar to a previous category that we just did, but I wanna talk about this one specifically because I think this is one of the ones that I have a hard time with, which is if we're nailing things and customers are using it, you can see the effects of our work in the metrics, right? daily active use is rising, churn is dropping. The signup rate is increasing. You can see that we're nailing things, but then the company's like, rather than promote the. Product manager whose metrics are obviously on the rise. I'm gonna promote the product manager that I like better 'cause I like them. Because they talk to me on the weekends and they answer my slack messages at midnight when I post a random shower thought on a Sunday. They hear from these people all the time, as opposed to people that are just quietly sitting there getting the work done. So it kind of makes sense that, if that's who you know, you're gonna promote that person. People like promoting people they like. I get it. I don't know if I'm gonna come along with you on this one with that kind of attitude. I was trying to, I dunno why I'm so accusatory. That was a Yeah, but I mean like the, the, the self-promotion thing. I, I have a problem with the, I honestly would think for most people, self-promotion. Feels kind of slimy. It should. but we've seen lots of people who do it and they thrive at it, these are heroes. They wanna be heroes in the company and chances are they're not really team players. They don't give credit. You know?'cause it's all about me, me, me. So if they're doing that and leadership's not seeing that, I'd say we fall back to our normal advice here.. Keep that resume updated, I think I have a shot of winning this category. Because I do believe this category is important. I think it's important to go out of your way to separate your work from everyone else's work to say, Hey, this thing was successful because I was involved, however. The negative size of that is basically what I've seen all throughout my career where you are claiming ownership of everyone else's work that was successful. And then when the failures happen, you're nowhere to be seen. That's what I've seen normally. But if you're going to focus on outcomes and showing your stakeholders, no matter what quadrant they're in of the power interest matrix I think this could be a real tool for you. That, and also a big point against saying self advocacy is the only strategy, it doesn't matter if it's a success or failure the fact that you are promoting your own thing. Is the only thing that matters. I don't know if I believe that. I think there are certain organizational cultures where you can see this happening. You can see people getting promoted that basically toot their own horn. And then you've gotta think to yourself, well, if that's how leadership is promoting people and rewarding people, I have two choices basically. Be like that. Or take my expertise someplace else, it's sad but true that companies like that lose some good people. not everybody's good at doing that. A lot of people are good at peacocking is what I call it. Well, the takeaway from this category is a pretty hot take. It says Your brilliance has no organizational value. But at the same time, strategic self-advocacy isn't bragging, it's ensuring your contributions matter. So that takeaway is basically taking both sides of it and globbing it together. I don't know if I feel better about this or worse. Now the category's over, I think this one gets zero brags each side. Zero brags! let's go to our final point. It says one page vision versus comprehensive documentation. I'm glad we saved this one to last because we did do the PRD podcast arguing Agile 1 23 on PRDs, right? the claim here is the majority of product documents. Nobody reads them, So get all your chat PRDs, get all your, your funny glasses and your quirky quirks outta, outta your system because all of the AI systems you build to build your documents and all that kind of stuff, nobody's gonna read 'em. what you have a chance of getting read is a one-pager. This product, or I guess this feature, this big thing, this big swing that we're taking organizationally. You've got one page to communicate that to your people, which is actually a challenge to try and communicate everything you want to. On a single page, right? It is a challenge to see what are the right things to put there and the brevity of language, the clarity that's needed. Not everyone can do this, right? A savvy PM can perhaps do this, but not everyone can do this, the trade off here is yeah, one page gives everyone, one place to go back to, one place to add comments to, you know, it's pretty easy, The trade off here is like you can't do everything in one page, even Amazon has a six pager. You can't do everything in one page. So, that's my trade off to this. So while it's doubted as one page, what if it's two? What if it's three? Not, reams and reams of documentation. I think the one page simply means keep it really short and concise. That's really what I think from this. Listen, I've put together IKEA furniture where there's not a word in the manual. And somehow you manage, you have parts left over. It's important to say it's not just a single page necessarily, but it's brief. so you don't have this noise everywhere. You gotta go through references and all this different documentation. So I think when you talk about vision, it should be short and to the point. I can't imagine a vision document that's six pages long. No one's gonna read it. And if they read it, they wouldn't retain it. I get the arguing point that the unnecessary complexity, just doesn't need to be in there. It needs to say, here's the state of the world, here's where we're going and here's what the world will look like when we get there. that's it, maybe some high level, like must have, could have, type of stuff. Some bounding basically. I can go along with that. I can give you points for that. the hangups here that I have is if you're building a product that is inside of a suite of products, like one page could mask complexity. Let me about the YouTube like if you came up with a product like, oh, we're gonna just allow you to edit all the videos. In the world or whatever. You're like all in the whole world. Yeah. On YouTube. Like, come on, man. Like that's a insanely complex product that won't fit in one page. This goes back to what I was saying earlier, the ability to concisely craft what you're trying to do. So in that scenario, for example, maybe you need to break that down, right? Videos of this size, quality, et cetera, and that could be a one pager for each of those, perhaps. So you end up with four pages. Yeah. I'm perfectly fine ceeding this category because I think this is out of everything we talked about, probably the most important category, other than the initial one we started where 51% is communication, for the 49% of people you can't communicate with on a daily basis. You have somewhere to put down your thoughts, Think about a typical company, how many people can your company scale to until you just can't get to all of them in a day-to-day basis. that's where I'm going with this category. why? I think this is a good one to cut my losses and cash out, right? And just leave the casino before the house takes all my money. If you can't fit your product vision on one page. You haven't, come up with elevator pitches for new product features to pitch. If you can't fit them into a ten second pitch, they're not refined enough. Your pitches as a product manager for a new feature, let alone a whole product suite. They need to be very concise. And this is the document version for people that are actually our high interest. This is a high interest version. So like you can you get a whole page to dedicate, I mean, a whole page is a lot. It is a lot. So what is the content of that page? maybe we'll take that one to a separate podcast. Because that's a, that would be a good one. If we were to outline this product vision document without a lot of thought put into it, which we can cover in a different podcast, so like, we don't need to go too deep now. It would be your company strategy, your North star, how the two of them tied together. All right, let's, let's stick with that. And then any cross-functional dependencies, shared goals with other teams, other products, ways that they can contribute to this. Mm-hmm. Okay. What else would it be things that you need from other teams. Things that other teams can get from you, right? Other things are commitments that you need to be successful. This is a weird document at this point, but I can't imagine this all fits on one page. when we make this strategic decision, when leadership talks about this strategic thing, I need to be included because this product touches it. so if like, oh, if, like Brian Roman's development company, if, if like we develop a, a product that operates in the FinTech market and somebody in our company wants to talk about stock trading, we need to grab this product manager and bring them in Yep. To talk about like, oh, we are exploring this other, other feature or other product or partnering with another company that does something with stock trading. Okay. So there's some, there's some like organizational level working agreements that are happening. Yeah. Yeah. It's, it is basically akin to a contract between different teams contributing to a common product, so it's ending up being a vision document, a goals document being like, what does the world look like when we get there and also it becomes a working agreement document. So it's like three documents in one page. That needs to be a real, like whoever's editing that they need to be doing their job that day. I'm just saying. So yeah, those three headings you outlined, but at some point on that document, it has to relay what the. Solution or product is who the target audience is, presumably. I mean, this thing could go into two pages it could and that'd be perfectly acceptable. When you have this document, you could do a whole quarterly planning. on this document, and then when the quarter is finished and you've implemented some features and got some customer feedback, I would go back to this document and say, now that we implemented these things, how does this document change? do we want to change our goals, target different customers? Talk about personas, like all the things you do around the business. Could roll back up into this document, but, my main arguing point here in this podcast is if you establish this document, it can drive the rest of your business Maybe your working agreements get adjusted based on the things you find and the things you find don't need to be in this document. Or you're like, you know, you, when you change your goals as you accomplish goals, maybe your new goals go into this document. This document, whether it's one page or two, doesn't really matter. Is the single most important artifact where everyone is aligning themselves to it. Otherwise, you're not gonna build the right thing for the right people. So, when I said solution earlier, I should have said product. What is our product is, I'm thinking about like the Geoffrey Moore you know, our product. So if you put all of those things in, you're gonna exceed a page, I suspect. You very well could, I mean, the Amazon six pager is the industry, gold standard that people will reference for this. But I'm saying like, start with a page. Yeah. see what you can get from there. See what kind of alignment if you can't get enough alignment, expand it, you know what I mean? Two pages. I personally think just what we talked about, vision, goals, working agreements. I think you're already two pages. Yeah, I agree. So I could see starting per product. Or if it gets larger, you could do this type of document per large feature, like big roadmap, pivot type of yearly refocusing. Or maybe quarterly planning type of refocus. this is our next document that everyone agrees on. I think the important thing is that you reference this throughout. Yeah. Because if it is not something that you do and then put away or mount on a wall and it's done. Much like the other podcast that we talked about with vision and mission. This is something that you really need to keep coming back to whenever there's any kind of, disagreements or dissent or deviations from the mainstream understanding of what your product or product line is. I don't know if we've disagreed on this at all actually. Yeah, I think it's super important to align at the vision level. so with all the points tallied up all things being equal, that's right. Arch two, D two and C3 po are equal. That's what I'm saying. We've got a 11 in the four category and nine in the against category. And I think the nine is only because R 2D two only counts as one R two, D two and C3 PO counts as three po. That's right. So it's 11 against nine. Communication has become the primary job of the pm. That's what we've agreed on today, or at least that's what the numbers tell us. I am salty about losing this battle because I don't know if I agree with this one, but I'm just happy that both teams had fun. There you go, man. And that's the most important thing, right? Let us know in comments down below what you think about these things. And don't forget to like and subscribe. We'll see you next time.

product management,stakeholder communication,agile leadership,product strategy,product vision,technical excellence,organizational chaos,self-advocacy,one-page vision,