Getting alignment & building trust with our stakeholders

Our guest today is Yuiko Majima, a senior product designer at our team who works on our customer experience group internal tools, where she gets to manage different stakeholders and to work with different parts of our business.

Yuiko is here today to share with us how she manage and work with so many stakeholders and her interesting and quite unique background in sales and project management, before transitioning into design. 

Transcript

SUMMARY KEYWORDS 

stakeholders, designer, design, people, sales, product, cg, agent, clients, customer, understand, realised, create, users, learned, project management, conflict, collaborate, booked, organisation 

SPEAKERS 

Nahum, Yuiko, Yuki 

Yuiko  00:00 

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 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 everyday 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. 

Nahum 00:36 

Hello, and welcome to the design explorers 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  – all in one simple, easy-to-use platform. 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 Nahum Yamin and I will be your host for the show. Our guest today is Yuiko, a senior product designer at our team who works on our customer experience group internal tools, where she gets to manage different stakeholders and to work with different parts of our business. Yuiko is here today to share with us how she managed and work 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, Songkran, which is the Thai New Year. And it is also a time for many of us to take vacation and travel during her vacation you eco 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 and some of the insights she got from that experience. 

Yuiko  01:56 

During Songkran, I had gone to France and Portugal. And on my last day in Lisbon, I decided to to check into my flight online I was I thought, oh, I need to I need to check it. And so I 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 17. I, I thought that I booked it for the 16th because when I had originally booked my airplane, the confirmation said departure April 16. 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 travel 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 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 the 17th. So I went into our chatbot, which, which I designed or helped design. And I'm going through I'm on I'm like walking down the streets of loot lake. So let me paint you a picture. So it's like 10pm at night, we have my friend are walking down the streets of Lisbon, I just check into my flight. And I realise I've made a mistake. And then I go into our go to chat bot 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 trying 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 was great, because now I knew like what I needed to do. So I I cancelled, 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 realised 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 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 realise I kind of wrote like a diary study of it afterwards and the the plane because I wanted to make sure I remember 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 chatbot 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 travelled. So I think it was a good way to kind of understand the customer a little bit more to in the real world. 

Yuki  06:05 

That's a very interesting story. I think my Songkran was just a little bit more boring than that wasn't as eventful. So I think there's a lot to learn. And I think being in CEG, 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 be always be in the shoes of the users, right? So could you kind of walk through the audience, like your experience in CEG, and maybe what you do there? 

Yuiko  06:37 

Yeah, so So CEG stands for customer experience group, and at Agoda. 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 Agoda. So what that means in terms of product is that there's actually a bigger ecosystem of different products that create customer experience group so so when I was in Lisbon, on the Chatbot, that was like a customer trying to contact Agoda that is a touchpoint customers can go into our help centre 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, or even hotel calls, to try to solve the 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 workflow set in place for that. So So CEG 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 product side. But there's also a bigger business unit. That's kind of an of its own its own little organisation 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 the customer experience group. And as a designer, it's really interesting because not only do you create products, but you've created products for different types of users, as well as collaborating with a lot of different stakeholders as well. 

Yuki  09:09 

And today's episode is about stakeholder management. Right? And I think last we talked 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 CEG designer and how it has helped you in your current position. 

Yuiko  09:33 

Yeah, so I I never thought I would be a designer. I am 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 fibre in Japan and that's kind of how I started my career. And in sales. I learned a lot of things but I'm We have since it's b2b, it's our clients, our longer term enterprise clients. So maintaining good relationships was a key to, to getting those deals and making our product 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 was 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 CEG designer, because it is there are obviously visual elements to but it is also heavily UX, and domain driven. And there are, I think, I mean, I think I know maybe 1% of what all what it is to know about CEG. It's a very complicated area. But there's a lot of different people who are experts of their area. And so as a CEG 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 this cohesive ecosystem of different types of suites 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 realise how they would be beneficial to me, I think, looking back, I realised that some of those dots kind of connect, were in sales. I think there's a lot of transferable skills like, like facilitation and presentation, time management, and stakeholder management. And I think the stakeholder management part is something that I I'm really glad that I learned because it's something that I feel like is, is something I do every day today. And it's 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, here we are. 

Nahum 13:00 

Maybe you can give us like, you know, some examples of some of the skills that you picked up with your experience and what you learned from sales and project management, how they come into play in design, and what what exactly these skills. 

Yuiko  13:13 

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, 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, my 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, what kinds of, of things they needed for that particular project. But also they were able to connect on a human level to where, where I feel like the colleagues and managers I worked with were really good at trying to, you know, look up current events of the company, they're there, the clients ought to bring up some conversation or they would ask questions about the person's interests, and they would remember all of that information. So the next time they do come and meet the client again, they're able to to have these talking points that they could talk about and connect with the client more. So I think that taught me but 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 in CEG, a lot of our projects are, 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, 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 to have of what each 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, 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 would, will make a huge difference and how you are able to collaborate. And I think at the end of the day, it will show in the products that you create, and how you innovate, that at the end of the day, I feel like we're all humans and, and design is very human centric, that also our the way we collaborate, I think also has to be in a way in like a similar way. Where where we were we understand each of the stakeholders, own challenges. And the differences too, I think they are our 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 to build trust over time and cultivate those relationships was something that I I learned and I still use today, 

Yuki  17:22 

moving from a different industry coming in to travel, have you felt any differences in stakeholder management and how you might, I guess, go about your way managing stakeholders expectations at Agoda, compared to your previous experiences? 

Yuiko  17:40 

Yeah, so 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, those are very different environments, where we're sales, you know, it's really dependent on the client. Agency, it's a little bit more short term projects and clients specific. I think Agoda is 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 as a product organisation, we aim to, 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 to where, without a business, we don't have a product to create flow without the without users, we don't have a product to make either. So I think that there's there needs to be a good balance between the two. So I but 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 empathising with the stakeholder trying to understand where they're coming from, I think is something that is same for for any environment, I think, because at Agoda, we are an in house product, or I think one thing that might be different is that we can bring these stakeholders really early on in the, in the design journey, like instead of, maybe at an agency, you you need to show something more polished, but but Agoda I feel like I mean, I create draft designs and send them out and see what happens all the time. And I think it it's great because it allows us to collaborate earlier on and and kind of build something together as opposed to end of having something more siloed where design will design and then handed 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 for CG, 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, 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 

Nahum 20:37 

stakeholder management at the end of the day is working with people like you mentioned, you have different backgrounds, different perspective. And because of that sometimes you could have maybe conflicts or challenges working with other people. How do you manage that? 

Yuiko  20:50 

Yeah, I think I think it's I think we will always have conflict. I don't think that it is 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 approached 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, too. I think though, that while individually, we might have different goals and different challenges and different limitations. At the end of the day, though, 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 CEG design, 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 we and when we did the exercise is true, like a lot of the stuff that we see in those individual stickies are very different. But when we went back, and synthesise, 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 to of what you are trying to achieve and why you think maybe this is a conflict. And then if you could map it, 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 too. 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 if even when, 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, 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 to not only account for some of that limitation, but also provide a better experience for the user. And I think if you can frame it in that way. It it would it would also make the stakeholders feel like they 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 of the entire domain. 

Yuki  24:47 

It's actually catching me by surprise in terms of like the impacts that it could have. Right. I think the end result is to come up with a solution that tries to satisfy as the stakeholder as much as possible. Hopefully, that's a win win. But a lot of times there are trade offs that needed that needs to be made. And when are there there are those trade offs that needs 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 organisation. I think you have an 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? 

Yuiko  26:10 

Yeah, I think that, um, I mean, honestly, I was just lucky to be 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 productive. And if we could be more productive, 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 empathise, we understand, put ourselves into the other person's shoe, that person feels like they they are being heard. When someone you know, when someone has interested in what you do, I think that's also a great feeling as well, where where you can kind of engage with that person at that level. But when you do understand a little bit more than you are able to be more productive. So so when you do know something more about the stakeholder, maybe you will consider that when you when you do something. So if you if you are creating a design, or if you want to drive a new initiative, when you are when you're 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 can get buy in from all the stakeholders, it is great to and understand those different stakeholders and see what they are, they might be considering or thinking and proactively 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, and they they won't be asking you the questions that you you've 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 can, they might think that you understand them more to you, which I think would 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, 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 everyday 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. So you don't need to be in sales. 

Yuki  29:08 

The practicality of doing this, I think, 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 influenced but it's very far reaching from your position. Like, although, I guess there's 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 deprioritize. Like how early is a is early enough? As a question, right? Like, 

Yuiko  30:01 

I think that I think there's two parts to that question where before even like, when to bring in stakeholders, I think there's also a component of who to bring in at what level of involvement. So for example, there's like a project management concept called the RACI model, which stands for responsible, accountable, consulted and informed, which has 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 might be more of like, the vision might be more of a visionary type of person. And then maybe if you have someone that is more in the frontline, for example, like agents, maybe might be more on the frontline who understand kind of those operations, I think that those two people will 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 higher level understanding, however, maybe they are able to drive the strategy better. So So depending on what, what you need, I think you bring in different people. But when you do start thinking about, like doing something, I think it's, it's good to bring them in early. So for example, even when we do very ambiguous designs of, of let's create this, I don't know, let's create this, this bigger product, and we don't really know where to start, I think the starting point is trying to figure out maybe as a designer, like what you need to do, and then in those prospective stages, who you need to bring in. And 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 CEG functions a little bit differently, but we have people that are 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 when things are really ambiguous. So 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 another session. 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 as 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 in that in that depth. So depending on the stakeholder, I think you need to be able to position it a little bit differently. So for example, if you've created this whole, like maybe this, this, I don't know, like this vision of a product product, and you have kind of figured out some other requirements, maybe then 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 finalised, like finalised vision, but maybe a first phase first version of it. And from there, you can kind of get that feedback to see more on a more on a holistic level what someone of that position may think. So I think if you understand kind of where what strengths those stakeholders have, you'll be able to see like when to bring them in. 

Yuki  33:50 

If I understood your answer correctly, I think it's not necessarily like as early as possible or like 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, right? If you you present to someone as a final solution, and there is 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 said like, Hey, we've been working on this for x amount of days, weeks or months, but if you ask them and say like, 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, that's where the caveat is for how early is too early or early enough. So does that kind of reframe fit? 

Yuiko  35:01 

it's always easier to, to have someone work with you, as opposed to trying to convince someone when it's already too, too fixed and too late. Because it. And also, I think, in our, in our world of product, we do want to fail 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. 

 Yuki  35:30 

I've realised that you can present the same solution to the same people. But depending on what happened prior, or what you shared earlier, like 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 are involved around those ideas and how that idea came about is, is as important or if not more important than what you the final solution that you come up with. Right? So yeah, that's, that's my takeaway. 

 Yuiko  36:09 

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, how well they know about, about what you're doing. I feel like it changes kind of the feedback there too, that at the end of the day, I tell people that I feel like it's, it's just, it's just managing those relationships. It's like human psychology, kind of all in one, in design. 

 Nahum 36:51 

Traditionally, in the practice of design UX, there's a lot of emphasise 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 we learn to be empathetic with our users and the people that use the products and not so much goes into that. So, you know, it's great that we had you on the show today. And we want to thank you for coming and sharing your experience in that. 

 Yuiko  37:16 

Yeah, thank you so much for having me and I appreciate being able to be provided the place to share. 

 Nahum 37:22 

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 agora, visit Agoda Dot Design designed Thanks again for listening and hope to see you in our next episode.