The Art of Stakeholder Management

Parul Goel, Adam Copeland, Lauren Chan Lee, Reed Jones at UXDX USA. Video: https://www.youtube.com/watch?v=873xSbPafs8

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Who counts as a stakeholder

[00:00:00] Lauren: What do you do when you have a stakeholder that's important but just doesn't respond to any of your emails? Welcome to the Art of Stakeholder Management. Today our panel has faced this exact challenge and many more, and they're here to share with you their success stories and their battle scars. I'm Lauren and I'll be your moderator today. I'm joined by Parul, Adam and Reed. We're a mix of new friends and old friends, and we're going to have some fun and keep it real together for the next half hour. Let's go ahead and jump right in. As Katherine mentioned, Parul is a director of product management at Indeed, and I want to start by asking her: who are some of the most important stakeholders that you have to manage?

[00:00:48] Parul: Lauren, when I think about my stakeholders, I ask myself: are they someone who can derail my plans, who can impact my plans? Can they impact my roadmap? Can they change what I am building, how I am building it, when I am building it? If the answer is yes, they are my stakeholder. Depending on the context I'm operating in, it could be a small group; usually it ends up being a large group. For example, at PayPal it was usually a pretty large group. It would include my leadership. It would include the sales team, who would have put things in my roadmap. It would include the ops team, who were usually advocating for automation, which was something my team had to build. It would include product and engineering teams across the organization whose help I would need to build the product. So really the core is: whose help do I need, and can they have a material impact on what I'm trying to do? That's how I try to define my stakeholders, try to figure out who they are, and build these relationships with them early on, so that it's easy for me, when the time comes and I need something from them, to approach them.

[00:01:59] Lauren: Great, that's a really helpful way to think about defining who your stakeholders are. I'm curious, Reed, as a user researcher at Zoox, whether your set of stakeholders is similar or different from the ones that Parul just talked about.

[00:02:19] Reed: I definitely think that there are things in common. One thing that I think can be interesting to add, because I think it really hit the nose, "who can derail," I think that's such a good perspective on who is a stakeholder. Sometimes, previously, I have thought about it as the degree that they can do that. Is this a problem that they're also likely to derail? The example I was once given is the plant next to the desk. The CEO probably doesn't have a strong opinion on it, but might come in, and when a CEO says something, it's a fire for everyone. But often it may not be something that they're too strong on.

[00:03:02] The other thing I think about is that sometimes my biggest stakeholders are also my partners' biggest stakeholders. For me, my operations team is one of my largest stakeholders and primary clients that I think of, so sometimes that is a common point that we have to gather around. But there are going to be people all over. There's going to be the engineer I'm immediately working with, and in some ways the way they can derail it is to either build or not build what I want, as well as, at the end of the day, the highest paid person in the room that was being talked about. Sometimes that's the one we all think about. So I think it was spot on, and I just think, to some degree, what's the relationship of that person to the problem? Because that's probably going to influence the likelihood that they're going to impact it, and how close they need to be to the problem.

[00:04:01] Lauren: I love how you referenced the HiPPO problem that was in the last panel. I think we've probably all faced it before, and that's a fun one. Adam is in the healthcare space. I'm curious how your set of stakeholders might be a little bit different, given you have a healthcare dimension as well as a B2B side.

[00:04:25] Adam: Thanks, Lauren. I think there are a lot of resonances with the other panelists, but in the healthcare space particularly: I work at Mayo Clinic Laboratories, which is a large reference laboratory, so our clients are other hospital systems. We think a lot about the internal stakeholders, where I have completely the same experiences as Reed and Parul, but then the external stakeholders are pretty diverse for us, and in the B2B space that can make life challenging and exciting for research. There are certainly physicians ordering lab tests, there are managers of labs, specimen operators. Every lab test will touch 15 or 20 people before it gets to us, and then we do the work ourselves and it moves over to our internal stakeholders. So having an appreciation for those external touch points is really key to our work. And I would be remiss if we didn't point out that the patient is always the primary stakeholder in healthcare. Even when you're running highly complex processes, we do a lot at Mayo Clinic to always center the patient, from a lab test to every single interaction we have.

Prioritizing stakeholders as the product changes

[00:05:56] Lauren: I love that you mentioned how the patient is really the most important user, the most important stakeholder that you deal with. I think in consumer tech a lot of times that's the end user. We all share a similar prioritization, if you will, of our stakeholders. Does anybody have any different ways that they think about how to prioritize their stakeholders?

[00:06:27] Parul: I can jump in. I think it changes depending on what's going on with my product. If I am trying to build something significant, in the beginning I focus on my leadership to get their buy-in, and I focus on other groups who will be instrumental in me building this. But over time, for example, if there are teams that I know will be against this idea, they might become my focal point. So at any given time I try to assess where I can expect pushback from, where I can see an opposing opinion which might take time, which might take bandwidth, and I make that my focus. For me it usually changes over time as I work on my product.

[00:07:15] Lauren: You have to be very agile with your stakeholder management as you go through your agile product development process. I think that makes a lot of sense. As you are juggling that and preparing for maybe some difficult conversations, when you have stakeholders that you know don't agree with your perspective, how do you prepare for those kinds of discussions? Anyone can take it. I think, Reed, in our prep session you had an example.

Preparing for difficult conversations

[00:07:58] Reed: I definitely don't do this every time that I go into a meeting, but maybe it's because I understand what's at stake, or maybe it's just the diverse point of view that I might be beginning to work with. I do think it's valuable to think through the different ramifications of different options that you might have. If you think of negotiation, and I'm sure many people at the conference have taken negotiation courses, one of the big things about modern negotiation, at least, is it's not about a competitive head-to-head battle. It's a lot more about thinking in two ways: both thinking about what's at stake, what does everybody want and need out of the situation, and at the same time balancing that with, if you can't get something to work, or if there is something that won't budge, what are the next options?

[00:09:00] I think when you're really working in a collaborative space, we have the benefit of being able to work through the thing that won't budge. Maybe we have a partner that has a lot at stake, and you can't necessarily ask them if they're scared or they're fearful, but you can begin to talk to them about their concerns, about how it might reflect on the team or on them as an individual, and say, "Okay, let's play this out. If we go with that option, what happens? If we go with these other options?" And just work with them to play out the options. I think that can be a good way to persuade people: let them see all the information on the table.

[00:09:39] Lauren: Negotiation as a preparation technique, I love that. And I love that you think about win-win, and if not, because it's not always possible, then what is the next best option. I think that's a really key takeaway there. Adam, since you have internal and external stakeholders, does what Reed outlined work with the type of stakeholders that you deal with? Are you able to use that negotiation-type framework as well, or what kind of preparation goes into your discussions?

[00:10:18] Adam: One of the things that's probably distinctive for our group's work, as opposed to some folks at the conference, is how much of a challenge it is for us to get to an external stakeholder. I loved one of the previous presentations that emphasized connecting with the user at least once a week, and I think we probably get that on average, but the amount of prior authorizations and relationships and pre-meetings it takes to get there is pretty significant for us. For us, our field staff, our sales team, is always the primary holder of the relationship with our clients, and we work with our communications team to help support any time we reach out to clients, and also have follow-up meetings with our field staff as well.

[00:11:13] We do that because we so value our clients' time, and they really respect how we interact with them. But it does mean that each one of those interactions with those external stakeholders takes on an additional level of import, and you want to use that time as well as you absolutely can. I'll stop there, just in terms of some of the things we think through. At the end of the day, I think for all of us it's about relationships. The reason we have all those steps is because we value the relationship with that client or that external stakeholder, so much so that we want to be careful and orchestrate that experience. You want every interaction with that user, that stakeholder, to be positive and add to the relationship.

Advocating for the user when you don't own the decision

[00:12:20] Lauren: Adam, thanks for that. I think our timing was great, because we got a question from we [?], which asked about how you manage communication when you're disconnected from stakeholders who are part of your company, so I think we've addressed that one. We also got a question from Sydney, who asks about when you're not actually making the decision. I think that would be a great question for Reed, who I know, as a user researcher, is frequently in the position of advocating for the user but not owning the decision. What have you found is the best way to advocate for the user?

[00:13:00] Reed: I think it is about starting with relationships. Sometimes you're just not in a position where you're able to, but if you're able to build a lot of relationships in advance, it's super helpful, because then you have a common ground that you can meet on. Other times I think it is trying to understand what's important to the person that you're trying to influence, or trying to manage the relationship with, and then also think about different times that things have been effective. Maybe there are things that they've shared during an all-hands, or maybe in different meetings you've been in, something has affected them, or you've seen that kind of response. You can look at those ways of approaching the problem. Maybe it is the storytelling, painting the picture, trying to show them audio and video, and really trying to make it come alive for them. And then if they're a quantitative person, trying to bring that live experience and then maybe connect it to some data as well, and try to find that balance.

[00:14:13] I think also, when you can, bring them into the experience. Make them do it. If it's something that is unpleasant, set up your meeting where you have someone go through the workflow at the beginning of the meeting to introduce it, and anticipate the problems that they're going to have, or maybe set it up so that they're going to run into some problems that can naturally occur. Just bringing it to them in a way that is real, that they can connect with, that is palpable to them, I think is an approach that I like to take when possible.

[00:14:46] Parul: Lauren, sorry, I want to just add to what Reed was saying. In times when I am not the decision maker but I have a stake in what the decision is, there are two things that I've done, and they align with what Reed was saying. Number one is just making sure that I align on the goal, explicitly mentioning, "This is what we are trying to do." The second thing is, if I am able to demonstrate that I understand their concerns, that I have explored the other options, that I know their world well, I think that also goes a long way in building my credibility and in my recommendation being taken seriously. Then they are more comfortable relying on what I am saying, if I'm able to demonstrate that.

[00:15:33] Lauren: I think a lot of good stuff was mentioned there: putting yourself into your stakeholder's shoes, using a mix of storytelling and data, whichever way speaks to the stakeholder, and more. And I would add one more approach: check out Reed's on-demand talk on using frameworks and user research to bring people in along the way in the process.

The stakeholder who never responds

[00:16:00] I want to switch gears a little bit. I opened up the panel with the question of what you do when you have an important stakeholder who just does not respond to any of your emails. It was a little bit of a selfish question, because this is a problem that I've dealt with before as well. I had an important stakeholder on the legal team when I needed to review a contract, and every single time we had a meeting set up, she would cancel or not show up at the last minute, or blow past deadlines. And I know, Parul, you had a really great story along those lines as well, so I'd love for you to share it with this group.

[00:16:43] Parul: I have been in this situation multiple times. When I'm working with somebody, I need them to weigh in, and for some reason they're not engaged. I have sent them emails and meetings and I haven't gotten a response. And I have made the same mistake more than once, which is: "Okay, they don't have the time, this is not a priority for them, so let me just move forward without their blessing." Usually I do this when I know what they have to say is going to make my life more difficult. It will just create more work for the team. The last time I did that, there was a challenging stakeholder that I had had a history with, and I knew that she wasn't aligned, but she wasn't engaged, and I said, "Okay, let's just move ahead."

[00:17:36] Obviously, before we had to launch, we still had to get her approval, and at that point she brought up all of the concerns that I was worried about. Just because she hadn't attended the meeting, and so she hadn't given this feedback earlier, in her mind didn't really make her feedback any less important. Which is fair: your concern is still your concern. And at that point the stakes were much higher. We had promised our customers that we'd be delivering this product by this timeline, and to adjust would have been a much bigger deal than had I chosen to address her concerns earlier on. So at that point it became an escalation, and then we had to address it.

[00:18:20] But the big lesson that I learned was that if there is conflict, go through it rather than around it. As painful as it is, there's this saying, "a stitch in time saves nine," and that's exactly the case. If you go through the conflict, if you deal with it now, you will make your future a lot more peaceful and the journey a lot smoother. I have made that mistake a few times, and now I finally get it: choose the harder path.

[00:18:53] Lauren: I think you've given some talks on managing conflict as well, so I think you have taken that learning.

Getting buy-in before the meeting, in a remote world

[00:19:02] Adam, I want to ask you, since you have internal and external stakeholders: how do you get ahead of this buy-in problem when it's hard to have some of those direct conversations, especially with customers, where it's highly orchestrated? How do you do your best to ensure that there's alignment before you walk into a big meeting and get blindsided by critical feedback?

[00:19:30] Adam: Before COVID, when we were all in the office, one of the best ways that we found was just those informal contact points you could have in the office: stopping by somebody's office and framing it up. "Hey, there's a meeting coming up on Friday, this is what we're expecting. I really would love your feedback on this area particularly," or, "I know this is of value to you," and highlighting it that way. I have found, now we're in a work-from-anywhere environment, that those opportunities have evaporated. It's just more difficult to have those serendipitous moments of connection that do drive progress forward for projects.

[00:20:14] One of the things that I've found is my schedule is much busier, because I'm having those 10 or 15-minute check-ins with folks, and I'm finding I need to schedule them. It's basically taking the place of what would have happened prior. Part of that is because a lot of our organizational culture thrives on relationships, but also on giving everybody a voice and coming to consensus. So sometimes it's the meeting before the meeting that helps that consensus come about. Unfortunately it takes time, and it's not always the straightest line towards a solution, but given where we are and given the work circumstances, it's the appropriate act in a lot of cases, at this moment at least.

[00:21:11] Reed: To add to it, I think we've all probably had the experience where people come to us for advice because they want to move into the field. One of the things that I often do is talk to people about, quote, networking, going to events and stuff like that. I encourage them to go, but I encourage them to go and not try to network, but try to make genuine friendships. If you can make genuine friendships, the other stuff will come. So, just to add to what Adam was saying, I do think that there's huge value in trying, in our working environments, to establish those really genuine connections and friendships with people. Because, one, generally you want to solve the problems with people that you're friends with and that you enjoy working with. Even if you have different points of view, even if you're very firm in your ground that you don't think something is the right way to go, you'll feel so much more willing to work through it with someone that you feel that connection with. I'll leave it there, but I just think: genuinely try to build the friendships, and the other things will come as you do that.

[00:22:23] Lauren: Case in point, Reed and I actually worked together. We were stakeholders of each other in product and user research, and it's true, we didn't always agree on everything, on all the findings from the studies that we did, but we worked through it, and we still talk to each other. We're friends.

Communicating research that says don't build it

[00:22:43] We have another question from the audience. This is from Gary, and it seems to be directed to Reed: how do you communicate new-scope, blue-sky user research that is damning to project stakeholders who seemingly only care about budget and timelines?

[00:23:03] Reed: I think that's great. I have a significant stakeholder story that goes with that. I was previously somewhere where I was asked to take on a nebulous space. They wanted to increase efficiencies, but they had a lot of ambiguous tools that they were using, and people above a certain level stopped understanding how to do the work to get it done. So I had a very clear ask. There were aspects of it, like looking into some tooling, that I didn't even know about until executives asked me to take a look at it and understand what we could do. And I did, and I went through it, and what came out of it was not only some very practical, immediate findings that we could put into play; there was also a blueprint for a new tool set that we could argue for, or start working towards.

[00:24:00] I collaborated with the team and said, "Okay, here's the blueprint," and our conclusion at the time was that we shouldn't move forward with this yet. For the time that it will take to engineer and build this, there's not enough gain at this time; we're not scaling at a rate where it's going to be as relevant. The comment I got back from the exec, the person that told me to go look at this stuff, was, "Then why did you even do the research?" At first it was really a stab in the heart. I was like, "Because you told me to. This was your ask." But instead of saying that, because that would not have been a useful comment at all, I think what I had to do was help them understand the mitigation, how it's helping us.

[00:24:47] I think one of the hardest things for a researcher to accept sometimes is that if you're doing good research, it shouldn't always come out with a product. Sometimes you might recommend that this is not a productive direction to go, and maybe you put a project to sleep, especially when it's blue-sky or foundational. Sometimes you put stuff to sleep and say, "It's not the time. We can archive it, we can save it, we can reference it. There are tons of learnings, but this is not the way we should go forward." So if you can understand what the benefits are when you're doing research, there's no loss, there's no lack of value being generated. But you may have to take a different tack and say, "Yep, we didn't get to do that. We were asked to do it, and I'm recommending that we not do it," or, "It looks really bad, and that's the problem." And then look at the value that you do have. Do you have a new direction that you can go in? Do you have engineering time that you're going to save because you're not going to invest in this? I think that's how you need to put it forward, because I'm sure there's value you've derived if you look close enough.

[00:25:51] Lauren: I think it's super important to clarify the things that should be de-prioritized. A lot of times, when you think about even managing your own to-do list, it's important to drop things that are not important from your to-do list; otherwise you won't get to the things that are really important.

How their stakeholder management style has changed

[00:26:10] We have time for about one more question, and I'd like just a quick answer from each of you about how your stakeholder management style has changed over your career, or over the course of the pandemic. How have you adapted your style over time? Adam, you're the first box to my right, so maybe you can start with this one.

[00:26:38] Adam: Sure. I think two years ago I would have said, and I don't want to put it this way exactly, but empire building: "We're the voice of the clients. Always come to us whenever you're asking any sort of question that has some client feedback mechanism." I've really switched over the years, and really appreciated how the whole organization has an incredibly client-centered culture, and that's how we've been successful. And then really acknowledging and appreciating and lifting up when other teams are showing that client-centered mindset. So really trying to affirm: "Hey, my team's the client experience team, but you are doing this work already. Fantastic, let's tell that story." Because it's not about me or my team, it's about centering the client as we work towards business value.

[00:27:36] Lauren: Thanks, Adam. How about Parul next?

[00:27:40] Parul: What I have learned over time is that building relationships and influencing somebody takes time, and that's not something I knew going into these kinds of conversations. Early on I used to over-index: "Oh, I am meeting with them, I need them to say yes to this." I used to go in with a lot of pressure on myself, and I think that came through, almost like I'm pushing them to say yes to something. And I realized it's not one conversation. It's a series of conversations over time, how you influence people, how you really get to know them and they get to know you. I think that has really helped. I have taken that pressure off myself. Even if it's not a yes in the first meeting, I'm like, "Okay, for now it's not a yes, but I can try to change it over the next few meetings." So just know that no meeting is as important as you might think it is. There are always other chances.

[00:28:36] Lauren: Very wise, Parul. And let's wrap it with Reed and any final thoughts that you have on how your style has changed over time.

[00:28:48] Reed: I would say I really echo what has already been stated; it's been said best. What I would add is that what's probably happening for me is that, in parallel, there is the development of my discipline. Early on I might argue with a stakeholder about how many people we should have in a research project. They want ten, I don't think we need that many, and it's a back and forth. Then I evolved to the point of saying, "Okay, if I think we only need five for this particular round of research but they want seven, let's do seven." That extra time is not worth battling over. And now I'm at the point where I'm comfortable enough with the research that I do that I'm less concerned about that, and I'm more thinking about: are we learning, are we gaining the value out of the work that we're doing? Because I have the confidence that I can do the research, I can do my best to mitigate my bias, and I can try to get enough to get a broad view. I'm less concerned about how many people, and now I'm more thinking about whether we are learning. So as I've matured as a researcher, or in my discipline, for people who are not researchers, it's been in parallel with that maturing of how I manage my stakeholders.

[00:30:10] Lauren: Thank you so much, Reed, Adam and Parul, and thank you everyone for joining us in this panel. If you take one thing away from this panel today, and I think we've said it multiple times: invest in building relationships with your stakeholders. It will pay off in the long run. And don't be afraid to build your skill over time, to adjust your skill, and learn from your mistakes. I wish all of you the best in building your stakeholder management skills, and thanks for joining us.