 Hi everyone. Welcome to today's product school panel discussion on managing stakeholder expectations. My name is Jenny. I'm a principal of PM at Disney in New York and I'll be moderating the session today. Yeah, and I'd love to kick it over to the panelists to do a quick introduction before we get started with questions. Great, Nithya. Do you want to get us started? Hi, my name is Nithya Chandrasekharan and I am a former Amazon PM and I've had some experience working across a very large and small companies. I'm glad to be joining this discussion with you, JT. Hi. Yeah, I'm JT Katzman. I am currently a senior product manager at Disney as well. I've spent a lot of years focusing on entertainment companies. So, you know, in a lot of big companies with logos that everyone knows. And I've sort of specialized in entertainment for my career. Cool. And I'm joining. I'm a senior PM and alloy where a series C from tech based in New York and we solve identity risk for financial companies. Thanks, everyone. All right, to get us started, one of the questions and we're just starting to get go through questions that we put together. We're obviously happy to take in other questions as well if we have time. One of the first questions was, how do you identify your stakeholders? I think, Nithya, this was a question that had come up. You had raised it would love to hear your thoughts on it and obviously everybody else feel free to chime in. Yeah, absolutely. I think when I was thinking about, you know, how do you identify stakeholders? I was primarily thinking about it from like, you go into a new company, a new team, you need to quickly identify who your direct and indirect stakeholders are. Right. So, the direct stakeholders could be your peers, you know, in the product function, design team, your engineering and, you know, obviously if you're a manager or a leader, then people who report you and into the org and another obvious stakeholder is your leadership group, right? People you report to and, you know, sort of the chain of command and there are other, you know, stakeholders as well that you need to be able to identify with the different cohorts of customers. If you are managing a portfolio of products, also like potential dependent teams that you are either in service of or stakeholders or dependent teams that you are dependent on. Right. So, really, I think it's super important that as a part of your like onboarding as well as the first 60 days, you're able to get a good grasp of who are the stakeholders, what do, you know, I and my team need from them and what do they need from me. And also that sort of helps you understand like what sort of information you need to be communicating across all these different groups. You know, I think that's a fantastic, fantastic answer and I think yeah in line with that I would very much add the building relationships with those stakeholders as well, you know, I think that's extremely important. And then those might change over time too, right? Like as your project, your products are progressive, like those stakeholder groups may have luck to wait. So yeah, I feel like it's almost an ongoing thing to be managing stakeholders and of keeping those relationships. Yeah, and also just helps I think both yourself and the team like better perform if you, you know, when you encounter a crisis or a problem that's not when you actually go need to discover who are the most important key stakeholders are. Yeah, absolutely. If I if I can also like add to that on that question and one thing that I found helpful in my that when I when I usually join a company is like ask the person that I just spoke to know who else I should, who else should I talk to because usually on similar topics or similar projects, they may know other people that I didn't know exists that I should talk to me have different context to asking that question sometimes may lead to additional stakeholders that may be helpful. Yeah, and I would add just one quick thing on the relationship building part of it. Absolutely super important. But I think that's the first step to establishing credibility. You know, as a product manager. There are moments in time where people are going to need to trust in you to do what you say you're going to do and, you know, by the deadline you say you're going to do it. That's very hard, especially when you join a company when when you're new and have, you know, no credibility in the minds of, you know, all stakeholders. It's it's critical to start building those relationships and getting little wins right so identifying small tasks, setting dates for when those tasks will be done and actually accomplishing those tasks are baby steps towards establishing your credibility and goes a long way in stakeholder conversations down the road. Yeah, I think those are awesome. Some super good points and I think to add to that, like the credibility piece I think communication and transparent communication, you know, to all your stakeholders. I feel like at least, you know, from a product management perspective, you'd rather over communicate than keep accidentally not have someone moved in, you know, which could potentially then lead to a small stakeholder crisis down the road. Yeah, I think also just to add to that one sort of interesting counterpoint to that is a very important part of identifying stakeholders is also identifying what sort of communication each of the party needs. It's a very, it's, you know, typically over communication is always better, but I've also been in situations where, you know, you're working on a product that, you know, some of the internal customers use and, you know, it's a, it's a lighthouse partner, right. It's a working relationship and you go so far as to invite them into, you know, discussions around, you know, any any critical like milestones, etc. And then now it's, it's, it's like you have to keep including them in all of these conversations and you are unable to manage the communication and the impact or is sort of like outsized right now you can't like payback. So I think it's also important to identify like, you know, who the stakeholders are what sort of communication they need and also like, you know, how frequently right and what is the sort of tone and outcome expected from that communication are you asking for help or informing them because they have a dependency or are you asking for extra budget or you know, people to hire it so it's really all of that sort of is the next level of conversation but I think it all sort of goes hand in hand with identify your stakeholders and then click another level deeper for what they need. I also feel that I just want to add. I think that self kind of corrects over time because I want to start before we start on this. Okay, this is some the type of thing that this person may care more about and therefore I would tailor communication to that a little bit. But yeah, 100% agree on the point that like some open can be maybe overdoing it over time. So there's always the point of adjusting as things go. I think Johnny touched on something that's super important as well which is not just the frequency of communication or the method of communication whether you know certain stakeholders prefer, you know, emails with lots of detail versus others that just, you know, need a slack message here and there to, you know, to understand that you're on the right track, but it's really telling tailoring your message to each individual. And I think Nipia was was saying about, you know, you stakeholders across the organization and, and even though, you know, presumably everyone you work with is a smart individual people who work in the design area don't necessarily think the same way as you do finance or, you know, just different personalities hear things differently and sometimes you need to tailor your message. Even though you're updating everyone at once. Oftentimes, you might need to tailor that message to your specific audience in order for them to truly understand what you're trying to say, I think I've spent, you know, sometimes trying to get a point across using sort of a blanket message for everyone and realize at some point that it's, it's not a failure of them hearing what I'm saying it's a failure in me making myself understood and so I think the role of a product manager has lots of sort of sub roles and one of those is a diplomat, you have to be diplomatic and and sort of talk to lots of different people about lots of different things. And not everyone hears things the same way so I think that's part of what makes you good at, you know, product management and specifically stakeholder management is, you know, really understanding who you're talking to and tailoring your message for that audience. To not agree more with all that's been said. And I think, yeah, that just kind of trying to go over to one of the next questions like I think, in line with that like you're, you're probably never going to make all your stakeholders happy. Right, there's, you know, you're never going to be able to do to build out all the features that people request, you know, so you're always going to have to draw the line somewhere and one of the questions that we have put together as well was, how do you prioritize right your stakeholders. I know maybe you originally brought up the question but yeah happy to just kind of kick off that conversation. Yeah, I think the one thing you touched on earlier is holds especially true for this which is, this is one thing that you have to continue adjusting over time, right like so. So, once you've identified your stakeholders right like, for example, customers, right or like your leadership team so as as over the course of the year if you're in the planning process, then you sort of engage more with one set of stakeholders and you have to be, you know, probably talking more to finance as they plan in the budget and leadership as you try to like communicate your themes and overall on your planning and goals and okay ours and what not right versus if you're, you know, closer to a milestone for launch. You know, of course you still have all those but you know you probably need to communicate over communicate with your engineering stakeholders right like and you know other your program managers and the whole set of other different types of stakeholders who are getting PR who help with the launch so I think it's really, you know, you have to have a framework for, you know, this is the time when I need to like stay hyper focused on on these groups so we don't want to have anything like going sideways, but it's just again, something you have to adjust over time. Anyone else? I could put like a more meta point on on that I think how we prioritize stakeholders like how we sort of talk to them when we tell them over time I think, ultimately that goes back to solving the problem that we wanted to solve. Which is like, it goes back to the product product that's being built really so throughout like based on the problem that we need to solve who needs to be involved and who needs to have more time and I think that's fundamentally what drives that how we think about prioritization over overall, they have like at some point of a project when we first kick something off and maybe the leadership needs to be involved so that we aligned on the strategic direction that we're going, but over the course of the project as we get closer to launch and maybe like marketing that needs to be a lot more because we need to make sure the message and everything is set up so that the products ready to go. So kind of so yeah that's all I think about it. Yeah, I would just add, you know, different phases require different prioritization. You know I think most people would agree that just depending on the type of product and how it's monetized, and if it's a revenue generating product that often gets the highest priority. You know, you have budget in order to continue doing other things. So, you know, I think a lot of times it's a trade off and, and, you know, there's people who are not involved on the revenue generating side of things that let's say let's just say again I've done a lot of entertainment for a large part of my career so you often have people on the creative side that are creating content and have lots of requirements around how that content needs to be presented. However, you know at the end of the day none of that really matters unless there's a revenue coming in to justify this product's existence right so you oftentimes need to make trade offs with people who are you know requesting features and functionality. You know, in order to prioritize some of the more baseline requirements that ultimately need to get done first in order to then have the luxury of working on, you know, things that are deeper in the backlog. Yeah, thank you everyone and I think we can maybe pivot over to a question Johnny that you had raised around. How do you handle when there's misalignment with stakeholders. Yeah, that happens. That never happens. Yeah, I think my mind, the way I think about it is, first of all, it's important to understand what type of misalignment it is. Like, is it that like people have different information therefore they come up with different kinds of conclusions or understanding of the Or is that we already have the same information but we have very different takes on what the next, what the best approach is. I think it depends on the situation, you know that there are different ways to sort of go through that. Yeah, if it's if we don't have the same information, great just make sure everybody has the same information that this goes back to communication it goes back to all the taxes we talked about earlier, how we manage that how we make sure people understand each other's takes. And but if it's people actually, but if it's in a situation people actually have very different takes with the same information, then it's time to have a intellectual debate on what's what's actually the best thing to do when it's for the user for the business, both. That's when trade off into a mate collectively. And I think on top of that, we also touched on relation building. I think that's also very important, but ultimately we're all humans. We want to always only rely on logic and facts, but that's usually not always the case. So, you know, we need to listen to the other side, we need to be genuine. It could be stressful moments, but I think at the end of the day, you know, teamwork that gets everybody gets everybody across the line. Yeah, I think one thing that has helped me, you know, when, like you say, stakeholder misalignment never happens, right. So the thing that I think has helped me quite a bit as like, not quite racy but I always think of like, you know, there's always like one or two stakeholders that are critical to any decision making versus there is like a slightly larger group of stakeholders that have slightly different responsibility, right. So, sometimes just thinking through that helps and, you know, which information or which sort of opinion carries more weight and again to what Johnny said, like, you know, are they making that recommendation having all the data right or is there anything, any course correction to be done. So, you know, to help lead them towards the same direction. So I think, you know, just to add to what Johnny said, like, when there is really like hard to break ties, and you have stakeholders that have like completely opposing opposing opinions, and you have to continue making progress like definitely also think about like who's in opinion, you know, decision is critical at that juncture, and that helps definitely make progress. Yeah, I would just add it also helps to do, you know, regular presentations, or, you know, whatever the methodology is whether it's a deck or presentation or something to make sure everyone's at least pretty close to being on the same page with regard to what you're building and why level setting if necessary for those that have a different impression of what was happening. You know, there's always going to be, you know, sort of resource collisions right you can only do a certain amount of work and any given moments in time and there's likely going to be more requests and there are resources fill those requests. So that that's just, you know, a constant communication. Sometimes it's delivering bad news. But you know I found it you know clear concise consistent communication is really the thing that that helps avoid some of these misalignments with regard to stakeholders. You know, having a consistent message and then delivering like I was saying earlier on on that message builds that credibility and, you know, ultimately will sort of ease the pressure I think, often with stakeholders who will kind of leave you to it. As opposed to try to jump in and micromanage or, you know, whatever the situation maybe. Yeah, thanks everyone. Sorry, Johnny, you wanted to. Yeah, I think touching on some of the things that others spoke about I think there's a point of disagree and commit that like there's going to be a point like there's going to be a lot of debate a lot of good ideas but at some point a decision needs to be made and some of the things that you may be made as well so I think disagree and commit sometimes sounds scary but it's actually very important thing that we can we all get comfortable with and say okay, I don't just I don't agree with what you're with with the direction is but we'll go with it, and then we'll pivot we'll learn and we'll figure out the next steps. Yeah, I think you brought up a fantastic point and actually very good transition into one of the next questions that I wanted to bring up around. Do you spend time also collecting feedback from stakeholders around what is working what isn't working, you know, I think, you know their mechanisms, once a project gets wrapped up to do a retro, you know, with engineering teams or other stakeholders, just be curious to hear from from all of you. You know, RDS certain mechanisms you use your recommend, do you spend time on that and yeah how does it inform kind of your other projects going forward. Yeah, I think gathering feedback is certainly a critical aspect of the relationship. You know, not everything goes right. But you want when things don't go right you definitely want to learn from that experience and not repeat the same issues over and over again. And it just goes back to credibility right so keep doing the things that interrupt or interfere with your ability to succeed, then you're going to lose credibility with people so absolutely understanding what works and what doesn't work. And with teams like engineering and design, you know, assuming you're building a product where you're all working collaboratively. Those are different, you know, they're assuming everyone works on a, you know, agile framework and, you know, we're working in sprints and at the end of those friends so you can talk about what work and what didn't. That's sort of all built into the process, assuming you're following that process somewhat religiously. It's harder when it comes to other stakeholders, right so is the marketing team getting what they need from you is finance getting what they need. Did you check off, you know, all the requirements with legal right those those are conversations that don't happen as frequently as product manager to engineer or product manager to designer. Those are a little bit harder to get feedback. But I, you know, I found that, you know, just checking in a little periodically, is this all working for you. Yes, no, what's not working. And that gives you enough to course correct if necessary to, you know, adapt your communication style or, you know, whatever the circumstance happens to be to to those individuals to bring them more into the fold, and, you know, increase your credibility with them in general. I definitely agree. I think in my experience, having like one on once with a couple of stakeholders, you know, even if you don't work with them like really regularly at least once a quarter just to understand like what's working what's not right like just, are there expectations that, you know, we're completely missing the point on right. So that kind of communication helps and also builds trust going back to the original conversation right so when you know when it's time to actually, you know, leverage the the trust and relationships so it's easier to communicate going forward like you already have it right so that mechanism definitely helps. We also, you know, especially for companies like Amazon right like my experience we also typically end up trying to get in on like either the planning process or just one or the, you know, QBRs for some of the teams that are not, you know, quite adjacent to us but we may need to work closely for some projects in the future so that just helps us understand the motivations when they're coming to us with an ask or when they're asking us questions or when the expectations somewhat misaligned to our own map that we know where they're coming from so that context helps immensely as a product manager and for my whole team, it just helps break down some of the walls. Those are amazing points I and I want to echo back to one of the points that we made earlier, which is like this is where relationship building is really important right because if we both go relationships then it's easier for the other side to share this is something that may not be working super well because usually, you know we don't like to share bad news. And sometimes it may get in the way of like making progress and making you know being productive, but building a relationship with different stakeholders definitely helps with that. Yeah, thank you, those are all really great points and I think I'm just kind of touching upon a few points that were made before. I think the, the part about building trust rate also being honest with yourself and with others admitting failure where, you know, when needed and not pointing fingers that thing you know this didn't go as planned and you know here's how we plan to pivot. And it's a very, you know very key part of, you know, it's okay when things aren't okay but to be able to course correct is important. There was a question that we had put together as well around how do you ensure you can keep your stakeholders motivated. You know, especially in, and potentially tricky times you know when things don't go as planned like, do you have some some things you would advise other people to do that have benefited you in the past. Yeah, I so it's funny I've experienced a few interesting scenarios where you know I've worked in some very highly politicized environments where certain stakeholders don't necessarily want to help, because if they help and the project fails whatever it is, then they'll be partially to blame for that failure. Right so it's almost a self fulfilling prophecy right if you don't get the cooperation and buy in from everyone, then your project is most certainly going to fail. So you really, it's really where those relationships come forward and I think that's, these are some of the soft skills for a product manager right is to, you know, not in meetings, not in emails, not in Slack messages but you know, maybe in person or whatever form in person takes nowadays when everyone's on video to to really understand the individual to understand the person. You know maybe explain why their participation is so critical in order to, you know, reach the level of success we're all trying to reach with whatever it is we're trying to do. So if it's a specific product, if it's a feature or specific piece of functionality. If you need buy in from other stakeholders, and they're being stingy with that buy in you need to figure out creative ways to bring them on board. You know that the more official or the most official way is to sort of go over their head and, you know, force them to participate but that's not going to get you the level of cooperation. Oftentimes that that you would want from those people so it's better to solve that sort of at your level and, and, you know, just kind of figure out what they need to be motivated, right to be, you know, obviously success is a motivator. You need to explain and you know do your best to make them realize that their participation is going to be the best, you know, root for all of us to succeed. I mean there's there's a million flavors of that and I'm sure you've all dealt with similar situations. Yeah, I've encountered that particularly when you are like pitching a new idea and, you know, most more often they're not the sort of reluctance of the lack of motivation comes from them not being able to understand, you know, what is in it for them or their team right because now to do X you have to be priority something else which is already on the roadmap and they've already committed so usually, you know, in those cases, as JT said, I think a one on one conversation with several, you know, members of that team helps like definitely try to pitch the idea and pitch the grandest version of the idea what's the role that we play in it like what's the, you know, what's the great outcome for customers that you're trying to showcase right. So I think advocating and evangelizing for what you're trying to do in whatever language that they can understand right I think that's, that's really the thing that has helped me doesn't always end up in a success but that's the sort of path that leads to each friction when you're in final meeting and you don't really want the key, you know, key members whose critical support you need to like say no, that's one approach that's like a start. Yeah, thank you both and I'm sorry we're running out of time I unfortunately need to wrap up the session. It was great chatting to all of you thank you so much for all the questions and and answers and a wonderful discussion and thanks to everybody for for timing and as well. Have a great rest of your day. Thanks. Thank you.