Getting Stakeholder Buy-In To Build Better Products

Kevin Duggan, Patrizia Bertini, Hannah Chaplin, Kay Schnittker at UXDX EMEA. Video: https://youtu.be/miE4ZJ_Gu6s

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.

Is data the myth?

[00:00:00] Hannah: Thank you so much for the introduction, that was really lovely, and thank you Kevin, Pat and Kay for being here today. As per the introduction, today we're going to cover the thorny, sometimes thorny, topic of how to get stakeholder buy-in when you're building better products. The four of us got together to discuss this session ahead of time, and the first sentence of the abstract really, really caught our attention. It was: the biggest myth about getting buy-in from a stakeholder is that you need data and logic to make your case. And Pat, you were on it out of the gate. Let's start there. Do you agree with that statement?

[00:00:39] Patrizia: No, of course not. It's not a myth. At least it doesn't resonate with my own experience. My own experience is pretty much the opposite. When I was trying to influence by presenting use cases, user stories and all the empathy that we do in design, you know, "this is my fantastic persona, this is what I know about the user journey," that was not really working. When it started working for me was when I combined the empathy, the understanding of the user problem, the understanding of what is happening in the user experience, with a quantifiable measurement that would actually resonate way better with my PMs.

[00:01:30] The moment that I started pointing out and looking at user behavior through product analytics, I was able to combine what was happening in the user experience, and all the narratives that you hear from users when you test, together with, "Hey, and this is happening. We have an increase in, I don't know, a failure rate or a drop-off rate or whatever rate it is, or a decrease in engagement. So this is how you can make better decisions." And this is how I was able to push changes and nudges. So for me, data has been my best friend, and truly, for me, it's the way that I can show the value of changing and doing things.

[00:02:16] Hannah: Kevin, do you agree with that? I think you've had a slightly different experience, haven't you?

[00:02:20] Kevin: Yeah, I think I had a different experience, and maybe it's the life cycle of the companies I was in, or maybe the particular products. But certainly earlier on, I found that the narrative, almost the artistic side of it, and again you'd think with UX that would be stronger there, but I found more the narrative, what the story is behind it, the more qualitative feedback, the couple of quotes you could get from some key people, were quite important.

[00:02:49] And also, when you're in engineering and you're maybe dealing with non-technical founders, they don't necessarily understand what technology can bring to a product or space. You can talk about it all day in meetings, but actually coming back with something built, prototypes, something they can click, again, for me has been hugely powerful in getting buy-in, and in them saying, "Okay, we see it now. We get what you're talking about now." Maybe that's just me being bad at explaining. But sometimes getting something where you can say, "This is real data. This is not mock data, this is not clickable data, this is something real," I've seen that have a powerful effect on stakeholders as well, given that this is the target we're talking about here.

[00:03:34] Sometimes they might not understand from the engineering perspective what can be done, what's possible, what's not possible. So often, just having something that can click, something tangible they can feel, and also a story built around it, saying, "Well, we can bring this further in this direction, in this direction," and getting them to then steer the direction, can be quite powerful as well.

Transparency, and the narrative around the data

[00:03:54] Hannah: That's really interesting. I've always come at this from a product and founder point of view, so selfishly I was excited to talk to you all to hear a different angle on this. Kay, you're in engineering as well. Where do you go first if you want to get stakeholder buy-in? Do you go to data? Do you do something different? What do you do?

[00:04:15] Kay: I agree, data is very, very important, and for me another aspect that is very, very important is transparency: to share the data, to be very open with the stakeholders, with everyone, to get their buy-in. And data is a wonderful tool for creating this transparency, because the truth is in the data.

[00:04:40] Kevin: Sometimes, although people argue about that, don't they? It depends what spin you put on it, I find sometimes. I think it can be, "abused" is maybe a strong word, but again, you're dealing with people. Data can be overwhelming. It can be hard for you to say, "Well, what are we going for here?" That metric looks good, but how is that arrived at? And it can sometimes derail discussions as well, if you don't have someone presenting the data. Maybe that goes back to the narrative: the data should support a narrative, so that people can go, "Okay, I get the context of this data. I get the points. I get where this person wants to bring this discussion."

[00:05:22] Kay: Yeah, I agree with you. Data of course can be overwhelming, and it needs a bit of guidance to go through the data together.

[00:05:38] Patrizia: No, absolutely. I was saying I agree with all you're saying. Context is everything, and data is not a single point in history or in the journey. It's constant. You don't need one single data point; you need to see the evolution and how data tells a story. So it's both the story of the data and how that story crafts and influences what's happening on the other side, on the user side. It's keeping an eye on what the changes and the variables are.

[00:06:12] So data by itself doesn't tell me much. A 5% increase in engagement is not a story if I don't create the correlation, and I'm able to create a hypothesis and go to my stakeholder and say, "You know what, we did this and it had this impact. Last month we did that and it had that impact. So should we try something new and see what the effect is?" A very experiment-driven mentality supported with data really helps to have interesting conversations and influence the product development, or at least in my case.

When the agreed metric stops mattering

[00:06:50] Kevin: After you. Just a short example. Recently I had a good data point. It was around a key result of an objective, and I was like, "Yes, this is good proof that what we're doing is right." I went to a stakeholder and I said, "Look, we need more investment in this area," and the response I got was, "No, that metric's not important." Yet we had agreed on that metric.

[00:07:13] So I think this is down to the abstract for this talk: data and logic. Sometimes you might have data and then the logic changes, or you have a different understanding of the logic, because we're dealing with people at the end of the day, and all different stakeholders have different personalities. Some really cling to the story and the narrative; some just want to see numbers.

[00:07:32] Hannah: Kay, how do you deal with all the different personalities you have to as a director of engineering? Because you're really at the intersection of lots of different people and departments. Have you got any good tips?

[00:07:46] Kay: Yeah, that's right. We have lots of different stakeholders that we have to get on board and that we have to somehow align, and that's why, getting back to what I said before, transparency is so important to me. When we have different stakeholders for a single team, then we have to prioritize, and the stakeholders have to do it, and therefore it is very important to bring them all onto the same page. We are doing this with a roundtable format, where we present our roadmaps, where we present what we have achieved and what we have not achieved, so that all the data points are transparent to the stakeholders, and then we can take decisions together.

[00:08:41] Hannah: That's really cool. Getting that alignment up front, I definitely think that helps. But coming back to your point a second ago, Kevin, because that happens a lot, people change their minds. What did you do when you'd agreed something and then you felt like it wasn't agreed again? How did you handle that conversation?

[00:09:00] Kevin: Took a deep breath. I guess you have no choice. Then you try to understand, okay, what's the new data point? And maybe try and dig: why is this new narrative or new thing coming up? You go back and you try to interpret and say, "Okay, I misunderstood something, or maybe something has changed that I'm not aware of." And again, you try to build that understanding back up again. I guess if you believe in what you're trying to get achieved with the stakeholder, there's no point in fighting it. You can obviously acknowledge, "Hey, we've hit this. This was agreed. Okay, it's changed, let me have a look at this." So I went back, not to the drawing board, but back to, okay, where is this now going to, and how do I somehow draw a dotted line from where we are to this new place, and try and follow it then.

Speaking to everyone's agenda

[00:09:51] Hannah: That's really cool. We've had a question from the audience, but before I ask that, can you share your experience as well, Pat? Have you had a difficult situation you had to go back to?

[00:10:03] Patrizia: It's always difficult when you want to influence, because you want to change someone's opinion or someone's starting point. So it's all about knowing how you can be everyone's best ally, and what everyone's explicit or implicit agenda is. If you're talking to engineers, what are the KPIs, OKRs, metrics that matter to them? How can that decision that we are trying to push, and we see coming from data, help them to look good and help them to be successful? It's more subtle, and perhaps some basic social engineering: how can I serve you, and how can this narrative be a narrative that helps the narrative of the PM or the engineer or the marketer that is interested in changing? Always build the stories around your audience, so that your story can be their stories and they can click in. It's capitalizing on empathy, in a way.

[00:11:10] Hannah: Yeah, that's definitely a key point from my experience as well. It's understanding what each stakeholder needs, how they like to be worked with, what you can do to support them. I'm so sorry, my phone rang in the middle of that. I think it was one of my children. They obviously don't know I'm still at work today, so apologies. I was listening.

[00:11:32] Patrizia: No worries. It's live. This is proof that it's live, right?

When data doesn't land

[00:11:38] Hannah: We've got some really nice questions coming in. The first one is: have you ever experienced people where data doesn't work? I don't know who wants to start with this. Has anyone dealt with a stakeholder where they just don't care about the data, and it's all about their opinion?

[00:11:57] Patrizia: The thing is, every metric and every way that matters in business language is filled with data. They may not understand certain types of data; you just have to find which is the data that makes them click. My role is pretty much to show the business value of design and create efficiencies. What resonates with my finance partner, "Hey, we saved 30% of budget," doesn't necessarily resonate with others. But if I tell them we saved 20% of time and increased productivity, that resonates. So not everything works for everyone, but it's finding the right data. It's what we were discussing: it's a story. Because you can have your own opinion, but not your own data.

[00:12:50] Hannah: Love it. And there's a nice one here. I'm going to start with you, Kevin, on this one, because I think you've felt the situation. What if you're at the beginning, at the start of a smaller business, and you've only got data from a few customers? Do you trust it, or do you wait until you've got more? What do you do in that situation?

[00:13:08] Kevin: It is very difficult, and something I struggle with in terms of data when you're starting off. It could be a greenfield, new path product, or it could be a new product in itself. I find everyone wants to look for that metric. Everyone wants that key insight, and they're just not statistically reliable. So often I just don't even fight it anymore. I just go with more qualitative feedback, go with those powerful case studies if you can get one or two of those, again if you don't have access to maybe hundreds or thousands of users. You have to go back to that pilot phase where you're like, "Yeah, if I can convince five people, and if I can get their feedback, that's enough." Because you can beat yourself up all day looking for the perfect metric, and at that stage of a product it just doesn't exist.

Too little data, too much data

[00:13:56] Hannah: Yeah, great point. Kay, what stages of data have you had to deal with? Have you been involved in a startup where you've had very little data, or have you ever had the opposite problem and had too much?

[00:14:10] Kay: I think both, because when we are launching our games we have different phases. We start internally with internal user tests, reaching out to some more users, but still very much hidden. And then the next stage would be that we go into a small market, constantly increasing the number of users we can get feedback and data from, so that we are not overwhelmed, but so that we always have a significant amount of people providing us with this data, so that we know that it's worth looking at.

[00:14:53] Hannah: Cool. Pat or Kevin, have you ever had too much data? Have you ever been in that situation where the data has been overwhelming? In my head, the angle for me is customer feedback. Especially when you've launched a new product, that can be very noisy. Have either of you had experience with that? Do you want to start, Pat?

[00:15:16] Patrizia: If you have too much data, it means that you don't know what you are asking and looking for. Having too much data means you don't understand the data, or you are not collecting it in the right way, you are asking the wrong question, so you are generating too much data without making use of it. If we're talking large amounts of quantitative or qualitative data, if they are wrong, they're too much. So I don't think too much is a problem. The problem here is the quality of it and not the quantity.

[00:15:48] And for me that's critical, because even if I have 1,000 quotes from a survey, I should have the capacity to analyze it. Otherwise, why did I collect so many? So there's either something wrong in the process of the data collection, or in how I designed the experience, or how I basically thought about the question. So, not really, because I try to be mindful of the time of the team and what we need, and be focused.

[00:16:21] Hannah: And Kevin, I guess the same question to you. Have you ever been in a situation where you've got this data flying at you and you're like, "Oh, help"?

[00:16:30] Kevin: Yeah, but I agree with Pat. I think where it gets overwhelming is if you didn't know what you were asking in the first place. You haven't spent the time up front to say, what's this experiment, what are we looking to learn here? If you rush into a feature or something, you're like, "Yeah, let's do it," and you get feedback and no one's asking what we're actually looking to learn, then it can get very noisy, because a lot of it is very noisy. It's not exactly where you want it to be. So you need to be thorough and focused on "this is actually what we're looking to learn here," and discard the noisier pieces.

Buy-in takes time and preparation

[00:17:08] Kevin: Got it. And I think, just looking at this, regardless of whether it's data or whether it's more qualitative or more narrative-based, I think the one common thing, and this is from what Pat was saying, is that any approach takes a lot of time and effort. That's the thing. It never surprises me how long it takes to prepare a good case, in terms of understanding stakeholders, preparing your data, getting your case study or your proof of concept together. It takes so much time and preparation.

[00:17:40] And working in engineering, there's ideas everywhere, and people think, "Oh, I should just be able to say it to one person and it should be a thing," and then they get annoyed if the stakeholder doesn't listen. No, this takes weeks and months of shaping and putting your case together. I think regardless of whether it's data or narrative, putting the time in there will ultimately get you to buy-in. It's that lack of time and preparation which means you won't be successful, if you don't do that work.

[00:18:11] Hannah: Yeah, that's a really good point. I don't think many people talk about that. That's definitely the second takeaway from you all, really. The first one being: think about data, but think about the story and the audience. And then think about how it's effort, isn't it? It takes a lot of energy. Kay, when you're doing these roundtables that you mentioned, is that a lot of effort for you? Is it the same group of people? Could you tell us a little bit more about that process?

[00:18:39] Kay: We have streamlined the effort. I'm running these formats for eight different teams, and as we have streamlined the format, it is not that much effort. We have different groups of stakeholders; sometimes they are overlapping, but we are reaching out to different stakeholders. Due to the fact that we have templates for these roundtables, even those of our stakeholders who are present in more than one roundtable find their way through it, and they are used to the format. I think it was quite big launching these formats, but now it's more a maintaining job.

[00:19:27] Hannah: That's interesting. So it's like a muscle the business has to build, almost. You've got to see the value in that alignment and put processes and things in place, like you were describing, to make it easier as you do more of them.

Getting the data when no one will play ball

[00:19:41] Hannah: We've had another question, which is a really interesting one. I'm going to start with you again, Pat. Do you have any advice if you're looking for stakeholder buy-in just to get the data? Have you ever had a situation where you need something and someone's just not playing ball?

[00:19:56] Patrizia: I just do it. The beauty of data is that it's contextual, and you can always create your data. We have the traditional metrics, whatever they are, but sometimes you just need to do a very rapid experiment and create some in-context measurements. So I just run and be creative and invent something. Sometimes you don't need precise data. As long as the data is directional and gives you enough confidence in saying "this is what is happening," that's good enough. You can always refine.

[00:20:42] If you don't have data, make it up. Which doesn't mean invent that one million customers said "we love you," but just find a very rapid, lean experiment to run with. Do it even for one hour, and just share that this is directional: "Hey, if we try something more, we can learn something more, and we can do better, and we can iterate, and we can grow." It's just the starting point, but it always helped for me. So, make your data.

[00:21:12] Hannah: And Kevin, have you ever experienced anything similar? Have you ever had a situation where you found it difficult to even get people to be part of the discussion?

[00:21:23] Kevin: Yeah, and I'd fall back on the narrative approach, or the proof of concept approach. Luckily, being an engineer, you can typically cobble something together. You can do something to get more buy-in. But also, as Pat said, you can use another metric. Like you say, you can be creative. You might find another proxy metric. If you don't have access to a hundred thousand users, you might find some other proxy that gives you an indication. It's not perfect, but it might be something to go back with that's cheaper to get, or that's within your power to get. Then you might make the case to say, "Okay, we should put this out to a wider group and get the data that you actually want."

[00:22:02] So I think typically, daily, we use proxy metrics a lot. Everyone wants to move the needle on revenue, and that's extremely difficult to do, and that takes a long time. So you're constantly trying to say, well, what would work in place of that? If this is the ideal metric, what can we do, what's within our power, to make our case?

Documenting decisions and accountability

[00:22:23] Hannah: Really cool. Kay, for the last few minutes I thought it'd be good to talk about how you actually document any of this. You've had the roundtable, transparency is important, you want to get everyone aligned. Do you document it in Confluence? Do you have a spreadsheet? How do you make sure there's a trail, I guess, of decisions that are made?

[00:22:43] Kay: That's a good point. We are documenting each of these roundtables in Confluence, exactly, where we are taking the notes, where we are writing down the action points, so that we are tagging all users being present, and those who should be present but couldn't make it, so that the stakeholders get notified by the inbuilt notification function in Confluence.

[00:23:09] Hannah: That's cool, and that helps build transparency, right? If you're doing that ongoing, tagging people and sharing, and you've got that trail. Pat, do you do something different? How do you document decisions and that sort of thing?

[00:23:25] Patrizia: I'm pretty much the same, but what I really try to do is to connect decisions with impact, and stakeholders, and who is accountable. I have some base where I have the company OKRs, metrics, goals, whatever we call them, and what the success metrics are, what the team projects and initiatives are, what success is for them, who is accountable for what, and tracking how things are happening, all the decisions that are being taken, and clarifying, if anything goes wrong, who was accountable.

[00:24:05] Because the biggest problem is you start with quarterly priorities, and suddenly, six weeks into the quarter, someone comes and says, "Oh, that priority that was super important, super hot, super urgent: drop it." And you just find that you wasted six weeks' worth of work for three resources, and you start doing the math on how much I'm wasting. Again, data. So, hey, six resources for six weeks: how much time, how much money, and who is accountable? Who took the decision to change priorities? So yes, I'm probably more focused on impact and accountability of decisions. But give me a base and give me OKRs and I'll track everything.

[00:24:59] Hannah: Very cool. And what about you, Kevin?

[00:25:01] Kevin: Yeah, I'm happy with OKRs. I'm trying not to go into too much detail in terms of tracking every decision. If the outcome is hit, that's okay, and if it's not, you review it in the quarter or whatever and see where the team went astray, maybe, to your point, that something came in in the middle of the quarter that they had to switch to. But I'm typically happy with a quarterly cadence, and again, focusing on the outcome, focusing on hopefully measurable results, whether it's a really small sample or where you've accessed a lot of people. It doesn't matter, once there's something there that people are aligned around.

Air cover from the C-suite

[00:25:39] Hannah: Cool. Oh, we've got five minutes and one more question, hooray. What was the best example of air cover, so support from C-level people, you've ever gotten? Kay, have you ever had a situation where you've needed to align a stakeholder and someone in the C-suite has saved the day, or really been on your side? Have you got any good examples of that?

[00:26:04] Kay: Usually the C-level people are also invited into these roundtables. This is very important, I think, to have this approach of jointly coming to a decision through all hierarchy levels. And from time to time, of course, it happens, especially when things come in from outside, Facebook or Apple changing their APIs, where it's pretty obvious that we have to do something. But coming back to the cadences, for example, that's why we've decided to have only a four-week cadence, to be very flexible and react in a very agile way to all these needs. Because I agree with Pat, it is a drama when you have to throw away six weeks of work or so.

[00:27:00] Patrizia: It is an absolute drama, yes. 100%.

[00:27:05] Hannah: Pat, have you got any examples where you've had to bring in the C-suite, or are you similar to Kay, in that the process includes them anyway?

[00:27:15] Patrizia: Well, in a way my role itself, managing design operations, means that I'm an enabler and I empower teams, leaders and everyone to do things. I always describe my role as a brilliant number two. "Brilliant," because it's always nice to say. Jokes apart, it's about making sure that I have the relationships, and I'm their ally, and I'm the servant enabler that helps. So for me those relationships are critical and are part of my role, because without C-level buy-in, without getting their support, and without being able to speak their language, because it's always about speaking their language, I'm useless.

[00:28:04] Hannah: Perfect. And Kevin, do you have a similar relationship to Kay and Pat with your team?

[00:28:10] Kevin: Just thinking back to the question, an example has just come into my head. On a previous team I worked on, we stumbled across something that technology enabled. We were working on a particular solution for a particular part, and we were like, "Oh, there's something here." This is back to the illogical, or the logical, part of the abstract. Logically, from engineering management, which I wasn't in at the time, we were locked into quarterly things, and it didn't make sense to go down this road.

[00:28:39] But having other stakeholders aligned, and having your network in your organization, having a side channel to the CEO, and presenting what we stumbled upon, which was very close to his vision. Often in middle management you can be locked into this process, but actually going to him and presenting a narrative and showing, you know, this could accelerate the vision, the vision might take three years, but this could be a key foundational piece of it. That then helped to get buy-in with the middle layers. So it wasn't very logical from the engineering management point of view, but it really tied to where the company wanted to go, if you like. Maybe it was a bit bold to do that, but it worked.

Closing takeaways

[00:29:29] Hannah: Oh, I love it. A brilliant example. We've only got a minute left, which I'm sad about. That went far too fast. But thank you all so much. That was a really, really good session. I think the key takeaways from listening to all this are: think about data and storytelling, and combining those. The stakeholders are all different personalities, different people, so just being mindful of how to communicate and what they need is really useful. People are hard work, right, Kevin? It takes a lot of time to get stakeholders on board. Patience, patience, and deep breathing. And then finally, as Kay's explained so nicely, transparency and process can go a really, really long way in getting the buy-in you need to build great products. So thank you all. This has been brilliant.