Mauricio, Vivien & Lisa: Inside the minds of GetYourGuide’s Product Team

When we design something, we can do all of the preparation work in the world, but like in the end we're just guessing, right? And we're not really going to know how something is going to work until we put in front of real users. Hello, I'm your host Liam and you're listening to Behind the Journey. On this show, we dive deep into the world of Get Your Guide by chatting with our leaders, innovators about their stories, ideas and strategies. If you're new here, Get Your Guide is a market leading app dedicated to connecting millions of travelers with unforgettable experiences around the world. Ready to start a new career journey and shape the future of travel, visit GetYourGuide.Carriees. Now, today's episode is very special because we have not one, not two, but three guests from our product team on the show. So I'd like to welcome Mauricio Gambola, Vivian Pele and Lisa Marillini. One welcome to you all. Let's start with just a short introduction to you and to your roles. Hello, so I'm Mauricio and I'm an engineering manager here. Hey, I'm Lisa and I'm a product designer. And I'm Vivian and I'm a product manager. Thank you so much and welcome. So you might wonder why do we have three guests today? Well, because we really wanted to get into how this trio of product disciplines works together to make Get Your Guide a leader in the travel experiences market. If you're interested in product management, design or engineering, this is a great opportunity to gain real insight into how we do things here. So without further ado, let's get into it. So we thought the best way to understand how all of you work together is to explore the journey first of a new product idea. So we broke it down into four stages, a strategy, discovery, execution and evaluation. So let's find out how each of your roles acted into that process and where your responsibility is over. So Vivian, we're kicking off with you. Can you just tell us a little bit more about your role as a product manager and how it all begins in the strategy stage? Yeah, great question. So here it's important to say that no two strategies are alike. We always varied up a little bit, but in general strategy has this kind of basic skeleton. Everything starts with the company strategy and the company mission. That's generally how we evaluate our overall direction and that tends to be defined annually. And from there we can kind of distill like the rough direction that we want to go into. And if there is one particular aspect that we want to focus on, we start trying to really clearly and ruthlessly focus on designing the customer problem. We do things like collecting insights. We might kick off a bit of research, collect context with our stakeholders, all that sort of thing. And once we've really clearly defined the customer problem or customer problems, it's a good point to start defining like what does success look like? What do we want to accomplish? And this can be anything from defining a success metric, some milestone that we want to reach. Or what we like to do is also just define what we want the user experience to feel like to look like. And there's a number of exercises that we can do to really have a clear picture of that. From there we've collected our insights, we know what the customer problem is, we know what success look like. What we do then is also define a clear leading hypothesis. What is the overall idea that we want to, what is the action that we want to take on this problem? And what does that look like in the form of a product or feature that we want to launch? And at this point also with our team's help, we'll have kind of laid out a couple of idea variants and it can be anything from like the color of a button should look different or the placement should look different. All the way to we want to test this completely different design pattern from another one. And I think another step that's really important here is defining an overall approach. Like okay, we've got our ideas that we want to test. And probably the first one that we're going to do is that we're going to test is not going to be the right one. So we want to make sure that we're like defining what learnings we want to achieve with step of this strategy and implement certain kind of checkpoints where we say, hey, did we learn what we wanted to learn? Did we achieve what we wanted to achieve with this particular variant? If yes, let's keep going. If no, do we need to kill this or do we do we go in a kind of slightly different direction? The defining these steps like way ahead of time is super important because otherwise you're just going to kind of wander around aimlessly and circle the drain and never really get to where you want to get to. And then the last thing I'll say about this is that there's a lot of socializing that happens at every step of the way. So this is not something that happens with just me, the product manager kind of working in a room and writing a document and then hoping that everybody agrees with me. I throughout every step of the way I'm working with Lisa and Mao and engineers and stakeholders and leaders to make sure that all of the perspectives are shared and that we're leveraging everybody's expertise. Amazing. Thanks for being over to you then Lisa. When product designers get involved, how are you turning those ideas into reality? I want to start by saying product design is always involved in the process. So as we've mentioned, you'll keep people in the loop as he's discussing the strategy. He'll of course keep me informed, asked for my import, the workshop ideas with me along the way and others on the team as well. So when it's kind of my time to shine, I've already been immersed in the problem space in the strategy. As for what happens within the official design stage, as one may say, there's not really one size fits all process for this. So every customer problem or idea we focus on is different. Some small, some large, some are very well understood and with very clear solutions and others are a complete mystery. So my job is really to bring toolbox, assess the situation and kind of choose the right steps in order to turn that unknown into some more actionable clarity. So this means first, if it's not already completely understood throughout the strategy phases, to understand the problem is assess that existing knowledge, the data, the research, chatting with the UX researcher and also trying to build empathy across the team in this stage, so involving them in some of these discussions. Using this as a base, then understanding all the potential solutions. So ideating workshops, competitive analyses, mapping the user journey, and often we also included in much longer term vision projects. So we'll be thinking what does this look like? Not just now, but three to six to 12 months. And what does the UX feel like? What does the user flow feel like in the perfect case? Then of course, if we're thinking that large, we need to try and break it down into a solution that we can test. And this is also with BIVS help. He'll often do this through the strategy phase, but we may also do this in design of, okay, well, what is the easiest design solution that we can put forward? Is it easy enough to build something that may not be the perfect UX, but we'll test the hypothesis. And then how do we go from there as well once we are more confident? I refine it, I refine the interaction, the edge cases, considering how this looks and feels within our branding and existing experience, and create prototypes so that we can show the engineers what this will look like, often looking at how it feels in my hand. If we're talking about the app, I'll try and do a Figma prototype and just play with it. It's a lot of gut feel. And I try and evolve the engineers as well. I give them some insight into the upcoming work, even longer term vision, so they can start to think about it, how they'll implement it, trying to light on some of the complexities in my process and some of the things that they may need to consider when they're building this. And ideas, we discuss ideas on like simple ways to execute. So they may come to me and say, this is very complex even though it may not look it. And then we have that open discussion. So that helps shape the design and what we can get out in the first iteration. So these conversations then obviously continue throughout the development phase as they start to discover or complexity. Great. Thank you so much. So now let's bring you in Mauricio. So what's your process in engineering to get a new product over the finish line? Yeah, that's a great question. And I'd like to add that it's just not like a hand off, right? Like it's not that beef hands off everything that he does to Lisa and then she does her thing and then she hands it over to engineering. It's not like that, right? Usually the way it works is there's an engineer involved since we're having the strategy conversations. So they work with product with beef in this case with the product manager kind of like, okay, yeah, this is possible. This is not. We expect them also to contribute to shape the feature, right? What it's going to look like while we're building. They then also work with Lisa. Lisa comes with these amazing ideas, but that's the ideal case scenario, but that's usually not what we end up building, right? Because we have time constraints or maybe it's not visible from the engineering point of view at that moment, because I don't know, maybe we need to work with another team to unblock us or so or whatnot. So we work together kind of like building that MVP. That's the first iteration of an experiment or a feature that we want to put out there. Maybe just to start getting learnings, right? So I just wanted to add that engineering is involved since the beginning. And the way we usually now like start building something is there's a tech lead, an engineer in the team that is assigned to a specific feature experiment, etc. And then like I said, they start working with this too, I mean with beef and Lisa. And once we know what it's going to look like they do that, let's say, a little bit boring part, which is like creating tickets in JIRA. Okay. And not of that. But they also need to kind of like involve the other engineers in the team, the tech lead. I mean, they need to involve the other engineers in the team, kind of like, okay, this is what I'm thinking about. Terms of the technical approach so they can get also the feedback from the other team members and together start shaping it. And then we do spring planning and this is like, Veef and I usually agree, hey, this spring, this is what we want to do. Based on, you know, we have like goal number one of the spring, goal number two and so on, based on our capacity. And then, yeah, we just start working on it. And that's when once we finish the experiment, the feature, we launch it. And then the experiment runs and that's when the analysis part comes, which is, I guess, the next thing we're going to discuss. Yeah, that's incredible. Thank you so much. So once all that's done, and obviously there's a lot that's going into that, but then let's talk about the evaluation stage of Veef. So how do you measure the success of a product as a product manager? Yeah. So there's two answers to that. Two speeds by which we evaluate our program. There is evaluating the thing that we just shift, whether that's like the experiment on a feature or some milestone that we just reached. And then there's also kind of evaluating the overall strategy that we're betting on this quarter or year or whatever. So with that first part, when we ship something, you might have already picked up on this, we launch 99% of things under an A/B test. Yeah. And the reason for that is that when we design something, we can do all of the preparation work in the world, but like in the end, we're just guessing. Right. So that's why by design, we like to really just experiment with things pretty rigorously. And when we design an A/B test, we define some sort of metric or metrics that we want to affect. So I reflect some sort of customer behavior that we want to change. And then we also have a bunch of kind of learning goals that we want to have for this particular iteration or experiment. And we launch it, the experiment runs for a little bit, and then we've got some time where we can understand the results and deep dive into it. Here what's important to say is that we, even if we like positively moved our target metric, we don't necessarily just kind of blindly launch it to everybody because there's always going to be some sort of learning behind that movement. And so we have an awesome data analyst, Ashton, who's not in the room right now, unfortunately. But he supports us with a deep dive analysis where we really try to understand what's going on. Like we rip apart the experiment and we try to see, well, maybe there was uplift in some conversion metric that we're targeting. But are we sure that is real? Are we sure that we didn't break something else and that resulted in, I don't know, like a faster way to get to some button and then that resulted in higher conversion. So it's really important to break that down. And then I mentioned two speeds earlier. The second speed is about taking a step back and making sure that we're on track with our strategy and checking in with ourselves and saying, hey, we've launched three experiments or four experiments in this direction. Did we learn what we wanted to learn? Should we keep going? Should we change the direction a little bit? Should we stop? I mentioned my first answer. We have this like checkpoint framework. This is why this is really important to have this defined. Ahead of time so that we're not running in circles. Yeah, and maybe one other thing that I'll add here is the fun challenge that we have to deal with is this tension between a codified quantitative metric, let's say conversion rate or whatever. And then what it is that we're trying to solve, right? What is the customer problem? Because in the end, a metric is really just a translation of some customer behavior that we want to have. And it's never going to be perfect. And I think this is true of almost any product team in tech. We struggle with this sort of, do we want to just move this metric? Or do we want to make sure that we're optimizing towards the customer behavior that we want to affect? So it's really important here that we work with Ashenar data analysts to really make sure that we're defining the experiment correctly, that we're not getting lost in this like, oh, we just like move this metric and now it's successful. We can bank the win and then move on, right? The definition of the target metric, the design of the experiment, like we can't just put that on autopilot. It's really important that we're very intentional about it. Yeah. Great. Thank you so much. All of you for the insights. So Lisa, we'll come back to you. Can you maybe give us an example of an exciting project, either something you've worked on in the past, something that's ongoing now, and how you maintain strong communication across all these different disciplines that you're working with? Yeah. Of course. I'm saying very exciting right now, but I can't give too much away. Perfect. The problem we have currently is that it's quite complex to try and design for the perfect discovery experience for all locations around the world. The world is a very complex place. For example, New York is very different to Hawaii or Niagara Falls, and so users have very different needs when they're planning trips to these different destinations. Our amazing research team, as well as data analytics, have helped us by collecting great insights about the problems that users do face in these different circumstances. And we've held knowledge showing sessions with them and our team, engineers, and ideation workshops involving people from all disciplines and other teams to help build empathy and also get a range of perspectives on this problem. So the strategy has been also presented and scrutinized by many stakeholders. So Viv has had to be on the hot seat and really get everything dissected so that we know that we're on the right path and solving the right problems and that we've got some clear thinking and some good ideas there. We still have some unknowns about the user problem and the overall opportunity. So we've created a game plan on how to gain more certainty. So that means just last week we had a session Viv, Mal, the lead engineer, and I. And we really broke down every single feature, every interaction, and prioritized it based on the value to the user, the ability to gain learnings, and the engineering effort involved. So our user flow and our wireframes have been created through this united approach where we all work together. It's not like I went to a room and just generated something. We really work together on what this MVP is going to be. So the solution is still a complex one even through all of this and through narrowing it really down. So I know we will uncover some hurdles in the next few weeks as we start to work on this, especially as engineers start to uncover some technical limitations. But we've got a very clear goal and a very clear strategy. So I think it's easy for us to discuss this as we go and make decisions and compromises on the fly. So we're definitely used to navigating with agility with these types of things. And if you're traveling to the Grand Canyon or to Hawaii or to Tuscany anytime in the next couple of months, look up for something new and shiny and exciting. Amazing. I look forward to it. So just about to you very quickly, if you could describe your trio in three dynamic words, what three words would you pick? It's hard and I guess although I am the creative one, maybe the first thing that comes to mind is not the most creative and maybe a little bit lame. But I just mentioned agility. Yeah. Okay. And then I could also say bridges and curiosity. Playing into our "Get Your Guide" principles there. Nice, nice, nice, nice, nice, great, yeah. So Mal, to come back to you again as well, what's one fun or unexpected thing that you have learned about your teammates and are there any maybe common misconceptions about your roles that you'd like to debunk? Yeah, about misconceptions. I think I already mentioned this a little bit, right? And misconception is that while product is or beef in this case works isolated, trying to figure out what to build and then he hands that over to Lisa and then she does her thing, then she hands it over to me, right? I think that's a misconception. We all work together in the team, including not just myself as an engineering manager, but also the engineers in the team. The data analysts, we have also a content designer, etc. Everyone kind of lay okay, working together these experiments on these features, right? I think another fun misconception is that product managers are just project managers and creating things in Gira and that's it and telling the engineers what to do. And the product designers are just here to make things look pretty, right? That's not really their job. It's part of it, but not the main one. So yeah, I would like to debunk those misconceptions. Right. You so much. So we have a tradition on the podcast to end with a subject that we love the most, which is unforgettable travel experiences obviously. So let's start with you. If what's your most memorable travel experience? Yeah, I think generally speaking, my best travel experiences are the ones in which I'm the most uncomfortable as they're happy, and it almost feels like pain, but that it's just like you look back on it and it's everything just sort of lights up in your memory and it becomes this like wonderful fun experience in retrospect. And for me, that was traveling to this region of India called Ladakh. It was about 10 years ago, some friends and I did a 10 day trek through the mountains. It was supremely challenging. I didn't know that I was actually going to make it through. I thought we were going to turn back a bunch of times, but the reward was immense. I mean, these incredible, if it does, these wonderful, hospitable people and also just like really great bonding experiences with some friends that I still maintain to this day. Amazing. So how about you, Lisa? This is a tough one. I have done over 90 get your guide experiences in the last four years. So really hard to pick one, but I think one that really just like sticks in my memory, I guess it's because it put me outside of my comfort zone. Just like Viv was talking about is skydiving over Rotnest Island. So Rotnest Island is a little island off the coast of Perth, that's my hometown. So this New Year's Eve, when we went back home, am I partner and I then decided that we would skydive. And we got to get to the island. There's these adorable little animals called Quaccos. Yeah, you should Google them. They always let us miling. And yeah, we got to fly up in a plane, see the entire island from above as well as the coastline of Western Australia. And then of course jump out. And it was uncomfortable with the flapping face, but then as you get to glide down more gently, it was amazing. Most amazing views couldn't replicate anywhere else. No, that sounds amazing. I did one in like Taupeau in New Zealand in 2003 and it was just unbelievable. I'm not sure what to do again now, but back there was a bit more of, maybe a bit more adventurous. Last but not least, well. Well, I'm going to stay in Europe. My favourite trip ever, I think it was like to the Lafote in Ireland in Norway. No, nice. It was weird because even though it felt like a different planet, like the scenery is like out of this world really beautiful, it kind of also reminded me of the Caribbean and I'm from Costa Rica. So it felt familiar in a way. It was like, you know, the beaches with like white sand and blue water. So yeah, it felt like back home a little bit. It just that I couldn't take a swim because the water was like freezing cold. Like, it felt so beautiful and it felt familiar yet also out of this world. Sounds awesome. Well, thank you all so much for sharing your time and your insights as well. Discover more behind the journey episodes on all major streaming platforms and explore how get your guide is transforming the travel experience industry.