 Hi everyone. Thank you for joining. My name is Lauren Peters and in collaboration with the product school, I'm excited to speak to you all today about effective tips and tools for stakeholder management. Now, before we get started, I'd love to briefly introduce myself. I'm currently a senior product manager at Peloton Interactive. My team leads the end to end member delivery experience. We're responsible for everything that happens from when a member completes their order until it arrives in their home. Now, prior to Peloton, I've spent many years in the technology space. I first started learning about the intersection of business and technology when I got my degree at Syracuse University. After Syracuse, I immediately headed into the client services space and I spent about five years working as a technology consultant at Delight Digital. I worked with both e-com and healthcare clients and one of the biggest reasons I wanted to speak with you all today about stakeholder management is because of that client service experience. I learned a lot both about what to do and what not to do and working with someone all across the business. Now, as much as I enjoyed consulting, I wanted a bit more ownership over the decision making happening towards the products I was building, so I pursued a transition to product management. Now, before doing so, I did take a brief sabbatical. I got to travel the world and meet some incredible new people and have some incredible experiences. But when I returned, I was more confident than ever that I wanted to work in product. Before coming to Peloton, I spent a few years working at Walmart Labs. I got to work on their mobile platform, fulfillment, and marketplace products. Now, as I mentioned, the focus of our discussion today is stakeholder management. We'll basically be talking about three different areas. We'll first start with a background on what it is and how it applies to your role in product. We'll then cover three pillars of success. These are three areas I've identified that are going to be super helpful tools and being effective in this space. And finally, we'll apply those pillars and look at a real life example and figure out how to use them. Now, I encourage you as we're thinking about all of these topics to think about some of those most difficult stakeholders you've worked with, whether they be challenging, pushing against your decisions, or maybe they might just be a bit crabby, whatever it is. These are some tools to work with them as well as anyone else you work with on a day to day basis more effectively. The role of stakeholder management in product, what you see here on the screen is a sample product lifecycle. I'm sure at your company it might look a little bit different. But regardless of the approach and cycle that your team use, one thing that will all have in common is stakeholder management. It's the active communicating with any of the partners that you're working with across all of these different stages that your product goes through. So what is stakeholder management? According to the definition from Google, it is the identification, analysis, and planning of actions to communicate with, negotiate with, and influence stakeholders. But I really think it's about people, it's about building relationships with the people that you work with every day, it's being able to properly communicate with them and ensure that all of them are along for the ride as you make great decisions for your product. Now who are your stakeholders? A stakeholder is any person, internal or external that is impacted by your product. So they're going to have a variety of different investment areas based on how involved or uninvolved they might be. But essentially anyone that has some sort of involvement in your product is going to be one of your stakeholders. So they might be invested in your product success. They might be invested in the actual creation of your product, your engineers and your UX designers, or they might just be invested in the impact your product will make. Regardless of these things, your different stakeholders will be more or less involved at various stages of that product life cycle. So coming back to that and thinking about some of our different stakeholders. When you think about our business stakeholders or our project sponsors, they're going to want to be involved at every stage in the process, especially in that upfront where you're defining that business strategy, defining those business metrics that you're looking to impact. Your program managers are going to be those executionists that are helping you at every stage and pushing things along, and you're going to want to work closely and have a great relationship with them. Your engineers and your user research and design partners, they're going to be working most closely with you on what that MVP is, figuring out that exact UX, figuring out that exact experience in different education and testing. So they're going to be super involved in some of those middle phases of the product. And then your analytics partners, they're going to be helping to build your success metrics and your learning plan. They're going to be helping you set up your AB test. And they're going to be looking at the learnings from your product and providing analyses that help you make decisions about how to iterate further. So all of these stakeholders have different involvement, different interactions, but also vary based on the type of product that you own. The business stakeholders that I work with now, working in delivery experience, are different than the stakeholders I worked with when I worked on the marketplace product. I worked with more marketing and kind of small business associates versus now I work with a lot of supply chain and final mile. To get all these different types of stakeholders, all of them you're working with to influence and help to build the best product that you can. Now that we've defined our products, we're going to go into our three pillars of success. So these are three pillars that can be used in any type of product, any type of product lifecycle. Our first pillar, know your audience. This pillar is going to be focused around understanding who these stakeholders are and adjusting your communications based on of their differences. Our second pillar is about being clear, concise and organized. This is where we'll focus on really simplifying and catering your content to be as specific and simple as possible. And then in pillar three tell a story, we'll talk about how to put your content in a logical order so that it makes sense to your stakeholders. Now across the board, these pillars can continuously be applied against the two most common ways you work with stakeholders, and that communication so that can be emails, Slack messages, informal discussions, anytime that you're interacting with these stakeholders, and also comes into play when you're creating documents and creating presentations, you're creating that product brief, you're educating them on why you're building the product in a certain way. These tools come into play there the same way as they do with an ongoing conversation. So pillar number one know your audience. When I think about this pillar I'm reminded of my training when I was a consultant. Now my first month at Deloitte digital, we did a ton of different training exercises, several of which were some mock meetings with fake clients or managers and the company. And one of the first ones that I did it was about a 10 minute discussion and we spent nine of the 10 or so minutes just learning about the person they're talking about their kids, their, you know, likes and dislikes, they'll have to play tennis on the weekend. And we only got through like maybe a minute of the business related content whatever scope we were looking to push for it. So when it finished our mock client asked for some feedback and how we thought we did and it was pretty unanimous our group thought we did terrible, we thought, you know, we didn't get to the content we were supposed to get through. And he completely disagreed, he said, in this case, this client wanted to tell you about himself, he wanted to build that report before he could have any sort of trust with you. And so because that's what he needed that's exactly what you're supposed to do. So when you think about that as we talk through this thinking about the importance of that upfront getting to know the folks that you're working with. It's really going to be beneficial and building trust with the people that you work with. So what are some factors to consider when you think about knowing your audience, the communications that you put forward, not only can but should change based on who you're working with. And that can always be the case if you're sending out a mass email or if you're having a large group discussion, but smaller group discussions individual documents, all of that can be catered in an efficient way that will allow you to take some of these factors into account. So we've kind of funneled these into two areas the first being level of involvement. So each stakeholder that you work with is going to have a different interest and how involved or uninvolved they want to be. And that's how you communicate with them. So your leadership your executives they're going to be much more concerned with a high level. I really like to think about working with executives as like talking to one of your parents friends at a family party. You want to keep a kind of high level you don't want to go into much detail, you want to be pretty professional it's not like you're talking to your friends, but in general they're just people they're not people to be scared of. So for our interstakeholders their involvement level is going to vary drastically, both based on the stage of a product a project that you're in, as well as how invested they are in the product. So for myself working in delivery experience, I worked super closely with our supply chain final mile partners, they're involved in so many of the major product decisions that we create. So our user copy team our user UX copy team that we also work with closely. They work with 1015 projects at a time they don't just work with my team they work across e commerce and across Palatine as well. So the context that I give them and I ask a question, I need to provide screenshots I need to explain exactly what we're looking to ask, give them some background and why we're making this change. It needs to be structured in a completely different way than asking a question to one of my partners that I work with every day. Finally your direct team, these folks are going to be involved every single day you may have stand ups with them, you're frequently meeting with them, you've got one off one on ones with them. They're going to require appropriate background they're going to want to know the dirty details, you also can probably be a bit more informal with them. People that you talk to all the time there's no reason that everything about work needs to be so buttoned up are all sitting on zoom all day long there's no reason why you cannot just a little bit of fun into it. So we're others factors to consider on the background and awareness side of the house. First, we talked a little bit about this already but relevant subject matter expertise. I'm talking to that final mile person or I'm talking to that copy person I'm going to discuss it differently. Technical versus non technical, I think this is really a product managers bread and butter. It's being at the intersection of business and technology means that you can explain the same thing to your engineer as to your designer as one of your business partners, doing it each in a different way. Folks that are going to want to be in the weeds versus know the details versus those people like many of your executives, most likely, they're kind of like that too long didn't read just tell me what I need to know. You need to think about that when each of the, each of the communications that you do. The past involvement in this project or an adjacent project does the person that you're talking to know about that a B test you ran that failed and didn't go well. Or do they know in the last phase of the project you had X number of lessons learned. If they don't, it's your job to educate them. It's your job to give them that appropriate context based on how little or how much they already know about the project that you're working on. And finally, do they have an existing relationship with you as a someone that you send you know gifts to over slack all the time and you know them really well and can be pretty informal. Or is this someone you've never met before in which case an intro is going to be important, telling them who you are and what part of the business you sit within before asking a question or asking for something for them to help you with. It's going to go a long way and the likelihood that they answer your question. If you spent that extra 30 seconds just briefly introducing yourself and giving them appropriate context. So we have a couple of tips kind of trickling throughout the presentation for know your audience our tip is to ask about it. So if you know going back to those difficult stakeholders that you might work with, if you're having trouble getting to them if you're having trouble communicating with them. Ask about it, there may be some specific preference that they have, but there may be an existing meeting that they're already hearing a lot of this information so they're tuned out for that reason. You don't ask these questions, you're never going to know why an issue is happening. And just by asking and keeping it pretty simple and straightforward is probably going to improve your communication with that person. Pillar to be clear concise and organize. Now when I was a consultant I had a client who I swear would fall asleep in the back of my meetings. Now, initially it really aggravated me it frustrated me I didn't understand why she was just asleep in the back corner, but I thought about it I thought about how busy she was. I thought about how I was subjecting her to these sometimes our long meetings multiple times a week when she really only had to provide input for about five to 10 minutes of the discussion. So I thought about it I adjusted my communication style I was much more specific with her. I have one off private conversations. I would send her specific emails where they were super clear, really calling out those decisions, and it really improved our communication and improved the my ability to get decisions from her and just by changing my approach. So when it comes to being clear concise and organize just like that client, all of our coworkers are busy people just like we are. We've talked about the zoom fatigue, all of us are sitting at our laptops all day long. If there's any way that you can make things simpler make things easy for the people that you work with. It's so much more likely they're going to be not only willing but you know excited to help you. So going across the board being clear, I think context is everything. I talked about this a little bit when it comes to the different types of stakeholders, but I think even adding that single sentence at the start of the meeting, saying, hey, today's discussion is focused on this. We're going to sidebar any topics tied to this really frames the mindset of everyone in the discussion. It helps them understand hey this is what we're looking to accomplish today. I'd also encourage you to state the obvious call out things that people might not be saying if there's some launch date that's just not going to happen and everyone's kind of dancing around it, say it say that that's the problem and figure out how to solve it. One of your biggest jobs as a PM is to call things things out and make it clear to your stakeholders. The second area being concise really prioritizing that top information, you know using an executive summary at the top of an email or a presentation for those TLDR stakeholders that just want to leave with whatever information. They may not read a single sentence pass that cert first sentence. So really pay attention to the words that you're using, and really make sure that whatever you said in that first sentence is what you want them to take away. I know there's that age old expression keep it simple stupid and I do think that it applies whenever you can be as simple as possible about what you're trying to say, definitely do so. And finally be organized think about the content hierarchy you use to share your thought process, organize your thoughts in a logical way that's going to make sense we'll talk about that in our next pillar in a bit. Think about the presentation as well if you're presenting a big roadmap and making a huge change for the upcoming year spend time visualizing that experience explaining it just sharing a paragraph and why you made a change is probably not going to be as effective as some sort of visual when you're you know making a big change your roadmap and vision. Now our tip for being clear and concise and organized is you practice practice practice. This especially comes into play when you're creating presentations are material. Go through that experience practice it in advance, especially when you're meeting with some super senior leaders. It's going to let you iron out your storyline it's going to let you anticipate any questions that might be asked. I also can encourage you if you've never done so before to record yourself. I'll tell you right now it's super painful I've had to do it a few times, but it tells you a lot about how you present and how you speak to the people around you. You might notice filler words that you use you might notice that you talk more quickly than you expect. I know myself personally that's something that I continuously tried to improve upon. So it's really going to help not just for whatever presentation might be preparing, but in any communication that you have both in meetings and outside. The more that you practice for some of those big meetings, the easier it will be and smaller meetings smaller communication, just speak naturally and confidently about your area of expertise. So I kind of think product management when it comes to working with stakeholders is a little bit like telling a bedtime story, you've got to have a beginning and middle and you've got to explain it in a logical way, so that it's going to make sense. If you jump straight to your conclusions straight to your decision, they're not going to understand the why they're not going to necessarily be aligned, because you haven't explained to them why you made that decision. So starting with the beginning this is when you're setting the stage in a meeting defining an agenda. These are the goals we want to talk through today, giving context or background. Why is this an area of focus. Why is your product focused on building this new thing. Then when you get to the middle this is sort of the meat of your discussion. This is when you're going to provide as well as walk through material. I think one of the big mistakes people make when kind of providing information is they spend all this great time preparing some material, and then they never give folks time to go through it, they don't walk through it, they just jump into the very specific details at the bottom. If you're spending all this time building a document, make sure that it's being used, make sure that you've explained the thought process and gone through it, so that this information is clear to your stakeholders. It's also really important when you're doing that to provide a point of view. I think this is a common misconception with more junior product managers that you're just there to kind of show what the options are. No, that's not the case. One of the reasons why you're leading this discussion is because of all the stakeholders that you're working with their lens of the product is not holistic. Discussions is across all of them, those stakeholders and your job is to represent across all of them. So you should provide a point of view, you should provide a recommendation based on what you've heard from everyone that's a big part of your job in this process. And finally backer findings with and your POV with data. I think another common misconception that happens in product is having discussions tied to opinions. If you're making a decision and you've backed it with data, it's going to be so much easier to push it across and kind of get to that final decision. I think where this comes up most commonly is when working with business partners who don't necessarily work with product as frequently. Their goals and focus areas are a little bit less oriented towards data. And this is a really good way to objectively make a decision without taking too many different opinions into account. If you're making your discussion, your next steps, you should wrap up and summarize what you talked about. If it's a big decision, come back and remind everyone of what you've all decided. Give them an opportunity to collect any final feedback. You may have some super vocal stakeholders that are giving information all the way throughout your presentation or immediately will comment in your document. But you might have some stakeholders that are going to be quiet. You may have stakeholders who are at home. So they're multitasking your kid jumped in during a big piece. Make sure that you're pushing again to make sure that they provide feedback. There's a specific area that you're worried about for a specific stakeholder. Call that out. For example, myself working with those final mile folks, whenever we're making changes that are going to impact our delivery drivers, it's super important to me that they understand every detail of that process. And finally, your next steps, identify what's next, identify, you know, what they can expect from you, whether it be another discussion, whether it be. All right, we've closed this decision, we're going to start building the product in this way. Just make that clear so that they know what's happening next. Our tip for knowing your audience is to storyboard. Now I still do this today. I learned about it when I was a first year consultant. I will physically write on a piece of paper drawing out here's what I'm planning to do in my slides. It's such a helpful way to figure out your storyline, figure out the logic and make sure that it's in that logical order. You can cross things out, you can move things around. I really enjoyed crumpling it up if it's not working. But I highly recommend it, it's going to help you to figure out, you know, that storyline, alongside the practicing piece that we mentioned earlier where really allows you to kind of iron out and finalize that approach. So now applying the pillars, I'm sure you guys have felt like this meme where you've been in a meeting and you're like, this could have been an email, it could have been a quick one off discussion, I shouldn't need to sit here for 3045 minutes or an hour. The only way that you can avoid some of those meetings by ensuring that you're sending super successful emails. I do think that meetings have a time and place, but in certain cases, an email can cover it providing your providing like context. So in this section we're going to be focused on applying everything learned so far to a real life example. So stakeholder management in real life. So let's pretend for a moment that you are the product manager for Spotify wrapped. So if you don't know what Spotify wrapped is it's this awesome marketing campaign that Spotify runs every year around December or so. It consolidates information about the most popular songs the most popular podcasts, all this great data about how a user listened to Spotify over the course of that last year. And as you can see on the right, I'm a big country fan, I also am a big scrubs fan which is why fake doctors real friends was my favorite podcast of this year. So pretending again that you are the PM for this product. And you learn that the data use for the podcast portion of your 2021 experience will not be ready in time for a planned launch. So let's start with how not to handle this so I have on the screen a sample email that probably isn't the right way to approach it. So I'll give everyone a second to review and think about what's wrong with it and I'll read it aloud. Hi all, we discovered our podcast data won't be ready for an November 30 launch. So we've removed it from rocked wheel instead launch with music data only fast Lauren. So what's wrong with this. First off the title. So we've sent this to every stakeholder involved in this project. Some of those folks could only be working on wraps this may be the only product that they work on year round. Some folks in my example earlier our copy stakeholders, maybe working on 1015 projects at once they may have no idea from reading this title, but this is tied to podcast data for Spotify within the email itself we've given no background and why this is broken so we haven't told them what the actual problem is we've just said hey it's broken nothing we can do about it. We've given no context on why this decision was made, as well as other options available, even if this PM's intentions were good and they did evaluate other options. It hasn't been made clear here they haven't shown that thought process and identified here's why we're making this decision. They haven't added any collaboration or input collected from stakeholders, maybe it happened outside but let's let's assume that it didn't kind of seems like this PM just made a decision for their product blindly without telling anyone and just you know told them after the fact hey this is done. And finally, they've given limited clarity on the what the experience might look like you know what does this mean what features are now removed. So what might be a different approach, thinking again back to some of our pillars, what might be a different way to approach this. Number one, documenting an analysis, looking at the problem, identifying what the issue is identifying what the impact is and thinking through here are options and our ways to approach the problem. There's any options in there but like hey this is absolutely so stupid like let's say as an example we're just going to cancel Spotify wrapped. No one would do that you don't need to provide that example, but anything that someone in could in theory could want to do should be listed as your options that you compare. So going back to thinking if something should be a meeting or not. I think after that you could use some sort of collaboration session. I think in this case you would at least want to coordinate and work with some of those core stakeholders. So the engineering team that can speak to why this is an issue. Some of your kind of key podcast folks or folks in that data team that really can kind of provide their perspective on why this is an issue and what our real options are to move forward. So if your, you know, kind of core working group has come together you've all reviewed the options you agree on the pros and cons, and you've agreed on an approach, then you can get to that stage of communicating at your decision, whether it being an email or any other tool you might use, and make it clear exactly what the decision is. And finally, allow time to react and agree on approach. Now we talked about providing a point of view and I think it's important to be clear about the decision that you've made. You should still give your stakeholders time to react. Give them a couple days or in some cases and maybe a couple hours based on how urgent the decision is, but give them time to agree that they have a super big concern or they completely disagree about the approach. You should still give them the ability to do so. It's not saying that it needs to completely change your approach, but you should at least hear them out. They're providing a different perspective for a reason, there may be context that they have that you weren't aware of and making your decision. So what might a new email look like you know you see it here on the screen, starting with this top section, we've provided very clearly. Here's the decision that you made. We can see now that after reviewing our options, we haven't gone with removing it from launch we've just delayed our launch a little bit to get at least a couple of our features. We've identified what that issue is we've identified the impact and then we've gone through the options as well as a recommendation. At the bottom here, we've given them a couple days to provide any of that last feedback before we officially close our decision. So going through our pillars knowing our customer in this case we've you know because we're sending this to such a large audience, we have adjusted that content so you start with a summary and then go into the detail. We've also been very data oriented, assuming given the type of company that Spotify is everyone in their team is going to be super data oriented and going to want to know the data aspect of the options that were considered. In terms of being clear, concise and organized you'll see there's very few words on the screen, really only going into the detail or were necessary, and really focusing on the exact wording that was used. And finally tell a story you can see that it's in a logical order it starts with that summary has that beginning middle of the end and make sure that you wrap on the next steps of the end. So in summary and closing stakeholder management as we've talked about it's about people. It's about building relationships with the partners that you work with your stakeholders are anyone internal or external that is impacted by our product and you carefully want to consider how you work with them. We've talked about the pillars that are probably drilled into your head at this point but reminding you one more time, our three pillars are know your audience be clear, concise and organized and tell a story. A few final closing tips. Number one, avoid that should have been an email by adjusting your communication styles for activity. I think all of your different communication tools. So email, Slack formal informal meeting. I'll have a time in place, you should choose them wisely you should consider what you're trying to accomplish, and then decide hey is this something that I can just talk to them about casually, or do I need to really formalize this and walk them through it live. Once you find an approach or a way of doing something you have a great product brief and it was super effective and getting your team to agree. Share it reuse and share it with other folks in your team. Once you figured out a good way of working there's no reason why you want to change it. Definitely like there are third tip is to leverage executive summaries and double clicks. You kind of saw that in the email that we just reviewed, but providing that initial summary initial outline for those TLDR stakeholders. So trying to break down slides that go into the data, continue to improve forward is a really great way to provide different levels of detail based on your stakeholders, without having to create completely separate documents. And finally collaborate not just communicate. The biggest reason why your stakeholder is asking questions or providing feedback is because they provide a different perspective. Because the product manager is to hear them out understand them. Ultimately, you have the same goal, you're trying to make your product better. Listen to them work with them together, the more that you can collaborate with them, you're not just communicating out decisions, the better that your product will be and the better you'll serve your customers. Thank you so much for your time I hope you have a great rest of your day.