AA201 - Mastering Stakeholder Communication & Management

om, I wanna talk to you about communications. We just had a podcast on crucial conversations. So we're on this run of talking about communications, Product management is mainly about, in my opinion, anyway, this is just my opinion. This is not sponsored by anyone. Nobody's given us money to say this, especially not Jira, Jira. Welcome back to Arguing Agile. Communication is a big part of product management. that's really why this came up. Stakeholder communication is such a huge part of product management and I thought we'd take a podcast, just talk about some tactical, tips of how you can do a better job in stakeholder management and communication, this will be slightly different from our other podcasts in that by the time you finish listening to this, you'll have some things that you can implement right away, like the next morning or the same day. So that's the hope. Let's dive into this. This is a great topic. So we're going to bound this one with an article. It's our friend, Roman Pichler. You want to hear a smooth jazz again? Roman's product management podcast.. Like he's got to get that pressure went down already. Thanks for listening now some smooth jazz. So his article begins he says lead the stakeholders don't please don't dictate. He wrote two articles on stakeholder management one titled stakeholder management tips for product people And then, he updated it. Oh, he wrote it on June 20th, but he updated it December 6, 2024. Very recently. Okay. The other one that he wrote is getting stakeholder engagement right from 17 November 20 2015. I will tell you from a tactical nitty gritty boots on the ground. I don't know why I'm making up so many ridiculous euphemisms. From a tactical perspective, I like this one better. This one being older, it kind of aligns with the old fashioned, communication strategy or communication plan from the project management field quite well, I think. And in terms of what you adopt day to day,, there's a lot here for this older one that you can benefit from, right? This is getting stakeholder management getting stakeholder engagement right, He starts by saying, identify the stakeholders. A stakeholder is anyone who has a stake in the product, who is affected by it, or who shows an interest in it. While this definition includes customers and users, it's commonly used to refer to internal stakeholders. Note that some frameworks such as Scrum have their own stakeholder definition. In Scrum, the stakeholders are all interested parties apart from the product owner, the development team, and the Scrum master. For the purposes of this podcast, I don't care about the Scrum definition. your job as a product manager is to take ownership of all the comms, so I'm, I'm not, I'm not worried about kind of quibbling over what pools, right? To identify the stakeholders, ask yourself who's help you need to develop, release, and provide the product. The answer to this question will be specific to your product and company. For a commercial product, the group is likely to include representatives from marketing, sales, support, and management, but it might also comprise of legal, finance, human resources, For an in house product, your stakeholders might be operations the affected business units and management. So, he's cast a wide net, it could be a lot of people. He's mainly talking about internal people here let me flip over to the other article and see if he includes customers more prominently in the newer article. Well, in the second paragraph, he talks about. The first feature you deliver runs the risk of being a feature broker. poor user experience. How are you going to know it's a poor user experience unless you're actually speaking to your customers? To focus on your stakeholder management effort, identify your key stakeholders. those individuals with whom you want to establish, a trustful connection and collaborate on a regular basis. Maybe go back to the first paragraph, the second line says, while this definition includes users and customers. So that's the difference between this version and the version before. He's added customers to this. Which I think rightfully belong there, honestly. Okay, yeah, and I agree,. So a handy stakeholder analysis tool is the Power Interest Grid, the power interest grid developed by Ackerman and Eden. I'm going to show on the screen here, it's got the four stakeholder groups, players, subjects, context, setters, and the crowd as shown in the picture. Interest is on the Y axis and power is on the X axis. so he says identify your stakeholders and then group them into these squares and I love a two by two. Everybody loves a quad. Thank you. That's right there. Yeah. Thank you. Consultants all around the world. we love a quad too, but also on the podcast today we're going to use this quad because if you're a product manager and you come on for the first time to a company and you don't know anybody, you don't know their customers. You don't know their internal politics. And of course, because we're returned to office now and you got a nice office as a product manager. Let's be honest, you got a cube like throw this up somewhere and start putting the stickies on it and start developing it over time Put it in Miro or whatever and start compiling the stuff and throw it on your matrix for your product so I guess we're now diving straight into creating something, in this particular scene, you're brand new to a company. You just arrived here. You don't know who's who, right? you get invited to these meetings that suddenly appear on your calendar. You don't know the power brokers. You don't know anybody really. You start right now, but you don't have the information to start. So two things, right? One is you can start to create this on your own. Could be a chicken scratch on your notepad. Could be a mural Miro, whatever, doesn't matter. You can build it up as you get to learn people and their roles, etc. That is how I used to do things, but let me tell you that takes a long time. So instead of that, what can you do? one of the practical suggestions that we alluded to earlier that I have is make your whiteboard Share it with people make it visible and say who all has an interest in this space, You're not segmenting people day one because you don't even know who they are So you're just putting up a 2x2 whatever it is 3x3 doesn't matter Yeah, put that up there and say to everyone. Hey I'm sharing this with you so that you can put a sticky with your name on it in one of these squares. Interesting so you're gonna crowdsource this, but you're gonna ask the people that have something to gain or say, right? But you're not gonna use their word and say, this is where, 'cause you'll find that a lot of stickies will congregate in one square. But, but all I'm saying is it is a starting point. Right starting point towards what we're heading to in this podcast Which is an effective strategy to deal with communicating out to your stakeholders and customers. so yeah, why not put it out there one thing will happen for sure You'll get to know the names They may say they're interested in a certain way, they may be, they may not be. But at least you have a start. You'll jumpstart that exercise. I'm interested in digging, like this is not really the point of this podcast, but I'm interested in picking apart this example. Because like, I can think of some corporate cultures where this will not work. Like everyone thinks that they are high interest. You know, like executives, I'll give you an example, like an executive in operations or marketing not somebody that's in my reporting chain of command, not somebody who's my hiring manager like they're, a peer of my hiring manager. So you have a darted line to them., to me, they don't really have high interest in the individual features that come out they may be powerful. But they may not see themselves in the powerful, low interest area. they probably won't, right? Executives mostly will be like, I need to be in this square because, I'm high power, high interest. I need to exert my influence and peacock away. But that's okay, because you have a starting point. as you get to learn these people presumably you're doing other things in parallel, like holding meetings and getting to know people, et cetera, right? Introductions or whatever else. You will soon get to a point where you're moving people around on the on the matrix a lot faster This way, then the other way, which is just put them up there as you get to learn about them. Maybe most of these executives are just in the informed area. But I'm jumping ahead a bit, but we'll get to that, I want to put this back on the screen so people can see the quad. Oh no, I hit the lock button. I don't even know what the lock button does. So I put the quad up there and he gives you the power influence matrix, and then he walks you through each square. So circle gets a square, so would you want to start down here at low interest, low power? All right, let's start with low interest, low power. So this is the crowd, the crowd are stakeholders with low interest and low power as they are not very interested in your product and don't have the power to influence product decisions. The types of people that would be in this block. Low interest, low power, other product teams are in this category, believe it or not, like other product teams support teams are in this block. The general employees that don't work in product or , they're at the company. Vendors are in this category. Other departmental managers are in this category. So basically everybody, who doesn't necessarily use the product every day is in this category. I would agree with that. I think the crowd category is the biggest in terms of the number of people, right? Well, that would make sense because you need one way information to go out there because otherwise you get overwhelmed by this category if you didn't. It's , usually sufficient to keep. The individuals informed, for instance, by giving them access to the products, wiki , or update them on important developments in the form of a newsletter, he has quarterly updates this is like 10 years old I'm thinking you tell these folks things when major project milestones are either planned or accomplished. And in the form of a push update, like a one way communication update, he says newsletter, I think the modern version of newsletter is like a Either a blog post or like a, a SharePoint site or a Slack post to a channel that has a hundred people in it or more, that kind of news blast to a large group. Typically something like this you know, you don't wanna just simply do it after the event, whatever the event is. Yeah something go that you're delivering, let's say. It could be a feature. It could be a whole product. It doesn't matter. You want to do it ahead of time say, 90 days out, we're expecting to release X then 30 days later, say 60 days out. If it's still on track or not change it, that's fine. 30 days prior to the event, there's another one. And the reason why you do that is just the same reason why you see those late night infomercials talk about. The price and the phone number three times, once the event happens, at that point, just prior to it happening, a day before, Hey, tomorrow we have this thing happening. This is to the crowd, right? And then, a little while later, you could say, Here's what's happening. But now, it's not simply a repetition of what happened in the past. it's also a good thing to include the impact of that. Okay so here's what happened. And the impact of that is boom, whatever it is. And that's it. The crowd is now being pleased. Yeah let me take that into a more tactical room. So as a product manager me and my team are using these ALM tools, right? And they're blunt instruments, the ALM tool. So let's pretend that I use a very popular ALM tool that everyone uses. Could be a good tool, could be Jira, but let's pretend I use that system, right? what would be the points where I would want to blast something out to my crowd? Cause I may not have a 30, 60, 90 day, but what I might know is , when I go through a refinement and we plan an epic, for example, and we break down an epic, so the epic starts to form like, we can do two, three stories and we're sure we can do those. And then beyond that, we'll replan and maybe add some more stories it might be stories inside of an Epic, but It's enough for this group to know we've begun work on this epic and let's take a step back for a second. I have to assume that you're living in some kind of sane product development world where your team works on the highest priority and you're not split across five different teams and you're all engaged in like three different product lines. You're working out of two different backlogs or something like that. Let's pretend it's me with my team or maybe two teams working out of my backlog, sort of the way that I'm going about this podcast, I'm thinking of like trigger conditions like when we might've planned an epic and had all the work ready, the first time developer pulls it and starts working on the first story under that epic, I can blast out and let the audience know, Hey guys, we begun we've now, Completed our pivot. We completed whatever work was happening before. I probably have something that I have already blasted out to the audience to let them know we're done with something. And there's a flurry of activities with that. we'll talk about that in a second when you complete work. But what I'm talking about is you've started work and you're letting the audience know, Hey, this big initiative I've been talking about for a while, it's starting. Yeah, I think that's a really useful thing to do when you first start work on anything like that, just send that out and say, we've begun. I think it's also very useful to say, along with that here's the roadmap, just in case you don't have access to it or you've forgotten about it. We set about going on down this roadmap and we're here, so I like the now, next, later type of columns and then within that, I would have you know, whatever fiscal year you're in And then the quarter you're in and say this work was on our roadmap We've now started that They're usually rectangles representing keywords for Large bits of functionality, let's say it could be epics , whatever, all of those I turn gray like black and white Basically the whole thing I flatten into black and white that piece of functionality you just referenced that we're about to start work on I make that color and say this is in our roadmap. It's in that column that says we're in the current quarter we have begun it may or may not end in the current quarter. It doesn't matter we've started And that's communicating out to everybody, the crowd. We're on track on our roadmap. This is nothing new. Don't panic we've started work on it and you keep doing that throughout, right, not every day or every month or anything. It's contextual, but as you get closer to finishing that, send that out and say, we're about to finish this or do it as you finish it. You finish the last. bit of functionality in that feature or epic. we haven't even done integration or anything like that, but we finished development testing. Like what you're talking about now, it depends on your audience. some audiences are a lot more touchy than other audiences. I was going to say touchy feely. People want to know when, when's, when's this next feature. That I asked for going to be done or like a, in B2B development, especially in heavy sales led organizations, I'm very needy about needing to know the progress because I've got a whole bunch of stakeholders that I am managing as a salesperson and they're asking me all the time basically I'm looking for opportunities because I know there might be money under that rock when you guys get to that point. I think you probably could have triggers when, when big epics and swings like that start, but also there's like a, regular cadence you could be taking things out of development environments as things get turned in and taking screenshots and stuff and throwing out at it, whatever channel this is, this, this this is low interest, low power that we're talking about. So , whatever that is, like giving them a window into the development. Of the product and saying, Hey here's a preview of this new widget. the styling's not quite right. And we got more work to do, it's coming along. I'm just showing you, this is what you can expect in the next couple of weeks in the application or a couple of days, Expanding the comms to these folks that often feel like, they're just along for the ride. To make them feel more like they understand what's happening through the development process. Which to be honest, a lot of time is a very opaque process to most people. Sadly. A couple of things I want to talk about here really quick. One is, if you have stakeholders that are really pressuring you because they're managing their own, like the sales people you referenced, right? If they don't sell and deliver, we don't make money. So, okay, fine. But with them, you don't want to just share a marker on a timeline to say we've begun because as soon as you do that They will ask when are you ending this? Because we don't know when it can, go live in the wild? So I think rather than just screenshots you have to wrap some narrative around it and say, we've begun, we anticipate this taking anywhere between three and five sprints, as opposed to this date, Even though internally your team may have planned a date, it's just a plan. If you're putting this out there to people for awareness, it's great because the earlier you do that and the more frequent to a reasonable degree, the better, because you may have stakeholders in the crowd that aren't necessarily. Heavily vested, but they're in parallel working on something that may somehow depend on, or your work may depend on them. dependencies, that's really where I'm going. People can see, oh yeah, they've started work on this dependency item that we're dependent on ourselves, it's really serving the purpose of keeping them informed. And it cuts out a lot of noise if you can do this in the form of them reaching out to various individuals Perhaps your tech leads teams, whatever directly and say where are we at with this we need this We need this right? It's like well, we've shared this with you. Here's where we are and look for another update So with this communication, there's always visuals. I like pictures There's always some narrative and then there's always when's the next update? So they know otherwise they'll get impatient and ask you where are you at? Where will you be in a month from now? Yeah. Theoretically any of the individuals in any of the boxes, this stream of constant updates, that goes out to the crowd, to this low interest, low power crowd. anybody in any of these could be in that communication channel. If it's a slack channel with product announcements or whatever, they're seeing these announcements too. So whatever you put into this channel everyone could take advantage of it. Theoretically. You're absolutely correct. I would say though, in a channel like this. Avoid asking for decisions or directions of people that are in the other three boxes, right? Because they'll lose it in the noise. Yeah, right. Don't do that. Keep this as a general purpose, typically just a one way type of information, Here it is. And then sure, they can ask questions if it's Teams or Slack or whatever. And you can answer that, but you know, majority of the time, this is just information from you as a product person to them, you're not asking for feedback, you're not asking for decisions, none of that. That happens in the other channels that we'll get to in a bit. So if you do that, I think that's a good thing. So we said when you start things, when you finish things, and a window for things that are in progress. Those are the three things that we outlined I envision this as a very chatty meaning like I'm sending a lot of stuff. I would prefer it be one way. Cause I could only imagine this could be a gigantic audience. If you work at a company that's like tens of thousands of employees , it mainly is intended to be one way. So let's move up to high interest, but low power. So high interest, low power. I've got some things written down for this one. the teams that you work with as a product manager on a regular basis, the development team members, QA team members, business analysts, the people that you work with that comprise your team, UI UX people and users and customers go in this category. And then internal client teams that use your products, which is basically the same as end users and customers, if you're like a technical product manager and your stack is like backend APIs or something like that, that would be these folks. So it basically, this is where you shuffle your customer, into low power, high interest. Yeah, and I think there's a category where if your solution is it needs it folks at your customer side to kind of either install, configure, implement, use, whatever it might be trained, right? Those people, not the end users necessarily. Those people would also be in this category. Also, if you have a product that's internal, my first job as a product manager was internal tools and tooling Some people that worked in support and some people who work in QA and other developers were my customers. If you have people in house that use the tools to do something for the product, but they're not really like external users. You can't just say they're low interest, low power your tools are for them because the stuff they drive using the products drives value to the customers in kind of a roundabout way, it really is a direct way, I've seen more than more than a couple of shops. Think that those people they don't really matter they put them in the low category I'm like, no those people need to be involved in crafting what the most helpful things are yeah, So in this power interest matrix. I want to define power and interest so that we can use that to help guide the rest of the podcast. So let's take a second and talk about both of those categories. There's a few bullet points I wrote down for it. power assessment says, can they stop or delay your project? Do they control resources or budget? by resources here, I mean people like, can they take people off your team thereby delaying? So do they own the budget or do they own the people? Can they influence other key stakeholders? you come up with an idea that you think is great and then somebody else is turning around and undermining you, right? It does happen. do they have direct authority over? The outcomes of what you're doing, if they're a director or VP or chief product officer and you're a product manager working for them, they can be like, you're making all the wrong bets, Brian, these are not the problems I need. These are not the droids you're looking for. move along. And I'll be like, well, I guess I should move along then. that's the power assessment. Yeah, exactly. To boil it down, the high power people, cool. Can influence whether your product goes, what direction it goes in, what features you deliver or not deliver. When do you deliver them, right? They can influence that. That's the high power piece The low power people have no say there, regardless of their interest level, high or low. They don't have the, I hate to use the term, but authority. to change things in that way, as far as the interest level is concerned, I think we said the crowd is the largest. Anybody who has even a tangential interest, that's in that category. But the high interest people are people that have either the authority to change the way the products are delivered, right, or not. That's the power side of it. The high interest is They have taken the game because they might actually be impacted by what you're doing. So here's an example. You're delivering into production, something that needs to be operationalized and supported by somebody else, right? They'd be very interested in this because they have to make sure that they get knowledge, transfer, et cetera. You know, upscale their people so that the product can be supported. that's just one example So I have some bullets for interest as well interest is, how frequently does this group, ask for updates? how needy are they? do they actively participate in your. Product discussions. are they coming to your refinements? sprint reviews or product demos Are they directly impacted by the outcomes of what you're working on? And then, the last one is, do they normally provide unsolicited? Feedback. These are awesome points. these are things to watch out for. When we were doing the agenda for this. I was putting my notes into AI for help and it wrote a power matrix assessment, a survey that I could use as a product manager to go put in and rank my, like enter my user. And then answer some questions about my user. I might show the code for that before we're done here. I thought that was pretty interesting. depending on how many questions I answered, yes or no to shuffle them into these categories. I thought that was pretty interesting. It would be cool if I would totally host something like that as like, Hey, go onto this tool, add your user. Answer some questions, hit go, and then you'll get a number ranking then it will tell you what the thing is. just a real quick online tool to name your user, put their job role in, answer the survey questions, hit go, and then you have your score you can take that score and put it right on your chart and be like, Oh, I guess they're in this category. That'd be pretty cool. I love the idea. Cause a lot of times people struggle with that. where do I put this person? Well. You try and slot them in what you think is the correct square or put them in the crowd and if they need more, they'll yell. Okay. Well, so we had a couple of side tangents. we may or may not be returning from but we are in the high interest low power category. On the chart on the screen. High interest, low power folks are your sprint review invitees people that are coming to your refinements. You know, people that have a, a, a sake in the, the, the features basically that you're planning and delivering. So we're talking about the subjects. He calls them subjects. Just to read what he says, right? What Roman Pichler says with his smooth jazz subjects are individuals with high interest, but low power. We already covered that. They feel affected by the product and are keen to influence it, but they can't. Veto or change decisions. Subjects can make great allies who can help you secure understanding and buy in for your product. Keep them engaged and involve them on a regular basis, for instance, by inviting them to sprint review meetings and encouraging them to share their feedback, but don't make the mistake of saying yes to every idea and request subjects raise. Use the product strategy and roadmap to assess if an idea is helpful or not. If in doubt, consider running a brief and cheap experiment to find out if adding a feature would be beneficial. Brian will say, an even better example would be rope those subjects, those, those, those those low power, high interest folks, rope them in to somehow having a hand in those experiments so they can see that their ideas are garbage just like everyone else's ideas are garbage. Or not. And if their ideas are great, Give them the credit for those great ideas and pass that along I do the same thing with development teams. Sometimes people are like, Brian, this feature is really great. And I say, well, I'm glad that you like it. I'm glad you like it. The developers came up with that. I certainly pushed it forward, but I did very little on that. And I will pass the credit right along to whoever the credit is due to. Absolutely. That encourages the team to be more innovative, if they're in that environment. So I do agree with that. Yeah, I think involving people going beyond the sort of just information, which is what we talked about with the crowd. Yeah. Involving people is It's not necessarily, as Roman says don't, don't feel compelled to put in every feature they ask for, but do ask them for feedback, You can ask open ended feedback, or you can ask specific feedback about the feature. Both have their merits. Open ended would be as if you are a customer, how do you think this journey could be improved? What are some of the ways we can get better at what we're doing The product can be improved. These are just suggestions from them. treat these as suggestions. not directives. compile them and use that in the greater context of planning, make sure it's clear to them that just because you're asking for suggestions and they're providing doesn't mean you'll implement those features. Okay. That has to be clear. So, he has involved in the older article frequency monthly sprint review meetings. I assume this is more frequent than monthly, but I guess monthly is the minimum here, if they're involved in your. refinements and your sprint reviews. I assume you're talking to these people every other week at a minimum because they're probably in your refinements or at least your sprint reviews. at a team level, that's true. If you're in a scaled environment, monthly might be fine too. Okay, it's contextual. So maybe they don't need to see something because it's not significant enough. Maybe it's every other sprint because you're integrating with another team But the point is to involve them as frequently as needed and regularly. at a workplace I was at one time, We had a core group of people that we made sure to include at the sprint reviews. we would record the sprint reviews, which I absolutely detest. I don't like recording sprint reviews. But, this pool of people was actually quite large at that company. It was a, double digit number of people, like 12, 15 people. it was larger than like three people. Probably cause we had multiple teams But what we would do is we could always get the commitment of like two or three people from that pool of users with high interest, low power. They'd always ask questions in the Sprint Review. And then we'd record the session and post it internally so that all of the other people from that group of high interest, low power could watch the Sprint Review. And they might have contacts they might have some thoughts on the channel or whatever but normally they would take it internal to the group. First, and then they would talk about what they felt strongly about. then I would get the cliff notes version of that, at that company, it was actually quite an efficient model of getting a lot of discussion happening. Without me in the room filtering it down distilling the best advice out of it that would get back to me So it actually saved me a lot of time. I was gonna say yeah it could be your ally really as a broke person, right? Again, I will always say I do not prefer recording the meetings you should be at the meetings if you have actual interest and want to have a say but also It did kind of work out. You don't want to give them reasons to skip your meeting, they say, well, don't worry, this will be recorded. That's the problem. People are like, oh, it'll be recorded. I don't need to show up at all it takes time to get around that kind of behavior, but it can be done. Okay. Let's go back to the grid. So we'll, we'll diagonally move or diagonally move down to context setters, the consult block, which is the high power. Low interest, a interesting category for me, high power, low interest. I'm going to read again from the 2015 article, he says Roman Pichler, smooth jazz. He says, people with low interest but high power are called context setters or referees. They affect the product's context. But they take little interest in the product itself. An example is the person in charge of the development group. If the individual does not help staff the development team properly, then the success of the product may be at risk. Make sure that the context setters feel that their opinions, concerns, and ideas are heard and understood. Regularly consult them, for instance, by having one on one meetings. This ensures that their ideas and concerns are heard And helps avoid nasty surprises. Don't let the context setters intimidate you and don't allow them to dictate decisions. Be strong and have the courage to say no, even if faced with a powerful and pushy stakeholder. Now I have some examples of context setters. It says peer executives to your sponsor, your hiring manager Compliance and security officers, architectural review boards, enterprise architects if you have them budget committee members, legal team members. basically everybody else is what I'm seeing here. I like that, the big people in this category for me, Executives. Absolutely. These are context setters or referees that want to be involved. Oh, you know who else I didn't write down These are like your key sales folks, like your senior sales folks. if you have a VP of sales or the people that lead the sales team, those types of folks, you absolutely need to say like, well, where do you see the future? You know meaning here's the feature of the product. I need to make sure that customers want to buy in the way that we're planning to develop our features. Who's the person that knows that? It's gonna be these high level sales folks in the organization. that's just good advice that you should be seeking anyway. But in the purpose of the quad here what is the right, I mean, these people are, not going to come to your sprint reviews. So what is the right comms plan for these folks? I think of other businesses I've been in that you do like the quarterly all business review type of quarterly roadmap. this is where we were at, this is what we learned, this is when we adjusted. This is what we're planning to do in the next quarter. The quarterly planning, Caden it makes sense to make a real solid effort to make sure these people are in the quarterly planning. Because if they're not, you can make some bets that are just unhinged. disconnected from reality. Yes, and I agree with that. they should be aware that there's alignment here that you're seeking with them in terms of the direction you're heading in the next three months The other constituency that should be present here in this particular square is if you have, let's say a, a user group where your customers bandied together, there's a user group the power of many basically get them into this as well because they, they can tell you things that you've missed. You've probably talked to users probably on an individual level, more likely than not. Yeah. Collectively, you could hear from them. You can hear other things like. In their own areas, there could be regularity changes coming down. You might be blindsided to that because you're not involved. It's not your fault. You're not involved. would this be your software buyer as well in this category? If you're a B2B? Yes, in the B2B, absolutely. Yes. Okay. Yes. So one on ones I mean, I outlined the quarterly business review, stuff like that. One on ones obviously would be another one. you probably should do those on some kind of rolling cadence. Some people in this category are very difficult to get ahold of because they're executives or whatever. software buyers, you talk to these people by going to them when you work in product or sales you fly out to wherever they are. the frequency, we haven't talked about the frequency. account visits. your salespeople are doing this too. So you, as a product manager, can sign on to some of their trips. Yeah. So the context setters, he has quarterly. In one on one meetings. like I can see if you're saying a bare minimum perspective, I'll agree with that. these people are definitely going to be in your quarterly business review. Yep. I would say one on one, it'd be nice to be every month. I don't know if you're going to get these people every month. Are you going to have the bandwidth? Possibly not, right? But again, this doesn't have to be binary. Maybe you have some, very high profile customers, you can reach out to as often as you can but others, you may not be able to find the time on the calendar for them or yourself. So you have to find some other way of doing it, right? Which might be in the form of an open meeting, like a town hall type of thing, but with external people, Struggling to figure out a decent term for that, but awareness meetings, things like that. Yeah so it's not one or the other, you could find yourself doing one and the other, depends. It's that contextual nature of it., the account management thing is what's rattling around in my brain right now there are opportunities to bring these people in the VP of sales is going to have a constant. Account management, like world tour going on, regardless if you're there or not. So if you can, like that, that touch point becomes sometimes they're in a internal quarterly roadmap review meeting where they're just kind of listening and you're trying to pull them into the conversation. the one on one that I've written down here is you joining one of their account management visits or demos you finding a place on their calendar to show up and interact with in the normal day, you basically make a one on one out of you supporting their initiatives. I would look for this, this is probably the messiest category, this context center, because they're super busy and they're not necessarily going to make time for you. You know what I mean? Until you start doing something that they disagree with and now they're gonna be like, Wiley Coyote, it's too late by then. Yeah. I feel like you gotta get ahead of that. So, yeah, it's tricky. I agree. This is a tricky category, you might have to go to them more than the other categories that we've talked about you might have to integrate into their schedule. Yeah, I absolutely agree with that. Well, I mean, I'm fine with that. I actually kind of prefer that. It makes you more visible., it gets you more context. Especially if you're in a kind of environment in product development where the customer is kind of gated off and it's hard to get to the customer, which a lot of people are in that we don't really talk about. We should have a podcast just on that. It's like, hey, there's a lot of people out there saying that you should talk to the customer every day how regular really is that?, for product managers. It's worthy of a whole session by itself. I agree. Okay. we have one category left. now we're going to go up to high interest, high power. They are the quote players. Who are these people? They're your direct. Executive sponsor. They're the person you work for. They're the person you work for as a product manager. they potentially could be the product manager or key business stakeholder if you're trying to integrate with the system. They could be the person that pays the budget. They could be the person that pays the bills. they definitely have high power and probably also high interest, right? they also could be a steering committee member. We don't really talk about that too often on the podcast, that kind of arrangement. Could be a member of the product council, if not all of the product council, if you have that. you might be in an environment where you have a group product manager where you work directly for, you know what I mean, so they could be either that person or the CPO, in product it could be several layers of people And they could all be in this category. Yeah major client representatives go in this category as well. If you're a product manager and this is your group product manager director of product or chief product officer or whatever, I mean like weekly one on ones is like the, the cadence here of like the, they need to, because you're probably taking your cues from their direction and you're probably making bets and kind of like I was going to say flying planes and cashing checks, whatever, whatever the Ric Flair thing is, or you're flying checks and cash you're doing milestone meetings where you're saying, I'm about to test this thing because I think this is the next feature. Remember at the start of the podcast, I was talking about. when you're about to wrap an epic, and start a new one, How do we know what the next thing we're going into is? Like, I probably am running some tests and I probably make some decisions about what tests to run based off of like my intuition or whatever, but I'm checking that to make sure it's in line with our strategy. These are the people I check with. oftentimes a category of people, that come into this box is your PMO if you have one. I'm talking about the project management organization. Especially when they control the purse strings. and want to have those phase gate reviews at this stage. So, to your point about controlling the purse strings. You know, the go, no go decisions and so forth, right? they have . High power, high intent. So it says collaborate with the players. Stakeholders with high interest and high power are called players. Sorry, they're not called players. They're called players. These individuals are important partners for you as the product manager. You should therefore collaborate with them closely, for instance, by inviting them to product strategy and roadmapping workshops. They want input. And the ability to move some pieces around on the board. what bet are we going to make next? Where are we going to go next? Right. Make those trade off discussions, right? Absolutely. Absolutely. What are we giving up by doing this thing? Right. They want to be consulted on that. They aim to secure their buy in. Leverage your ideas and knowledge and establish a close and trustful relationship with them. I like the way that he put this it makes me feel warm and fuzzy inside I hope that you're in an organization where your chief product officer has product experience. That's what i'm saying I was gonna say 90 percent of companies, but that might come Yeah, yeah, I don't know about 90 but it's a big percent. Let's say additionally, ensure that the individuals are involved. with the product on a continuing basis to avoid loss of knowledge and handoffs. Avoid handoffs. Thanks, Roman Pichler. take that to your PMI Agile Alliance meeting. Next time it happens. is undesirable for instance, that the marketing group sends a new representative every time a strategy workshop or review meeting takes place. Instead one marketer should represent the group on a continued. So yeah, you want deep, long lasting, relationships with this category. Otherwise they are not in this category. They think they might want to be in this category, but they can't spare the time. They can't spare the focus. Bear in mind that collaboration requires leadership. you should be open and collaborative, but decisive at the same time. Aim to build consensus with the players and don't shy away from difficult conversations. See our episode, Crucial Conversations 198. Don't settle for the smallest common denominator and have the courage to make. A decision if no agreement can be achieved. I think if you're collaborating with the right playas. Sorry, I don't know why I can't, I can't say players. I, it's impossible. I was, I lived through the 90s, that's why. If you're collaborating with the right folks, you're not going to get in the, oh, we can't make a decision. The folks that I think of that all fit in this category. They, they're, they're purely like mode one thinking. You haven't finished saying what you want to say they've already made a decision. forget evidence. They've already made their decision that's the type of people I'm thinking of here. I get what he's saying. I'm glad I read the whole section because there was some good stuff in there. Agreed. Absolutely. one of the points that you started off this category with is, and I think he mentions that you don't want somebody new coming in every time. historical context matters, if you have the same. Group, ideally person, but group attending, you can have a meaningful discussion with outcomes that are realistic, right? Well, if you have somebody new, the best you can get out of that is I'll get back to you and you don't want that because that's a waste, right? So yeah, I do agree with Roman here. something interesting about his players category is the frequency you invite them to your sprint reviews and your collaborative workshops, including strategy and roadmap workshops I think roadmap workshops are like the quarterly meeting we were talking about with the context setters. They're kind of straddling the business strategy sessions, kind of what I think of as quarterlies. And they're also straddling, where the subjects were the high interest, low power folks where they're going to use sprint reviews. So that's interesting to me that they're kind of straddling both worlds. I think it's possible for them to straddle both worlds. If I think about your product manager, this is your direct supervisor and they're on all of your sprint reviews on the invite list. the only thing I would put a star next to is like, yeah, they're definitely going to make all the quarterly sessions with the roadmap stuff. Yeah. And I'm going to consult with them before I make my bets and put them on that roadmap list and bring them up. To the context setters in that big session where I'm expecting to get beat up As far as being on my sprint reviews, I'll put them on my sprint reviews as optional because I really do not expect them to show up. I expect them to show up when the last story in an Epic is closing or the first story in an Epic is being delivered. Like the, like the big swings of work are just starting or finishing or, or, or we're about to have. The takeaways from a big bet in the sprint review, that would be when I would expect them to show up otherwise I don't expect them to show up for every single sprint review. You make a good point about the frequency of this. by all means do not exclude them because they'll get FOMO. Put them in as optional for sure. if they show up, great. If they don't fine, it doesn't matter. This is, this is one of those tricky situations where you say, well they don't show up, but they'll say, send me a recording of the review. do you record your sprint reviews? I leave it up to the team If there's a call for it, I typically don't, the advantage of the sprint review is the feedback you get when you're showing the feature. you're actually putting your hands on and walking through the feature live, which needs to be synchronous and that's fine. They can catch the recording afterwards for the stuff that. They don't really have too much of an opinion on, they're just happy to see things moving, so that they're informed, so that when, if they're in whatever other meetings. with other executives. I'm assuming we're at the executive level Yeah, you are at this stage. Then they know the latest and greatest. Like, nobody's gonna catch them by surprise. The cynical side of Brian is these people work extra hard so that nobody can surprise them because the thing these folks hate is being surprised by anything in the business. they will work 80 hours if it means they can not the culture at that level in most organizations is kind of cutthroat. that's what forces this. I'm not saying it's a good thing or a bad thing. And what I definitely am saying is invite them, put them on as optional. maybe a third of the time they're going to join, maybe less than that. But I would say once a sprint as a frequency for this one, I think that's a little too frequent. I agree with that. Absolutely. first of all, I agree with where you were just going, which is in the players category, you have your boss, Possibly theirs. You do not want to surprise people. You don't want them to find out in some other way that something is happening. So yes, invite them. But I'd say more likely they may show up even less than a third of the time or a quarter of the time. These guys are busy. What happens if you're in a situation where you're delivering something that's a bit bigger than just your team, So you're delivering a capability that spans multiple teams. Then you may have, a review. It's not a sprint review necessarily, but it's a review of the functionality internally before. It goes out in the wild, they will, want to see holistically across the board, how this program wide initiative is shaping up right before it goes to the customers. So you're probably going to get them there. You may not get them at your sprint review, every sprint, but even if you get them once in a while, that's fine. It's on their calendar and they have the first right of refusal. One of the unexpected takeaways. From this conversation is I think I've softened. I think I've softened my take on recording. The sprint reviews after this conversation, I think about the category we started with, which was the crowd, these recorded sprint reviews, you could blast them out to the crowd because it's one way conversation, you don't really care what they say. I mean, that's, that's, that's a callous way to say is like, but, but it's, it's way more detail than that group ever needed. And it's more often than that group ever needed. So maybe, maybe, maybe the, the, the, maybe there, there is a little bit of pushback to be like, well, you really shouldn't communicate with that crowd. Every update along the way, after you're done with a group of features and an epic closes, do some kind of special recording to walk through all of how you implemented the like a special sprint review about a larger group of functionality. we need feedback to kind of tweak the thing and more to say like, this is how we ended this feature. It's a release review. If you like, it's a real, yeah. Yeah. The thing I like about this, this conversation is this, right. I want people to not say. Oh, we're not going to record and send nothing out. If you really feel the need to do it, I tend to kind of lean the other way and say, not really, because you want to be able to get that interactive feedback. Now, today where we are, you have AI on your meetings that can summarize your sprint review. So we use that all the time at my work, for example, we'll have AI create a summary. And we'll send that out that's a much shorter thing than a, one hour, one and a half hour sprint review meeting, which recorded people have to spend time. If you have summarized , some key points of what is being demonstrated, they can glance through that. Maybe pick up something or not, but at least they're informed. That's the crowd level i'm talking about But why can't you apply that right to the program level or release a review if you like do it there as well and just capture it because again not All of the people that are in that top, top right quadrant, we'll be able to attend. You'll have one person who will say sorry, can't make it. No worries. We'll send you a summary and attached with that is a link to the recording. Release recording. I'm okay with recording those release reviews. it's actually useful for your team as well. just in case they need to go back and look at something. So I'm fine with that. I've softened my stance on recording. But at the release level and at the sprint level, just leave it up to you. That's cool. There's a lot of takeaways in this podcast for me there was a lot more content in here than I expected when we started recording because we didn't even talk about Ways to rank people into these buckets and, score them and stuff like that I almost want to do a follow on but I have to think about it We haven't talked about that yet. There's a bunch of adjacent topics to this one to talk about. I also feel that when a release triggers and goes out to an environment we talked about QA, for example, when a release triggers, You could fire off an automated message to your QA folks that says, Hey, the release is out. It's in this environment. Just want to let you know, here's the work items that are out and ready. Here's the things that should be ready to test or whatever. if you have automation, you have automation reports. Those can go out. there is some automation strategy that works with what we've talked about already, in addition to some way to rank your users, to fit them into these buckets a little easier. I look forward to the next one. Cause I, this whole idea of ranking people in one of the four, buckets is important too despite all of that objective ranking, you still need to go over it and say, who are the individuals? What are their personalities? You got any people there that really are afraid of? Being left out and include them and manually kind of just tweak where they are in the four quadrants there's a lot of opportunity here to improve communications. when you start getting busy, this is the first thing that it takes to hit for most teams. Product managers are like a. Just teams, just software development teams, like you have product management on the side. if you have this plan written down somewhere, maybe it won't take the hit in quality, because at least you have some kind of plan. Most people have no plan at all. They wing it.. They do the best they can. given the way some organizations operate, they're lucky they get anything at all, but there is some kind of structured way you could do this. Come up with some kind of comms plan, maybe we'll do a follow up about automated triggers you can build into this process and think about it. And maybe you can be head and shoulders of all the other product managers sure. Absolutely. I look forward to that next follow up. All right. Well, that's. Probably going to do it for today. So you know those of you that stayed with us, thank you. Like and subscribe and don't forget to comment down below.