 Hi everyone. My name is Abhi Morris and I'm very excited to be here today. I am excited to talk to you about managing stakeholders as a product manager. I'm particularly excited about this topic because this is a topic that's not discussed enough in the product circles, but it is something that we use every day. And it is something that it's a very common aspect in our day-to-day lives as product managers, but we deal with different kinds of stakeholders both within the company, outside the company, within our team, across teams, cross-functionally. And it's something that's very, very important. And not enough light has been shed, so I'm very excited to talk about this. And hopefully you'll enjoy this session and learn something from it. I thoroughly enjoyed making this one. So I hope you enjoy it as well. So what should you listen to me? Well, I am a product manager by trade. I work currently at Amazon. More specifically, I'm a product manager at AWS. And prior to this, I've been at Facebook, more specifically Facebook connectivity, the goal for Facebook connectivity is to bring more people online to password internet. So I was at a very exciting few years that I was there in working on various different products that we were trying to improve internet speeds and trying to get more people connected to the internet. So it was fun doing that. Prior to that, I was running product for most of the security suite at Ruckus Wireless. Ruckus Wireless is an enterprise company basically making enterprise wireless care. And I was responsible for most of the security portfolio, including some of the federal certifications and such. And prior to that, I was working in a company called Aruba Networks, which is now part of HPE. And I had a pretty long time in Aruba where I joined in as an engineer. And I wore multiple hats and transitioned my way into product from there. So yeah, it's been a very interesting ride. And I believe the opportunity to wear multiple hats and different roles in different companies and experiencing different cultures, company cultures was very useful to me in dealing with different kinds of situations. And of course, along the way, I have made a lot of mistakes. And I have learned a lot from a lot of my mistakes and tried to culminate some of my learnings over the years into into this session so hopefully it'll be useful for you. So a little bit about me. I'm a huge Marvel and Star Wars fan. So if anyone wants to geek out a little bit on some of these, I'd be more than excited to do that. I'm also huge into electric mobility. I have multiple forms of modes of transportation that are that are electric. And I really enjoy and truly believe that's the future. So I'm very passionate about that. And I am a biker, I bike. What about I recently did a century ride was very exciting and interesting experience I learned a lot in training up to be able to do 100 miles in a single day. And even the whole journey of getting myself up to shape and actually the day of the event itself was very interesting and exciting a lot of learning moments within that as well. I'm also a huge coffee buff. More specifically, I'm a big fan of cortados. For those of you who are looking at the picture and saying that's just a cappuccino is not it's very different. It's it's definitely one of my favorite drinks, especially in the morning. So here's how we're going to give you up the session. So we're going to talk a little bit of basics first. Let's, let's talk about some of the basic items of who we're who we deal with and what are the typical passions we deal with. And then we're going to do we go get into more strategies which I think is a more meat of this presentation if you will. And then we're going to talk a little bit about some of the things that we need to be mindful of when we are when you're going to buy our day and dating with multiple situations and people so what are the pitfalls to one and such. And then we'll get into other topics. So, you know, one of the one of the interesting things is I wanted to find out what exactly is the official definition of a stakeholder. And this basically interestingly enough captures exactly what what I thought it was and also in our job what it is. It seems trivial and kind of silly but I think it's very important to know that when we talk about stakeholders oftentimes I've seen a lot of people approach it with caution or approach it with, you know, how do I get them to do what I want. Oftentimes people forget that stakeholders are essentially people with the same interest as as you have in the product and making the product successful. And, you know, they they share your concern and your goal of making something successful. So, it's very important to understand that we are all in it to win it. Oftentimes, that approach, at least to me has made a significant difference because a lot of times I approach stakeholders as like how do I get my idea across and convince them and not paying enough attention that that they have the same end goal as well. These conversations are actually something that's helping us both. And that is something very important to realize that we're one one big team and we have the same and go. Especially this is true in a project management or program management world where you know the colors came to not showing properly but you know the x axis is basically traditionally defined as power the stakeholders and the y axis is defined as level of interest that the stakeholder has in your program or project. I'm not a big fan of that definition of traditional thinking. I'm not saying that it's not valid. I'm just saying as a product manager. Everybody's your stakeholder. The only difference is basically your stakeholders or the attention you need to pay to the stakeholder changes as you go along the project timeline. When you're in an ideation phase, you're probably spending more time with engineering. You're probably spending more time with customers trying to understand their pain points. They're probably trying to talk to sales to understand how would you go to market you're basically forming a map within your head. And that ideation phase the kind of stakeholders you spend more time with is very different than the than the kind of people that you would spend time doing an execution phase that an execution phase you want to manage closely. The process of producing the product which is mostly engineering and other functions associated around it. And obviously as you go to launch, you want to change your behavior you want to spend more time with marketing you want to spend more time with go to market teams. So, I personally believe that looking at it as a time horizon of a program or project or product and changing your gears depending on what phase you are in is a lot more easier and effective method to look at your stakeholders, as opposed to looking at it from a traditional project management discipline where you're just looking at giving up people based on based on their power or based on a level of interest so this has been very useful to me. And I'm hoping this could be useful to you as well and let me know as well if this is something that you share. You know, one of the things that I feel is basic to a product management individual is KYS and if you're wondering what KYS is just know your stuff. There is no excuse to this and there's no substitute for it as well. If you want to run an effective program or product, I think it's very important to know your product very very well. And it's not just a product you need to know your customer as well. And that will take a long way because as a stakeholder you need to talk to multiple people. And those multiple people have different levels of understanding of the product, the program and the overall function. They all have their specialties, but you as a general manager for your function or your product. You got to have your pulse on the whole organization and that is helping you make this product. So it's very important to know your stuff and to have very meaningful conversations with your team. Unfortunately, no substitute to it. And we got to put in the work to understand our product very very well. And something that I would say is is the first thing you should start with is to understand the product. Talking about strategies, one of the strategies that has helped me a lot is this concept called Concentric Circle of Influence. As a product manager, you have a lot of people that you need to influence and convince whether it's a brand new idea or if it's a feature that we need to build within a product. Or even changing up how we are positioning a product or whatever you're trying to achieve, there are obviously a lot of stakeholders. And one of the effective ways that I have found, especially when you're dealing with a mountainous activity of convincing a lot of people is start small. Like identify a closed set of individuals around you that are very important and effective for the program and get them on board and then slowly move out. So expand slowly and expanding stages. So first get the feedback in a circle first, get them on board, learn from them, discuss with them, and then do the necessary adjustments and then move to the next stage. And rinse and repeat. So every time you expand your circle, gather feedback, iterate and then expand again. That way a couple of things. And this one sounds a bit trivial and something that what everybody will do, but I've been in a lot of situations where somebody took an idea to a very large forum and automatically it went in all different directions and it was not very effective. I think approaching this in a more strategic way of concentric circles of people. I think it's very effective strategy because it helps you to contain your blast radius. And also have more meaningful discussions on what would be the right thing to build and who did for and such so I find having this concentric circle approach is very, very effective. Something that we highly recommend as well because it's also an iterative process. And as you go to the next circle, the circles before that are completely aligned with you. So it's no longer only your objective of convincing the next circle but all of the circles before that circle is now working for you to expand to the next circle. So I think that's a very effective strategy. Think about this as in some loose term or compound interest, right? So every time you go to the next circle, your idea has compounded to all the circles before it. So that actually is helping you to convince the next circle. I think that's worked out very well for me and I would highly recommend to think about this as a strategy when you're looking at launching something or trying to take it to a larger audience. The other aspect or strategy is also building a lot of social capital. So if a little bit of social currency goes a long way, oftentimes we're so hung up on a particular objective or a particular getting something done that we don't build or spend time building that social capital and I feel that that social capital is very, very important. It's often ignored and it's very easy to push it away, but I think it's very helpful, especially when you are in tricky situations when you have disagreements with the team that trust that you build with the team comes a lot of times from the social capital that you build over a period. It's not something that can happen overnight. It's something that you need to put in the work unconditionally and, you know, having that really that trust in the team and putting that social capital or currency goes a long way in actually getting the work done. So there's a lot more trust, there's a lot more belief that that gets built in and that makes life very easy, especially when I'm trying to launch something new or when we're trying to make decisions along the way. Another interesting concept that I've found very effective personally for me and I've learned this the hard way is what I call the 50% rule. You know, if you're walking into a meeting where some decision needs to be made. And if more than 50% of the people are not already aligned with you. There's a very, very high chance that that decision meeting will take weird turns and it can get into a lot of rat holes. And oftentimes we walk out of these kind of decision meetings very unsatisfied because the objective was different and the outcome was totally different. I do say that those conversations and radicals are not important, I think they are important, but keep in mind as a product manager, you're responsible to guide the whole team in that room to make the right decision. What I always do is I make sure at least half of the people in that particular room, of course now it's all virtual but in that metaphysical room are convinced and already know about the problem statement already know about the thought process already know about decision we didn't find them. That actually helps to keep the meeting more focused. And for those of you or those of them who are new in the room or to this idea or concept that you're trying to pitch a position. I think we'll get a lot of guidance and help from the rest of the other half of the room which already know about this. So definitely something that I would recommend you to experiment and play with as well. There's of course adds a lot of work because you know if you have 10 people in the room you need to make sure five more than five of them are already convinced or know about it and you know they have some sort of awareness and in the directional direction you have what you're thinking. It takes a bit of work but it actually avoids a lot of work later on. I mean imagine if the meeting could easily rat one into something else, and now you come up with more action items, more data to crunch. And if you don't even believe that additional data crunching is useful, you're just putting more work that's not that could have been easily avoided. So doing some work upfront in prepping people getting into that meeting is very helpful. And it doesn't always have to be within your immediate team. This could be from outside the team. This could be XFNs like make sure you're picking people that can help you, especially in that room. The other strategy that that's of course has been evergreen is data. And I'm putting this, even though we know a lot about this, I'm still putting it because it's important. And this become more and more important over the course of time. Always use data to help drive stakeholder behavior. Oftentimes it's very easy to, you know, people to think about opinions, but a lot of times having data even remotely related is better than having no data. And this is especially true in some of the non analytical aspects of product building. Think about naming exercises as one where a lot of people have opinions, but having some sort of data behind it. And then naming is an interesting one because you don't have much data behind it. But you can always gather data from feedback, like it could be customer feedback at the opinion polls, it could be any sort of feedback that you collect. If you're an enterprise business, it could be from your sales from your sales engineers, it could be from your existing customers as well. Having some sort of data, whether it's feedback, opinions, etc. gathered that could help make the decision is very effective strategy. And of course, if you're building, you know, if you're building any sort of product which already has some of the data that you can already leverage, that is very, very useful. Pricing is another classic example where you've got to go with a lot of data. You've got to know your computer's price, you're going to know what people are really paid. You're going to know how much this will impact, whether it's TCO, whether it's a subscription, how much it will impact your customers. I think having that data and guiding the room to make the right decision is extremely important. And every time I have gone with data and I've used data to form both my opinions and also guiding the room to make opinions. I think the outcome has been very different and positive as opposed to when I have gone into the room with just an opinion. So something that I would highly recommend. Most of you do to use as well. The other strategy and this might seem obvious, but I think a lot of times we fail to do this is, is oftentimes you don't sell the vision where we were always trying to sell an idea or we're always trying to focus on the very specific thing that we're trying to do, whether it's a feature, whether it's, whether it's even if it's a product. We're trying to approach it in a very use case-centric way, but a lot of times we don't sell the broader vision. Selling the broader vision actually helps people, especially the stakeholders, as you would know, to think broadly, to expand the horizon a little bit more and think about what the end state looks like. And oftentimes it's always easier to know the end vision and work backwards from it as opposed to trying to form ideas as we go. So it always helps especially in tricky situations that when you're breaking a new concept or an idea always sell the vision first. If we want data science to do something or we want a specific team, cross-functional team to do something, it always helps to first sell them the vision, you know, give them an idea of what you're trying to do, and then work backwards from it and as to how that particular activity or that particular function fits into the broader vision. The person or the team also feels part of this grand vision and it seems that there's more to it than just that. It also brings in more perspective and I think that's where people do give more respect because of, you know, you've considered broader vision and then you're seeing how this particular function or team or individual fits into that broader vision. So something that we typically don't tend to do and then, you know, life gets on and we are so laser focused on getting something done. We oftentimes forget that we need to sell our vision more often than we do and sometimes it's very helpful in getting cross-functional alignment and also contribution to the project. Because everybody wants to be part of something large and this kind of helps them to understand what's beyond the small effort or work that they're putting in. So there's a few other things that I have experienced as well and trying to kind of run through some of those here. You know, escalations, I'm not a big fan of escalations. I always read escalation as a lifeline. I rarely use it and I don't know the last time I've escalated something. It's often a bad idea if a recipe for disaster. Of course, I totally understand that it needs to be used in certain situations when you're not getting the help that you need and when you've tried different strategies. But I think if you've tried any of these strategies that we talked about till now, escalation is very, very rarely needed. But you use it extremely, extremely cautiously because you don't want to keep in mind this is your, you have other programs and products that you'll run. So you want to make sure that you have the trust and support of the whole team with you. So try to avoid that. Also try to understand what your stakeholders want. It often helps to do your homework before walking into a meeting, especially trying to understand what are their concerns, what would they object to. Oftentimes I find that we are so busy convincing our ideas and our concepts that we fail to look at the problem from their side. And oftentimes taking a step back doing our homework anticipating what their concerns are and addressing that head on gives them a lot of comfort and then it gives them that comfort that they've thought about it. Like this other person has thought about this idea, this product manager knows my problems and he's proposing a solution to address my problems. And a lot of times you may not have answers to the problems that they may have to the objections that they may have, but even acknowledging it without a solution and then bringing it up front sometimes helps and comforts other people to know that you're thinking about it and it's not that you don't recognize that. So always understand what your stakeholders want, what their priorities are to do some homework before you can do these situations. And I've also seen in many of these review style meetings where people get a lot of feedback. And a lot of times people tend to be very limited about some of these feedbacks because they are like why would the person think about it in this way and try to find the intent behind the feedback. There's always different perspectives there's always different diverse opinions of things so always try to find the intent behind the feedback and especially help the next iteration of the next time you go in front of the same audience, where understanding the intent and taking that head on actually is quite helpful. The other aspect also is up leveling and down leveling messaging for your audience and oftentimes I've seen this especially happens as product managers and traditional companies where you want to use certain slide decks or messaging and you just want to rinse and repeat. So for terms of the recipe for disaster. Now would say always try to up level and download the messaging, whether it's an idea concept product, an objective, or some numbers that you want to finance ideas or anybody to run, always up level and messaging for your audience. That helps a lot, because if they don't, they don't, if they're not able to absorb everything you're trying to say and understand the border picture. It's the outcomes not going to be how you would want it to be. And there are always times when things will go sideways, no matter how much you strategize no matter how much you anticipate failure there will be situations where things will go sideways. And it does. It's okay. Find common ground, find out where can you get back with this other person or team or member where we can find common ground again and then start building from from there on. And that common ground could also be going back to our strategy setting the vision make sure that you know when things go sideways, go back and realign on the ambition like let's start from this is what we eventually want to be this is how they should look like and then work backwards from there and see where where you're branching and try to address that branch. So that's sometimes a lot of times just help me in the past. Next, I also want to talk about company culture. This is something that I believe it's been important to me working in different kinds of companies and different styles of operation looking at different sorts of company cultures. I've seen that every company is different. They operate differently and embracing that company culture is very important if you're if you take up a new job. It's important to know how that company works. Then trying to bring in something. So, bottom line is don't don't fit a ground hole in a square peg so it's trying to make sure that that you're flowing with the company culture. Not to say that that it's bad to bring in great ideas always great to bring in great ideas. But if you're finding a lot of friction. You can consider that like reconsider going back to how this company works and see how we can optimize that if there is a lot of resistance for fresh ideas. So it doesn't mean you should stop but it just means that you need to change the change the approach. Another thing I always see is like even the title of this session, as we originally call it was managing stakeholders it's well yes it is but it's, you know, it's not really managing the stakeholders. To me managing means collaborating with your stakeholders learning with your stakeholders and building with them. I think that approach also changes quite a bit in me like how do you work with your stakeholders. So, and I don't think you're trying to force them into doing something. You're not trying to convince them to do what you want, but all together trying to build something that works for our customers for our users for our partners. And in the process doing something great for the company and poofing your own career objectives as well. So, so always look at this as a collaborating learning exercise. There are some role specific items that I've learned as well as I've gone along. I tried to make it very long but just to summarize some of the top four roles that product managers typically interact with and what the common pitfalls that we do and I have done almost all of it. You see on the slide which is why I made it a point to call it out, especially with engineering, you know, don't tell them how to build me especially transitioning from engineering into product I've done this mistake. Especially initially, in my original days of product management where I used to tell engineering how to build it. Like it was very, very hard for me to remove my engineering head and put on the product head. So always try to stick to the why, like why you want to build it. And then let them figure out how to build it. If there are feedback, always provide feedback on some of the things. But, but don't, don't, don't tell them how to do it. That's what recipe for disaster. Especially with executives keep it very high level. A lot of times we tend to delve in details because we want to show that we have thought this through and we have all the data we need and like we've done our due diligence and I think that's great. But unless you're asked for, I would keep the details very, very high level when we're talking to executives. And if there are questions of course dive deep, but don't dive deep without being prompted to and keep the focus on the company level and especially the executives you want to paint a picture and a vision of how this thing is going to help the larger company. So stick to broader outcomes for the company with this, as opposed to outcome of the product itself so oftentimes for an executive outcome for the product company is far more important than the outcome of a specific product. So something to keep in mind and again up level and down level messaging based on who the audience is. And then we deal with sales show sales how, how this works how to sell like and give them broad guidance and also don't ignore some of the suggestions and feedback again from sales especially in an enterprise company. It's very different if you're in a consumer world. But in an enterprise company, you got to listen more to sales because there are obviously boots on the ground and you get to know exactly what's happening out there in the field. Oftentimes I've gotten rumblings and feelings way before things blew up and pay attention to what they're saying. So everything that they say is is useful but but I would definitely recommend it to the due diligence on some of the things that they're suggesting. Also with marketing, I would recommend collaborating early. A lot of time for managers make this mistake of collaborating with marketing only at launch. I feel that it's a little too late. I think I would recommend collaborating with marketing a bit early. Basically as we're getting into ideation or execution mode. It's probably a good idea to collaborate marketing just because it helps in getting a better understanding of what this is going to do for a customer and kind of painting that story a little bit more clearly. And it also helps in building more cohesive launch plan so definitely recommend doing that a little bit earlier. And you know, hey, you've done this all you've tried everything. And there are times when things don't go as planned and things will fail like you won't be able to convince stakeholders or or they fail to see your vision like it always happens. And think about it as first attempt and learning like if there's always situations when the outcomes are not as desired. But they're always always a good learning exercise so keep that in mind and don't lose heart because guess what there will be around to. It's the same product not the product same feature different feature but there's always going to be another situation that will manifest soon as well and the learnings here would really help that. And with that, happy building. I hope I hope you've had fun on the session as much as I had making it. And, you know, I'm a true Steve Jobs fan and the true Steve Jobs style have one more thing before before we close for today and then that's, you know, remember that this is this is a marathon or sprint. Oftentimes when we are in situations of a particular release or a particular feature or a particular cycle. We often forget that this is a marathon, it's not a sprint so to keep that in mind. It's it's a long journey so bigger relationships along the way and these relationships will help you and things will spoon out and it'll get much easier. As we adopt some of these strategies and also practice because a lot of these strategies are not like on off switch. It's it takes practice in implementing some of these strategies and and you know it says sometimes it's also the way we think. So keep that in mind and and good luck with with with everything and happy building.