Managing Anxious Stakeholders

Speaker A: And now the daily sprint. So you've seen it. The stakeholder that always seems to swirl for one reason or another. Changing requirements, not aware of the impact of the questions they ask. Well, today on the Daily Sprint we'll look at what makes stakeholders anxious and how you can respond in a designy way to get them on the right Track. I'm Darrel Estabrook, 30 years in UX product design and the founder of Designy, a platform for product designers who want to design with a. Why I coach designers into leaders through real time, uh, interactive product specific guidance. Find out more and get on board with a free newsletter@designy.com that's Design with a Y.com. So welcome. It's episode 21. That's my favorite number times three. So how are you doing today? It is another day. It's the Daily Sprint. So it's a great day to design. If you, you are awake, if you are ready to go, hey, there's a whole lot to do today and are you ready for it? I'm ready for it. You're not always ready for it, but hey, we're going to go in anyway. So the stakeholder anxiety, it's a great phrase. It popped up this week on social media, talking with someone on there and it's like the idea of the nervous stakeholder kind of the actions, reactions, the statements they make and just how they seem to uh, go around the design process and yet they're leading the product. And so it can be very frustrating as a designer when you're going to the M meetings, requirements seem to change, they don't seem to make sense or they shift in such a way where it's like, well, this is not what we were doing and now we're doing something else, so what do we do with it? It's a real thing. Uh, I think there's two ways to look at this. There are stakeholders who react without strategy and you can say it's not like there's a private room they go in where the real strategy lives and then they go mess with it and then come back. But a lot of the times the requests that can be made don't have a clear outcome or they don't fit with the purpose. Uh, that's been established. So it can appear or be legitimately without strategy. So I think that's kind of the overarching category. And then stakeholder anxiety, it could be the reaction of a designer. Designers who fear talking to reactionary stakeholders, uh, that's also a real thing. If you are on a project. And, you know, the stakeholder is anxious. The way that they bring up these requests and all of those other things we just said. M. Who wants to walk into a meeting like that? That's not fun, but yet it's what we encounter. It's real, and we need to be able to deal with it in a way that's constructive and especially that can help guide them in the design process. There's all sorts of content that I've created on that, what the design process is and how you can really leverage it. But we won't go through that today, but we'll talk about these two aspects. So it's a two for one topic today. The stakeholder and the designer, all with this anxiousness that's there. So stakeholders who react without strategy. I see it every day, but in different ways. It might actually be the same person, uh, because it's a different day. Hey, there's a new day to design. That's the daily sprint. But how are you going to. How's the sprint going to turn out for you? It's the same thing with the stakeholders. They're in a sprint, too. We're all in this daily sprint. It's only the day that we have to take action. And so you kind of get these, uh, reactions like, which stakeholder will I get today? Will it be, uh, actually working with me or, uh, working against the product? And then, of course, there's stakeholders who are locked in. Excellent. Um, just collaborators with the design process. But it's these off days. Even the best stakeholder has an off day. So how do you deal with it? Well, think of it this way. The stakeholder is going to feel pressure to perform. You put yourself in their shoes. They are responsible for a lot of stuff. Why would they be anxious? Well, uh, this pressure to deliver, There's a lot that goes into that. Consider this. They have to deliver an outcome. Now, they may not know what it is or have thought of it in terms of an outcome. They might just think they're producing this product to do this thing, and that's the outcome. It should do the thing. But, like, how well should it do it? That may not even be in the purview. How do you deliver an outcome? I mean, that's. I don't know. It's like, grow me a garden that has delicious fruit. You're like, okay, uh, I can plant the garden, I can choose the seeds, I could probably work, water it and stuff like that, but I can't guarantee it's going to be delicious. Uh, there's a point at which the outcome is outside of their reach and yet they're responsible for it. So imagine that. That's a lot of pressure. They also have to deliver on time. And somebody said, get this done by the end of the quarter. Like, sure, that was fine at the beginning of the quarter or two quarters ago. Now it's, you know, 12 weeks is not a lot of time. You know, 12, six sprints, really, if you want to think I was like, 12 week sprints, we've done those two. Yeah. There's always delays, something that you couldn't think of. I mean, the days of waterfall process for software design, it's like we're just going to design it all and execute it. Well, that never worked. It, uh, still doesn't work. Um, you're always going to encounter something that you didn't expect and you have to work around that. And it takes time. So that's a lot of pressure, especially as you get further into the product. So at first it's real easy, but then it's like, oh, will we deliver it? And will there be an outcome? No. And then think of this third one. They are delivering something that they can't do themselves. So it's one thing to say, go plant a garden. Okay, Go plant a garden, get all my tools, get all my materials and go do the work. And I did it right. It was me one to one. But this is someone in charge of a team of people or working with a team of people. And that team of people has an expertise level that is off the chart compared to the stakeholder. Stakeholder is a business person, very savvy. I, uh, give them great respect because they are in charge of the company initiatives, whether they recognize it or not. They're the ones. I just work here and I say that in the honest sense I am here to help them. Uh, they can't do the design and they don't know the engineering. They may have been a designer, they may have been an engineer, but they're still actually not doing it. This time, very different. You have to trust the people that you're working with. So all those things are pressured. So they're going to manifest kind of this anxiousness in a bunch of different ways. And here are a few, uh, and some of the bad reactions, maybe not ideal ways to handle it, either them or other people. So one thing is asking questions about whether something can be done. So the anxious stakeholder, um, m. They may just be speculating or they may genuinely be asking a question or they may be passively asking a request. All of those are very confusing. So I've seen this in, uh, designers who kind of clue in on a question or something that was asked and they immediately think it's a request and they try to execute on it or they make promises to do it and it's really. Do we understand what the request was? What kind of request? So the anxious stakeholders are speculating about m. If this were that, could the user end up doing this? So that can really throw things off. And like I mentioned before, think of this other one. Literally getting nervous about a looming deadline. Like, some stakeholders don't handle that very well. Sometimes they get harsher. I kind of think of it like a jockey on a horse, you know, horse race at the end, that last stretch or whatever. They're, you know, they've got that, uh, the whip, I guess, right? And they're just like, go, go, go. And so you might get this product team, this stakeholder, uh, that just is like, I'm going to sink in a lot of extra hours and then everyone feels obligated to do the extra hours. Or they might actually be vocal, like literally more vocal, uh, more meetings and it just makes more swirl. This is a bad reaction. That's not good. They might have even moved the deadline, I guess, if they have the power to. Yeah, it doesn't help. Then this other one of changing the requirements, like an anxious stakeholder, it's like, uh, that's not working well, let's change this. Sometimes they react to all these other pressures, but sometimes it's because they've discovered a new feature in some other software that they happen to be using that day or that week or, hey, I was in this other app that has entirely nothing to do with what we're doing, but there was this really cool feature that it had. Sometimes that's really good, right? We always up for mashing up things, but sometimes that can just really redirect the focus of the product because it's like not the right time to incorporate something new or something experimental. So yeah, it's. Changing requirements might have good intentions, right. But it's not always have the good effect. So consider this. If you're an anxious stakeholder, maybe you're listening to this, maybe you're maybe, I don't know, maybe as a designer, uh, you can slip some of these into the stakeholder. But I think there's three things that would really help, like make your requests clear. That's true for anyone, really. It's so easy to assume that the person you're talking to is thinking in the same way you are. So that when you say you make a request, uh, or even not even making a request, like, yeah, we need to do that, this needs to happen, everyone nods their head, yes, it does need to happen, but who's going to do it? When is it due? How big should it be? All those things make them clear. And like we mentioned earlier, this hypothetical question, uh, be clear, is this hypothetical, Hey, I want to think through this. Let's imagine, uh, or say, hey, here's a new request. How do we work this in? Or what happens to the project if we try to get this in? Like that really good. Nothing wrong with being clear. I don't think anyone's going to be embarrassed to try to answer those questions. And if they don't, maybe it's a little one hour research effort to get that locked down. How about this one? If you're an anxious stakeholder, ask your designer how this request will impact the users. You might actually see your designer faint on the spot. I think this is what now. I mean, there's so many other things that we would love to have, uh, the opportunity to answer. But if you're like, hey, we want to make this change, how will the users, uh, be affected by it? I mean, we're talking at a level of design that's fantastic. That's our wheelhouse. We live in that thing. And that's really the product. That's where the product lives. It's only there for the users. It's not a pet project. So, yeah, how will making, changing this feature, what will happen? Uh, we need to make contingencies for that. Do we need to ask the users, do we know this answer ahead of time or does it have to have some research? Excellent thing that you can do, actually, will take your anxiety down. And then this last one, consider the smallest acceptable form of the feature just so you can get it out the door. Now, this isn't slop and it's certainly not, uh, to produce something of lower quality. But there's always something about a feature that you could dial back. Uh, it could be the whole feature itself needs to just be shelved. But you have to consider, if we spend more time on this feature to get out the door, what is going to happen to the overall product? Is there something about this feature that is going to cost more time for not that much lift? And I always like to ask the question, if we didn't have this feature at all, what would happen? And it's a Great question. Because if the answer is, well, nothing, or it's a very small percentage, or we don't know, it's not critical, well, then just say, hey, let's push that to the next release, whatever your time scale is. The next thing. Let's see if we can answer those questions and maybe ask the users if it's even valuable. Now you're talking. That would be great. So let's switch over to the designers who fear to talk to these reactionary stakeholders. I mean, that's a real thing. When I was just starting, I was very fearful of going into a design review and having people just pick apart the design, and all for the wrong reasons. Because I put a lot of work into the design. I wanted them to really say, hey, wow, that's awesome. Good job, do more of it. And those come in time. But that's not what we're there for. It's really to make sure that the design is achieving that outcome, solving the problem. Is it the strongest design we can make? And is it the strongest design that we can make? There may be other designers who are more talented, experienced, what not, and they might produce something stronger. But you are here now. You are the designer. What's, uh, your best effort? And that's what we should talk about. But, yeah, it feels like dread just walking into these things. Uh, one thing I'd like to kind of point out before we look at some ways to approach this is we don't need to fear people. Now, that's easy to say, but it also has to have a bigger perspective that's attached to it. It's not just, uh, pull up your bootstraps, hold your breath, and count to 20, I think. And you've heard me talk about this before. When God is in your life, he's much bigger than everything else because he made the whole universe. So there's a lot going for you. And there is this verse 2 Timothy 1:7. It says, For God hath not given us the spirit of fear, but, uh, of power and of love and of a sound mind. There's all sorts of value you could get out of that. But remember this. We're all people. And some people have coped with the stresses of life under their own wisdom. You have a bad situation. You're like, I don't want to go through that again. So let me react. Let me come up with a, um, mechanism to interact with people in a way so I can avoid that pain. That's just what people will come up with. That's not the right way to come up with it because it'll only be custom to you and it'll maybe have side effects that really hurt other people. But God has figured this all out. So when you trust God, God with your life, you actually can step forward without weakness but with the power of truth. What is true? I think a lot of design of what we're talking about is about truth. We want things to be true. When people click this thing, this happens. So we want to talk in terms of truth. You can step forward without fear, but instead with love through service. I think when we are here, like I said, I just work here, but that's a service. I'm serving the stakeholder. They're the ones that are in charge and I want to make sure that I'm delivering this thing. So it's out of love that we're delivering that. And then you can step forward without being reactionary, with a sound mind. It's wisdom. That's level headedness. The other people, people are going to be reactionary. Um, uh, you don't have to be one of them, but that requires you having wisdom, which means having a plan, which means knowing where you came from. So I'd like to go through a few things uh, regarding the reactionary stakeholder. How do you deal with reactionary stakeholders? How do you not fear? So here's some things, three different phases. Right before you meet with them, um, while you're meeting with them and after you meet with them, um, like that little arc. I think there's a lot of things, here's some things to consider. So before the meeting, are you prepared to explain your design? Don't just have a design or have designs. The having, well you need to have them. That's not the thing. But, but you need to be able to explain them. This is one of the big troubles with AI generative and generating the designs. Because you can just turn around and say it made the design and we can maybe look at whether we like it or not. Well, um, no, there should be a reason for everything on that screen. You should know it. You put it there. And if you didn't put it there, even if someone else on your team put it there, you should know why it's there, should be able to explain it. If you can explain the design to a stakeholder, you will have every question answered that they could ever ask. And if they ask a question that isn't explained by the design, the answer is this design doesn't cover that situation. Uh, should we explore it? And let's talk A little bit more about what you mean by that. Awesome. Awesome. Another thing, before the meeting, did you promise to demonstrate anything from the last meeting? So if you said yes to stuff, bring it, don't say you didn't finish it. Um, make sure you do it. We'll get to it later. Be careful what you promise, but always demonstrate the things that you promised. It just shows you're diligent and thorough and that helps stakeholders be less anxious. And then this other thing, before the meeting, did you discover new questions since the last meeting, and do you have the answers? So this is great because you're exploring design, you're on your way towards solving this issue, uh, the challenge, and you're going to run into other things or you're going to say, well, what if this. And you start to explore those branches of, of possibilities, right? And so you're going to come up with questions or you're going to run into something where you're like, oh, I can't finish this because I don't have something, or another. Go get the answers if you can get them yourself. Talk to the right people, get access to the right thing, get sample data, whatever it is. And when you're blocked, you raise that to people running the project, whatnot. Uh, and if it's totally blocked, the stakeholder should be able to unblock it or it becomes a thing that truly blocks further progress and you have to tack and go a different way. Really good things. But if you don't have the question, if you don't have the answers, bring those questions to your meeting. Because that is a type of, uh, preparedness. So then during the meeting, now that you've been prepared to explain your designs, explain your designs. Right. Don't defend them. That's so big, it's so crucial when you start defending the design as like, I put a lot of work into it, I was distracted. These, uh, are become excuses and it distracts. It's not. You're not really actually talking about the design, you're talking about yourself. And it's really not about, it's not about you. It's about the design being the strongest outcome. And so just explain. And like I said before, if there's a question that you can't answer because the design doesn't explain it, well, now you can say, this is as far as we got with this design, but we can find, uh, out more about what you mean by that. And that kind of goes into this next thing during the meeting, which is to identify new requests and handle them appropriately. It's huge. Again, this is so many things that stakeholders, uh, say, and you're not sure where are you coming from? What does this mean? I have a, uh, course at the end. I'll tell you about that. Just can help you go real deep into this and equip you to answer those questions and handle those. Just remember that these are people who are also trying to make things happen through other people. So you are trying to understand the stakeholder, but they're working with more than you. There's other people around that they need to try to get outcomes out of. The third thing during the meeting, don't promise to deliver every suggestion but research and follow up. That's always a good principle. Uh, that's what can get you into trouble when you go to do designs before the next meeting. I promised a lot. I don't know if I can do it or should do it. It's worth doing. But you can always take any suggestion and if you don't readily have a path forward, you can say, I'm going to research it and let me follow up. So then after the meeting, here's some three things. So what's the soonest you can reply with an answer? I love this one. If something comes up in the meeting, there's a question and maybe research or follow up. How soon can you get back to someone? If you can get back to them later that day, that's fantastic. The next day, that's still really good. The day after, well, the longer it goes on, the bigger the answer should be. Kind of proportionally you think, well, if it's a small answer, you probably could have asked it and gotten the answer in a speedy way. If it's real small, if it's this big, long, involved thing, well, maybe you shouldn't be getting involved in a big long thing, but use that as a pressure point to really motivate you. How soon can you come up with an answer? And it may be that you don't go too deep on that. You come up with some blockers and you reply with, hey, this is what I found. And then a second, uh, thing after this meeting, set up a 15 to 30 minute. It's going to depend on who the stakeholder is, how talkative, how much you talk and that. So you kind of have that relationship down and their, uh, schedule. But 15 minutes is pushing it to be short 30 minutes. Don't want to go past that. But I always like to promise 15, uh, to 30 minutes so that they know I'm not going to monopolize their time. So a lot of respect in that. But have a pencils down review before the next meeting and pencils down review definitely cover that in the masterclass. But it's literally put your pencil down and hey, step away from your work and let's look at it. If you present it as a work in progress that's hyper focused on a single topic, that's why it's a 15 to 30 minute conversation. You'll definitely get the answer you want. You'll have demonstrated that you're able to work quickly and you have good ideas. Like these are all good things to help stakeholders be less anxious and you're less anxious because you have answers. And then the third thing for after the meeting, it's kind of an easy one because it's all the stuff that I just said for before the meeting prep. Got to slip that one in there. Yeah, I mean, are you prepared to explain the designs? Are you promised to demonstrate anything and did you discover questions since the last meeting? Those things circle back around and just make sure you're doing those and you'll have a better foundation to have a conversation. You be the stable one. Right. Remember, sound mind. A sound mind. You be the one that has the answers or at least the direction of stability. And that'll definitely help, uh, some stakeholders to be less anxious. And that's what we're going for. So like I mentioned earlier, if you want to identify new requests and handle them appropriately in the moment of a meeting, uh, it also works in messaging, email, that sort of thing. But a lot of times in real time, that's where the pressure is on. Well, I cover that in a course on Designee Academy and it's called how to make Vague Requirements Clear. The same kind of principle of the anxious stakeholder. But vague requirements happen all the time and that doesn't help us as a designer. Vague is fuzzy. So we want clear and you are the designer so you can lead them through a conversation that makes it clear. This is a very short course. You can complete it on your lunch break and try out the techniques in a meeting later that day. So we're not talking a lot of time investment, but some, um, thought provoking behavioral adjustments that you can try out. I talk about the two kinds of requests and how to get to the heart of what stakeholders really want. So go to academy.dezigny.com that's academy.dezigny.Com Click on Courses and you'll see how to make vague requirements clear. Also, if you go to designy.com Sign up for the free newsletter. You'll stay up to date on topics and initiatives at least once a month, if not more. And that's just Design with a Y.com so thanks for listening to the Daily Sprint. Remember, today is a great day to design with a why. See you next time. Sam m.