Getting alignment & building trust with our stakeholders

Trust is something that doesn't come one day, like it's not something that's for term. I think it's a building of, it's kind of this accumulation of all the different tiny things that you've done with that stakeholder builds that trust at the end of the day. So it could be, so I don't think that, you know, it has to be like this big grand gesture, but just every day tiny things, checking in with your stakeholder or even trying to understand how they how they prefer to communicate like I think tiny things like that can build up over time. Hello and welcome to the Design Explorers, a podcast by the Agoda Design Team. Agoda.com is a global digital travel platform where you can book hotels, vacation rentals, flights and airport transfer. In this podcast, we will be sharing the awesome work of our design team. Discuss interesting trends in relation to design and travel and talk about product design in general. My name is Nacho Miamin and I will be your host for the show. Our guest today is Yuiiko, a senior product designer at our team who works on our customer experience group internal tools, where she gets to manage different stakeholders in the work with different parts of our business. Yuiiko is here today to share with us how she managed and worked with so many stakeholders and her interesting and quite unique background before transitioning into design. But before we talk about all that recently we celebrated here Sancran, which is the tiny year and it is also a time for many of us to take vacation and travel. During her vacation, Yuiiko had a very interesting experience how she got to use the product that she worked on as a designer but as a customer and she wanted to share that with us in some of the insights she got from that experience. During Sancran, I had gone to France and Portugal and on my last day in Lisbon, I decided to check into my flight online. I thought, "Oh, I need to check in." So I checked into my flight and when I did, I realized that I would land in Bangkok on the 17th of April and I remember distinctly that I did not book a hotel for the 17th. I thought that I booked it for the 16th because when I had originally booked my airplane, the confirmation said departure, April 16th and then Bangkok plus one and I didn't really think too much of the plus one time difference. And so, and it's been such a long time since I had last traveled to that I didn't really think much of it and then in Thailand you have to submit the Thailand pass which is the entry document to to get back into the country. So I had booked my hotel for the 16th and then I have the Thailand pass. But when I checked in, I realized that that Thailand pass probably does not work because it's for the 16th and so the 17th. So I went into our chatbot which I designed or I helped design and I'm going through, I'm walking down the streets of like, so let me paint you a picture. So it's like 10 p.m. And via my friend or walking down the streets of Lisbon, I just checked into my flight and I realized I've made a mistake and then I go into our go to chatbot and start to, it's weird, I went straight to try to contact an agent and I'm waiting in the live chat waiting for an agent because I don't have international roaming and I felt like email might take a while so I just decided to do the live chat. But I'm walking so my phone will keep on like turning off and I think maybe that's why, or I don't know if I got disconnected or not. So I was just waiting without an agent coming and I would try multiple times, try to see if I could get an agent whereas I should probably just stay on the line and wait. So I got connected to two agents actually. The first one told me that I can't change the hotel date and I need to cancel. So which is great because now I knew like what I need to do. So I, I canceled, I re-booked and then I went to live chat again and then the agent told me that they'll contact the property to see if I could get a refund for my previous, the one that I originally booked and she was able to get it within like five minutes or so, she was able to get it for me. So the whole journey was like maybe, I don't know, maybe like an hour from the moment I realized I messed up to the moment where everything became resolved but I thought it was really interesting because out of the hour, maybe I was talking to the agent for about 15 minutes. So the human contact part is really, is, is not as much and all the other parts that are offline is a lot more and it made me realize, I kind of wrote like a diary study of it afterwards in the, on the plane because I wanted to make sure I remembered this feeling when I do go back to like improve the product again but I just thought it was, it was just so, it was just so ironic how like there's, there's parts of the chat but that I didn't really think about it too much when I was designing because I was never really immersed in the experience and when I was immersed in the experience I was like oh my goodness this has to go or like we can't be doing this or we can't be doing that. So I think it was a good, vacation but also a good learning experience that brought me back some, some good thoughts as I came back into into work but yeah I didn't think I would have to, I don't know it's been a long time since I had traveled so I think it was a good way to kind of understand the customer a little bit more to in the real world. That's a very interesting story I think my song chronicles just a little bit more boring than that, it wasn't as eventful so I think there's a lot to learn and I think being in C-E-G customer experience group you have the, I guess being in that position of experiencing your own product is as you said insightful even though you try to always be in the shoes of the users right so could you kind of walk through the audience like your experience in C-E-G and maybe what you do there? Yeah so C-E-G stands for customer experience group and adagota that's basically kind of our customer service customer support team so the purpose of our customer experience group is to provide help for any of the issues our customers or suppliers or partners face when they use a go-da. So what that means in terms of product is that there's actually a bigger ecosystem of different products that create customer experience groups so so when I was in Lisbon on the chatbot that was like a customer trying to contact a go-da that is a touchpoint. Customers can go into our help center page they can also give us a call so there's a variety of touchpoints that customers have when they try to make changes with their booking but on the flip side there's also the agent so there's agents that are on the front lines that are taking customer calls or even hotel calls to try to solve these people's cases and they also use different tools in order to handle these cases and there's also another suite of tools that are in the backstage of these agents that create the workflows for these agents because we do have many agents but we have even more customers and to be able to provide a consistent experience to all of our customers agents need more guidance and we we have workflows set in place for that. So so C, G in terms of product there's a lot of different tools and products that create this whole experience and make it all possible that also comes with a lot of different people too so there's there's people like us like designers, developers and product that are more on the the product side but there's also a bigger business unit that's kind of in it of its own its own little organization where there's people in technology and operations we also have our own separate people team to train and hire our agents so there's a there's a bigger I think business component to to the customer experience group and as a designer it's really interesting because not only do you create products but you create products for different types of users as well as collaborating with a lot of different stakeholders as well. And today's episode is about stakeholder management right and I think last we talked you your background is actually not in design right you initially started your career somewhere else could you talk a little bit about that and maybe connect it to how you came to be a C, G designer and how it has helped you in your current position. Yeah so I I never thought I would be a designer. I I'm also kind of surprised that I'm here now because my background is just so seem so remotely different but I started out in sales where I was doing B2B sales selling broadcast fiber in Japan. And that's kind of how I started my career and in sales I learned a lot of things but We have, since it's B2B, our clients are longer-term enterprise clients. So maintaining good relationships was a key to getting those deals and making our products successful. So that was kind of a lot of what I learned in sales. And from there, I progressed more into project management and managing the projects to execution from when we close the bid with our clients. And from there, it kind of evolved into more of a strategy role. And as I progressed through my career, I learned more about the business side, the strategy side, but then I became more interested in being more on the product side and being able to actually execute some of the work. So I pivoted into design and I think it's a great intersection between business and the customer and the user. And I think that the skills I had subconsciously kind of acquired through all of this. I ended up being a strength at the end, especially as a CIG designer because it is, there are obviously visual elements too, but it is also heavily UX and domain driven. And there are, I think, I mean, I think I know maybe 1% of what it is to know about CIG. It's a very complicated area, but there's a lot of different people who are experts of their area. And so as a CIG designer, similarly to sales, I am talking to different types of people, of different types of backgrounds every day and learning from them and also trying to figure out ways we can better collaborate with them because at the end of the day we are trying to make this cohesive ecosystem of different types of products for our different users. So that way at the end of the day, the customer is able to get fast and efficient service. So I think that while at the moment in like those different moments in my career, I didn't realize how they would be beneficial to me, I think, looking back. I realized that someone, those dots kind of connect where in sales, I think there's a lot of transferable skills like like facilitation, presentation, time management and stakeholder management. And I think the stakeholder management part is something that I am really glad that I learned because it's something that I feel like is something that I do every day today and is something that has really given me a lot of opportunities to collaborate with our broader team. So yeah, who would have thought we would come from sales to here if I hear we are? Maybe you can give us some examples of some of these skills that you picked up with your experience and what you learn from sales and project management, how they come into play in design and what exactly these skills. I think that in sales, I learned a lot about empathy and understanding the client, which is something that I use today. I think in our design process itself, we start from research and we start from discovery understanding what our users need, what are the constraints, what are the limitations, what are these people's goals. And I think that sales really kind of taught me that because I mean when I first started out in sales, I thought that I would be really, really bad at it because and I was also really scared because I don't particularly enjoy talking to a bunch of different people as much as I'm sure like a lot of extroverts do. But I think one thing that I learned from sales, looking at all these different types of people, they managers, my colleagues who I would shadow and visit clients with, they were really good at understanding and it also came from a lot of listening and actively listening to the client understanding on a business level of what kinds of things they needed for that particular project, but also they were able to connect on a human level too where I feel like the colleagues and managers I worked with were really good at trying to look up current events of the company there, the clients at to bring up some conversation or they would ask questions about that person's interest and they would remember all of that information. So the next time they do come and meet the client again, they're able to have these talking points that they could talk about and connect with the client more. So I think that taught me that it's not really a lot about talking in general, but it's a lot about listening and understanding where your stakeholders are coming from, which I think I still use today. In terms of project management, I think because in CHEG a lot of our projects are very big as in designers would own one product as opposed to say like a feature or a subset of a feature and I think that our scope is rather big, that when it does come to creating something bigger, it is really important to have kind of the priorities set to, which I think is something that I learned in project management where I mean I think in an ideal world we want to do everything, but it's really hard to be able to do everything. So we need to set priorities and I think those priorities also come from the different stakeholders too of what you stakeholder, what are their individual goals, also what is the common goal that we want to achieve with the product and kind of laying out those priorities in that way, that's something I learned from project management, but I think for both of them, I think the relationships you cultivate with your stakeholders will make a huge difference in how you are able to collaborate and I think at the end of the day we'll show in the products that you create and how you innovate. At the end of the day I feel like we're all humans and design is very human centric that also are the way we collaborate, I think also has to be in a way, in like a similar way where we understand each of the stakeholders own challenges and the differences too, I think they are stakeholders because they are different and they bring something different to the table and they have their own expertise. So acknowledging and respecting that and also trying to understand their domain a little bit more to build trust over time and cultivate those relationships with something that I learned and I still use today. Moving from a different industry, coming into travel, have you felt any differences in stakeholder management and how you might go about your way managing stakeholders expectations at a go to compared to your previous experiences? Yeah, so previously I was at a larger corporation doing sales and then I've also worked as a designer in an agency environment and I feel like those are very different environments where sales, you know, it's really dependent on the client agency, it's a little bit more short term projects and client specific. I think Agoda is my first in-house product company and I think that from my experience at Agoda, I think it's a little bit more balanced where I feel like of course as designers and as a product organization, we aim to delight our customers, our users and make sure that what we're creating is actually useful. But at the same time, I think there's a balance with the business too where without a business, we don't have a product to create but without users, we don't have a product to make either. So I think that there needs to be a good balance between the two. So I think that the way we manage stakeholders in any of the environments, I think at its core is not so different where it does come from understanding and empathizing with the stakeholder trying to understand where they're coming from. I think is something that is same for any environment. I think because at Agoda, we are an in-house product work. I think one thing that might be different is that we can bring these stakeholders really early on in the design journey. Instead of maybe at an agency you need to show something more polished but Agoda, I feel like I mean, I create draft designs in some of them out and see what happens all the time and I think it's great because it allows us to collaborate earlier on. And build something together as opposed to having something more siloed where design will design and then hand it over. I think that there's a little bit more collaboration but I think that also is why it makes things more. complex to for CIG. There are a lot of different people that I would share designs with. It's not just the product folks, but it will also be people that are in operations who understand kind of what the agent workflows are or we even show it to the agents and see what they say. And I think there's a lot of a lot more people that we share with, which can make it more complex because you are getting different types of feedback. But I think at the end you can create a better product because you have so many types of voices and different perspectives that are incorporated in anything that you should. So stakeholder management and the other days working with people, like you mentioned, you have different backgrounds, different perspectives. And because of that sometimes you could have maybe conflicts or challenges working with other people. How do you manage that? Yeah, I mean, I think it's, I think we will always have conflict. I don't think that it because because we're from, we have different backgrounds and different different expertise and different agendas at times, I think it's completely normal that we do have conflict. And I think how we approach that conflict is kind of the key part because we can't avoid conflict. And I think it's good to have conflict because that also means that we're in a space where people feel open to, to say their opinion to. I think though that while individually we might have different goals and different challenges and different limitations, at the end of the day, the common goal that links us all is, is should be there. And I think that when there is this common goal, then it kind of all links us together. So it would help to understand what those, what the common goal is and what the individual goal is. To give an example in C-H-G design, we, we are trying to create a longer term research plan. And we wanted to figure out what types of research and what types of information of the user we currently know. And then what are the things that we don't know that we need to know. And what we did was we did this workshop, but we brought in people of all different backgrounds. So we brought in developers, product managers. We brought in people from operations. We brought in data scientists, different types of people. And when we did the exercise, it's true, like a lot of the stuff that we see in those individual stickies are very different. But when we went back and synthesized, we started to see that there are common themes and common goals that link those stickies together. And so I think that when you do have conflict, it may be helpful to see why that conflict is happening, where that person is coming from, and what that person's individual goal is. And then also kind of reflect on on yourself too of what you are trying to achieve and why you think maybe this is a conflict. And then if you could map it back to the common goal, what you provide as a solution can be something that not only incorporates what you would like, but also what the stakeholder might wish for to. And if you can map it to the common goal, I think it not only becomes more of a win-win situation, but I think it also makes the stakeholder feel understood and heard. And I think those are things that can build trust over time. Like even when as designers, when we're presenting a design, instead of saying, hey, I think ABCD solution would be great. And if it's just coming from you and just coming from what users have said, that's great. But I think it elevates it one step further when you can say something like, hey, I understand that this stakeholder, we have this issue and this stakeholder, we have this issue and we have these types of limitations. But in that, in this environment, I think that design ABCD would be a good way to not only account for someone's that limitation, but also provide a better experience for the user. And I think if you can frame it in that way, it would also make the stakeholders feel like they're not being dismissed and they're being considered. And also the solution you bring is a lot more higher quality and showing a little bit more holistically or knowledge of the entire domain. It's actually catching me by surprise in terms of the impacts that it could have. I think the end result is to come up with a solution that tries to satisfy the stakeholder as much as possible. Hopefully that's a win-win, but a lot of times there are trade-offs that need to be made. And when are there, there are those trade-offs that need to be made. As you said, involving the stakeholders early on and kind of making sure that they're not surprised and their opinions or objectives or voices are heard, make sure that they have somewhat investment and they're likely to accept any proposal or solutions that you propose on the table. So I think that's an interesting way to kind of see our job as a designer and how we could make impact or lead change within the organization. I think you have a pretty unique background as a designer and I think if you hadn't gone through all the previous experiences in sales and project management, what kind of advice would you give to a designer that doesn't have all these similar backgrounds as yours? Yeah, I think that honestly I was just lucky to be kind of going through that in my career, but I think that what I learned are things that we could do every day as designers, even without a sales background or any kind of background per se, because I think at its core, it's if we can be empathetic, I think that enables us to be more proactive. And if we could be more proactive, I think that will build trust over time and that I feel like is kind of the foundation of building good relationships with our stakeholders. So I feel like I'm sounding like a broken record, but I feel like when we empathize, we understand for ourselves into the other person's shoe, that person feels like they are being heard of when someone has interest in what you do, I think it's also a great feeling as well, where you can kind of engage with that person at that level. But when you do understand a little bit more, then you are able to be more proactive. So when you do know something more about the stakeholder, maybe you will consider that when you do something. So if you are creating a design or if you want to drive a new initiative, when you are trying to figure out how to position, like say for example, if we are trying to create a new initiative and we want to see how we could get buy-in from all these stakeholders, it is great to understand those different stakeholders and see what they are, they might be considering our thinking and productively put into your strategy things that they might probably already say. So that way, when you're presenting and trying to pitch the strategy, you're already considering them, and they won't be asking you the questions that you probably think that they'll ask you anyway. And I think that will kind of accelerate the process too. And I think over time that will also build a lot of trust. People will start trusting you more because they feel like they can they might think that you understand them more too, which I think would be great because I think trust is something that doesn't come one day. Like it's not something that's short term. I think it's a building of it's kind of this accumulation of all the different tiny things that you've done with that stakeholder builds that trust at the end of the day. So you don't need to be in sales. In theory, it makes a lot of sense as an audience listening to all these things. As everyone, I think all designers have to constantly remind themselves to be proactive and constantly manage the relationship with stakeholders, right? But I think the other thing about, you know, keeping people involved early on, I think when there are stakeholders that may not necessarily be interested or have influence, but it's a very far reaching from your position. I'm like, although I guess there's the advice that you want to keep them in the loop as early as possible, but there's always new projects, projects get defunded or postponed and deprioritized. How early is early enough is the question, right? I think I think there's two parts to that question where before even when to bring in stakeholders, I think there's also a component of who to bring in at what level of involvement. For example, there's a project management concept called the RACY model, which stands for responsible accountable, consulted and informed, which are different degrees of how involved a stakeholder should be, and it's basically a matrix where you would write down all the stakeholders and then see how much involvement they would need. So for example, if it's someone super, super high up that maybe might not be more of the vision, might be more of a visionary type of person, and then maybe if you have someone that is more in the front line, for example, agents, maybe might be more on the front line who understand kind of those operations. I think that those two people would have very different types of involvement, where maybe the agent will have better understanding of the context, whereas maybe the other person might have more of a higher level understanding, however maybe they are able to drive the strategy better. So depending on what you need, I think you bring in different people, but when you do start thinking about doing something, I think it's good to bring them in early. So for example, even when we do very ambiguous designs of let's create this, I don't know, let's create this bigger product and we don't really know where to start. I think the starting point is to figure out maybe as a designer what you need to do and then in those prospective stages, who you need to bring in. When you are in that particular stage, I would bring them in, I think personally, I like to bring people in as early as possible, maybe even just from gathering the requirements. What I would do is we would have, so maybe see if you function a little bit differently, but we have people that are really knowledgeable about the domain that we bring in and they'll kind of tell us a little bit more of the requirements that we need. But we also don't know 100% of what those requirements are when things are really ambiguous. So as a designer, I might create a first pass of a design and then have a bunch of questions and then we will do an understition and we will bring all these people back again plus people that we think might be able to help us a little bit more. So that way we're creating a product together instead of it being like, "Hey, I've done this, let me show you," and then getting an approval. So I think that may be making it the benefit of bringing in someone early is that they will be able to work with you instead of it being kind of more of this transactional relationship. However, I don't think that each stakeholder needs to be brought in that early in that depth. So depending on the stakeholder, I think you need to be able to position it a little bit differently. For example, if you've created this whole, maybe this vision of a product and you have figured out some other requirements, maybe that you bring in someone that is a little bit higher up to pitch that vision and see what they might think about it. And maybe it's not the finalized vision, but maybe the first version of it. And from there, you can kind of get that feedback to see more on a holistic level, what someone of that position might think. So I think if you understand kind of where what strengths those stakeholders have, you'll be able to see when to bring them in. If I understood your answer correctly, I think it's not necessarily as early as possible or on the first day where your project has kicked off, but rather consulting your stakeholders, depending on what their position or relationship to the projects are, consulting them early enough in order where the project is still open to feedback and is able to change. If you present to someone as a final solution and there's no wiggle room for change, I think that's when the people are surprised and has some hesitation to accepting certain solutions, whereas if you go to them and say, hey, we've been working on this for X amount of days, weeks or months. But if you ask them and say, hey, we're here for feedback and there's these things that we need your feedback on and we're willing to change the solution for. I think that's where that is the definition of early for that stakeholder. So I think that's where the caveat is for how early is too early or early enough. So does that kind of reframe fit? It's always easier to have someone work with you as opposed to trying to convince someone when it's already too fixed and too late because it also, I think, in our world of product, we do want to feel fast and we do want to pivot quickly and I think to be able to do that, we need to bring in the right people at the right time so that way we can continue to do that. I've realized that you can present the same solution to the same people, but depending on what happened prior or what you shared earlier, the room will be different, the feedback that you get will be different, right? The approval process will be different. And so I think it's not really about how good your idea is. It's about the framing of that idea, the people that you involved around those ideas and how that idea came about is as important or if not more important than what do the final solution that you come up with. So yeah, that's my takeaway. I feel like that's so true. I feel like that's so true and I feel like it's interesting because as designers, we could be presented the same prompt, but we will maybe have different outcomes, but also at the same time, we could show the same outcome and then have very different feedback based on if you've briefed someone before or how well they know about what you're doing, I feel like it changes kind of the feedback there too, that at the end of the day, it's all people that I feel like it's just managing those relationships. It's like human psychology, kind of all in one in design. Traditionally in the practice of design UX, there's a lot of emphasize that goes on craft, on ideas, you know, being creative and there is not much to be learned about how to handle the stakeholder, how to work with the people that we work with. We learn to be empathetic with our users and the people that use the product and not so much goes into that. So it's great that we had you in the show today and we want to thank you for coming and sharing your experience in that. Yeah, thank you so much for having me and I appreciate being able to be provided the place to share. Thank you so much for listening. If you enjoyed this podcast, please leave us a review on Apple podcasts, Spotify or anywhere you are listening and share it with your friends and colleagues. Don't forget to subscribe to our show to get notified when we are releasing a new episode. And if you want to learn more about the work of the design team at Agoda, visit agoda.design. Thanks again for listening and hope to see you in our next episode.