Collaborating as Product Manager & Designer - with Yoav & Tudor @ParkNow

Welcome everyone. Hi Christian. Hi Alex. Today we finally made it and we talked to a duo. We had Yoav Farbi and Tudor Teixanou here as guests and the beautiful thing is that even in their natural habitat they are working together as a product designer and product manager and forming a team and that's the topic of today. We covered topics such as design collaboration and product management collaboration as well as making decisions together as a product manager and designer and next to that also we deep dived into certain processes like design sprints and how to share feedback between each other and make sure that the communication is always granted for a good collaboration. What was your main key takeaway Alex? I think whenever a designer talks about trust that's when my heart starts beating faster. I think there is nothing more important than the trust in different functions and from different functions if you want to be successful in the organization. Yeah, without sharing too much. Keep your heart rate low and make sure to look into the link description because this time we have added a feedback form where you can share with us how you like the episode and also tell us what we eventually can do better or what we should talk about next time. Like in the good old NPS times and besides that as usual go to product-bakery.com you will find all our episodes there with some podcast minutes as well as a transcription of the first part. And follow us on social media so let's get started. Hi Tudor, hi Joachim, it's nice having you. Finally an episode with the counterpart in form of a designer and a product manager because I'm pretty sure our audience is sick of hearing Alex and my point of view and we thought okay after almost 50 episodes it's time to invite people who know what they're talking about so it's nice having you guys. Thanks very much for having us. Thanks for inviting us. It wouldn't be Product Bakery if we wouldn't try to get different perspectives to product so having you both here is a pleasure and we're happy that we finally managed to get a duo on this call. Absolutely. So as always we start with a short introduction. So you are in product management since a while. You have founded a couple of companies where you always worked as the leading head of product. You also worked for a while as a senior data analyst and besides that you worked for several companies as product manager, as product lead and these days you are working as senior product manager for the company ParkNow. Yes that's correct. All right so after Joachim asked the designer in this round it's my pleasure to also introduce Tudor and Tudor studied on the faculty of engineering where he was doing interaction design and I think it's a pretty nice combination because it combines the engineering aspect as well as the design field, design thinking, human-centered methods and after that you're actually always in the function of design between UX interaction designer. You saw a lot of the word from what I can see. He went from Denmark to Turkey to Romania and now you are in Netherlands at ParkMobile. So maybe back to you guys. What is ParkNow and what is ParkMobile all about? So ParkNow is a parking solution provider for both B2C and B2B so individual drivers and businesses. Under ParkNow there's several brands. So we've got ParkNow that is mainly in Germany, ParkMobile is the main brand in the Netherlands and Ringo is the main brand in the UK. So all these brands operate under the same company all offering very similar parking solutions. Okay it is not as complex as I thought when I heard the two different names. So that means Tudor and you're working together and I would love to hear from you guys. So how does a day for you guys look like collaborating as the product manager and designer twin pair together? So it always starts with lots of Slack messages on a daily basis and what we make sure is we have a weekly cadence looking at the actual work the scrum team is going to work on in the short term and then do more long-term discovery involving the right stakeholders including tech, design, product and whoever the expert we need. That's a very simple summary. Tudor do you want to add anything? Yeah so adding to that is maybe the fact that we're replacing the desk checks with Slack messages again or usually not emails. We're both not big fans of email but if there's any doubt or if there are any ideas or if there are any concerns about what we do and the direction we go in then we always try to talk. It's usually on Slack or having a quick call. So I wouldn't say that's part of the daily work but I think it happens almost every other day or once every three days or something like that that we have a small chat about what's happening and what ideas we come up with and how we move on. So are you friends? Do you like each other? I can say yes. I mean it's like putting you on the spot. It's the opposite from you and me Alex. Do you want to hang out on a Friday evening? Yeah we're hanging out on a Friday evening. Doing a podcast. Okay cool that sounds amazing. What I'm hearing is also that a bit like with Corona and so on you had to readjust and moving the desk chats into the virtual space and communicating via Slack and calls, right? Definitely. And maybe also to better understand the overall setup of the teams. Assuming you work in cross-functional teams can you maybe explain us a little bit like who else sits with you in the teams? So there's myself as product manager, Tudor as designer, there's a product owner. So Parf now splits the role between product manager and product owner. So I'm the product manager and product owner. Then there's a technical architect, so someone with really high level expertise. And then there's the Scrum team which includes backend, frontend developers, QA. And then alongside that we have what we call a V Team. So that's a different expertise from the business, so marketing, operations, looking at other aspects of product, but we meet on different cadences. And Tudor, how do you work together with UAF? Is it like at the moment that you are right now preparing designs or what's currently the biggest thing to solve? So since we're not that too many designers, honestly, we're growing, but we're not that many, I have to work with multiple PMs and multiple of these cross-functional teams. So I have to shift focus most of the time. But what I try to do going back to the question is make sure that I get to define whatever problem we're talking about with UAF, make sure that we can go through some of the latest data we saw and then eventually end up with actual designs and then ideas and get some feedback on the business and the vision and this whole V Team that UAF is interacting with more than I do. And what would you guys say, what's like the key also for a successful collaboration between product manager and product designers? So what I found really useful is that as a designer, I shouldn't stick with a design or with an idea for too long by myself. So I shouldn't be, even though I work with multiple managers, I shouldn't just get an idea or a vision from UAF and then look at it for a week or two and focus on it and make it huge, create prototypes, create designs, create journeys, link it to data and then go back with this huge amount of ideas back to UAF saying, where do we go? Based on his input. What I find it's way more useful is to get these more often checks every few days. I think we should go that direction or this direction and start shifting the conversation from, is this design good to, is this the experience we want to build in the end or not? Yeah, to add just, it's a nice way of working. It's a way that it's far more collaborative and again, it's not just me making the decision. What we, what I try and do is to get, again, this discovery core team of tech design and product. So it's myself, the PO that we work with, the technical architect, always coming in, looking at the designs as early as possible. Like as soon as we have something, so it's not, should it has a design, we need to deliver it tomorrow. That will be a bad situation. And what we do by having this constant communication as a group of four is to avoid that. Oh, we need that tomorrow. And giving the rest of the scrum team as much time to digest the ideas that are coming in the next sprints. Is my feeling right that I'm hearing out a little bit of design thinking at ParkNow? You're hearing an attempt of design thinking, yes. Can you elaborate more? So I wouldn't say that we follow the textbook or we can even call it design thinking as it is right now, but we're definitely trying to get ahead of development and of having a solution in our minds as a company and going that way and going ahead as in how can we find out what's the actual problem? Where can we go to figure out whether that's the problem or not? Is it in the data we have? Is it in the field? Going and see how people part and then going back and then get the experts. I think we're moving that way, but we're trying to make it in a natural sort of process instead of, hey guys, this is design thinking. Right now we should stop what we're doing. We should start empathizing, defining, and then building it. Yeah, I agree. And something that Tudor mentioned that is also really important, especially in last months and weeks for me, is the aspect of data. So we're now starting to get more data on the features that we're working with together. So that's also very helpful in order for decision making, for understanding how users are reacting to things that we're releasing and having help from data analysts or data insight teams. That's also really helpful in this discussion of who are the experts around the product. Very nice. And when it comes to the data that you're using, what data are you looking at? What is important for decisions around the product and design? So we're using app analytics. So we have an app analytics platform that looks at how users interact with the features that we are looking at. And it depends on the question. We try and make sure the data is there to some extent, or when we build a feature, what is the core question you have? If we build this feature, will users transact more with this feature? And then during that discussion, we say, okay, one of the things the tech team needs to make sure is this feature, there's a funnel that can say interaction with the feature, two more transactions per user. So hopefully if we do our job well, we're asking the questions before the feature is built. So when the feature is built, the data is there to be collected and for us to analyze like, hey, did we succeed? Did we not succeed? I would be curious about the process between getting the initial data and building the feature. So how are you approaching the feature preparation, so to say, and feature planning? So what we do when we look at the data, we want to see if, let's say, are you going back to the transaction example. We want to see if the feature does or doesn't increase transaction rate per user. So does a user go and park more with the feature that we introduced? And then we say, we also want to look at how much has it influenced? Is it 1%? Is it 100% change in that? And that defines the success. And what we want to do is to look at how we move that, let's say 1% that we observe to a 2%, to a 3%. These are just numbers to make a simple example. And then when, what Tudor does, and it's really helpful is to say, let's do some designs and do some qualitative testing. So do some real user research, get that back, see if that may influence the data from the quantitative, and then bring that back to let's build test and get the data in as early as possible. Is this then happening in form of a workshop or how do you approach that? It's in separate steps. So for now, there's a step of together as a discovery team, we like, what are the key business questions we have? Get insights from data insight, get input from the V-team. So these market operation experts come back, see what we can do from a technical perspective. Can this be built on time in the timely fashion? And then see what we can release, what the expectation on the data change is. So it's not, the simple answer is it's not a workshop. It's stages. I would not put it in a workshop personally. I think it's, there needs thinking time in between meetings, so to say, like you have a discussion, this is the most important thing for the business. Okay. How does that mean? What does that mean in the data? Let's have a think about it. Let's scratch things around on a virtual board and then come back to the business people to say, Hey, this is how we can influence business. I think there, especially when you touch the topic of design thinking, it rapidly goes into the direction of design sprints and having these workshops and having full week blocked out. One thing that you brought up, and I think this makes a lot of sense, is the fact that you need thinking time. And if you say you have a problem, you start exploring also a little bit more. Often, when I look at design sprints, also with a lot of the preparation that goes into in terms of getting the experts ready, getting lightning talks ready, getting the information prepared so that everyone is like really set up for success also takes a lot of time. So I think if you manage to include it in your normal day-to-day process and in the overall product development process, so that you still look at this, I think this can be a very sustainable approach. Maybe in the direction of YouTube or as a designer, before you go out and get qualitative feedback, what are the things that you need from product to start doing the discovery? Yeah, so in the beginning, it sounds very, very cute. A while ago, we used to test just by showing different pictures, different images and designs that we thought made sense. And then what I see changing now is that we actually think of all these different ideas and then we try to create more high-fidelity prototypes that move around and change to get really precise answers. But in order to build those, what I usually need from you all or from this team of experts, it's first of all, specific things like how much time do we have in general? I don't want to start thinking about ideas without knowing that they will never get built within the timeframe and the budget and team capacity and so on that we have. So that's not that I'm blocking myself into thinking out of the box, so to say, but I still need to be realistic since we work for a company that needs to make money. So that's one of the main things I need. The second thing, is there anything specific within the group of users that we look at? So parking is available to pretty much everyone that has a driver's license, right? But that includes people that are 18 years old to people that are 60 years old. It could be people who live in the countryside, people who commute, so it can be really different use cases. So I need to know beforehand whether I should look into a more specific group of people, maybe because we have more data from other sources about the other group of people. So maybe I have to look at people between 50 and 60 years old, let's say, because we're looking into more accessibility related things. So those two things are at least what I need. And do you feel like you usually get all of these things? The first part I do, I get more of it because I actually get experts in the room saying technically that whatever is possible in a short or long timeframe, I do get the business input, as in this is maybe a direction we want to go to or not. The part about data and people and who are we looking at is still a bit vague at the moment. That's still a challenge, as in right now we're still looking at everybody as a whole almost, as in parking for everyone. So we try to get a representative sample in whatever study, but that's really difficult when you have a sample of millions of people, when your population is basically billions of people. I can imagine that it will get better the more stuff you build, because you can then sit down and better define what are the right KPIs to track. How do you guys sit together? I think also from a design perspective, it usually starts with the question why, as far as I have heard. So I would be curious to hear how do you sit down and discuss or define what needs to be measured and tracked? I think it starts from the business questions that either I come with is like, I have this question, like, are we doing the right thing or how are users reacting to features that we're releasing? Or comes from the business being like, Hey, can you prove that your features are doing X, Y, Z? And then for example, and then we come and say, this is the problem. I have a discussion between at least tech products design, and then have, let's say, Tudor go away and do thinking about the design ideas. Someone from tech say like, Oh, I'll go and research what is possible, what is impossible. Like an example, Tudor came back recently with designs that solve two different problems on a feature update. And together we were having the discussion to make the decision on do we want to solve problem A or problem B, even though Tudor comes from his great work is, Hey, we can solve either problem. It'll be difficult to solve, but how do we make that decision? It's a group effort in the discovery process. And how did you pick, like in that specific example, what was the outcome then? How did you pick it? So the option that we picked was the most doable option from a technical perspective. I think it was one of the options that was really, it was a really cool option. From a tech perspective, it would have been very expensive to build. And so that was a really relatively easy decision to make of like, Hey, we want to, we want to iterate relatively quickly. If this is a really expensive thing from a tech perspective, maybe we shouldn't do it yet and solve problem B. And then we can come back to problem A in different ways. How did you feel about this decision, Tudor? Well, fortunately this time it aligned with what I saw in research as well. As in the first problem that we actually picked to solve, where it was the bigger one that people showed more interest in, and then they reacted more positively to the solution I came up with during the research and the usability study. So in this case, it was fine to postpone it to because of technical, postpone the second one because of technical reasons. Yeah, I love it. When Christian asked the question, I actually had to think about, Tudor, you wrote an article and it's super fitting. How to deal with designers. And I think it's very sarcastic. It talks about always compromising on the work until the next iteration. So yeah, it's a little bit like the nightmare of a designer. But at the end, what it comes down to is the designer obviously also needs the business understanding. And if you as a designer see, okay, this is like what we can deliver technically, and this is the time and the effort and the involvement is there and the collaboration is there. It also makes it easier as a designer to take the decision. How do you see that? Yeah. And one thing that to build on that, one thing that really helps me now is to understand that, okay, we have two issues, two problems or more, but it's maybe actually better to solve one, implement the one, make sure that all the measurements are there, figure out what happens when you implement that problem and how people react to it in production, and then see how you build on top of it with the second one. Having both of them at the same time might cause, you might have other variables at play that you weren't really thinking of because the study was qualitative at the end. The moment you bring it even into a beta program in an app, it becomes huge. Like you have tens of thousands of people using it and it might be slightly different from what I saw in the research. So that's something I'm actually seeing as being useful as long as we don't fully compromise on even the solution itself. That would be interesting for me because honestly, and I think you are happy to hear your feedback as well, but it happens, I would say, many times that designers come up with multiple ideas. At least I would expect it from a good designer to not only provide one solution and you have to say no. And you have to argue, you have to explain for sure, but I know it can be also really frustrating if you hear many times in a row the no and eventually the second feature that would be the follow-up feature of the first one will not be built because of a changing market or different company priorities. So I know it's a little bit of an emotional thing as well, because if you're always here to know, and if you always get rejected, I would assume you are not doing this with bad intention. I never did it, but it can be sometimes also feel very rude and harsh, I believe. I don't want to do it. Like I don't want to be like. And then what I try and do is to say this is V1 and even in the roadmap, just say whatever feature V2 was going to happen in three, four months time. So it keeps me accountable to it. If the market drastically changes in three months and the V2 of feature X can't happen, at least it doesn't get forgotten. And I need to make a really good excuse to the discovery team that I work with like why this is not happening. And this is something that is learned. So it's, if things, like you said, Christian, if it does get like things get dropped because markets changed and by having that roadmap documents just with a V2 means that everyone can remember it. It's documented somewhere. And then I hope like, I hope that Tudor will hold me accountable for not forgetting stuff and I'll need to make good reasons to say no to him too many times. What you're saying as a product manager, you also want the designers to be chasing you for a certain solution to make sure that it doesn't fall through the cracks. I hope everyone does. Cause if I make the commitment on a roadmap to say this is going to happen. And then no one asked me like, why has this happened or why has this not happened? Then it means no one's really looking at my roadmap. So hopefully Tudor and the tech guys and the other, and the scrum team are looking at it and asking questions. Let's figure it out. What are the top three features coming up next on your roadmap? If you can disclose them here. Yeah. Okay. Fair point. Just adding that to the mix. See the designers are sticking together. I'm going to take a couple minutes to describe it without breaking the privacy. Cause I, I think the serious answer is like, I don't think I can really reveal what the feature is. It's also more like a joke here. Yeah. No worries. I took you seriously. Christian has this thing on his face that whatever he says always comes across serious and it never really is. That's exactly the point. Just think the opposite of what I'm saying and then we're good. So are there any interactive workshops you are having together as a product manager, designer, or even a bigger group? Yeah. One thing we do, which is, which I found pretty interesting that came up naturally almost, is the way we go through the designs I come up with and based on all that input from all that team research and so on. No designer wants specific input around UI components. Hopefully not anymore. So one thing I found that really works is to not get feedback almost literally from anybody in that team. So what works best, at least from our experience, at least my experience apart now, is that we have this smaller group of people, which is usually me, Yoav, the PO, and maybe a TA in the room or so. And we go through the designs, but we don't go through the UI elements. Or if they tend to do, I tend to not listen when they talk about specific UI elements and then get the input. So for example, if Yoav keeps telling me that we need to make something more prominent because it's important, I'm not actually going to go back and make it bigger, but I understand that thing is important. So maybe the hierarchy needs changing or something like that because of whatever vision. So what I found useful is to not listen to specific feedback, but take the core part of it and then take that to the bigger team. And then from my perspective, again, it's a learning thing, like how, obviously you work with different people in your career, different designers. And then again, it's a learning, how do you want to work with this group or with Tudor, the PO, the TA? Having that feedback, having the different ways of feedback is really important to make sure that, yeah, the message comes across. So this is the important business decision. I'm never going to say this button doesn't look right. That's not my responsibility. And I'm sure that I'll be wrong if I say that, but I'm trying to say maybe this feature, for some reason, no one is clicking on that button. Why is that? Maybe that's more how I present that feedback rather than the button is wrong. And it's okay for designers to listen to other people's ideas. That's something important. Like it's okay if a better idea comes from somebody else in the room. It's totally fine. Yeah. Spot on. I think that's one of the biggest advice I got earlier in my career and it helps you collaborate if you're open-minded and you allow developers, product managers, and so on to contribute. Some ideas come from all sorts of people and they just help you be even more creative. And I think a designer who understands this will automatically also get more out of it. In addition, Christian, in your question, you meant around design sprints and design thinking workshops, going back a couple of minutes. We're not doing that right now in Park now, Park Mobile. It might be an ambition to do more design thinking in the long run, but my experiences before was first in a design agency called New Motion that was taken over by Accenture. And then at the Shell Recharge New Motion to do design sprints as product, working closely with design. And I think for product, using the tools of design thinking is really interesting. First, it's really important to get the right people in the room, whether or not you're running a full design sprint or some other type of design thinking workshop. And then second of all, with design sprints, there's really quick turnover of learning. So obviously, as Alex mentioned earlier, there's a lot of preparation for these workshops, but within that week or within that couple of days of workshop, you get from here's some business questions to we've tested something with real users to get that feedback. And that's something that's really powerful, both from a product perspective and from a business perspective, because I can say, look, the tech lead or CPO or someone from the management team to say, hey, we've spent this amount of time to get these results rather than build a thing, launch it and then learn. So you're saving some time in terms of the learning. You're not replacing, like it's not replacing software development and releasing, but it is speeding up the learning process and something that I find really helpful for the right challenge. And how would you set up such a process or such a design sprint, for example? Because I know it's like you have this one week of a lot of preparation and different steps where different people are coming in. And I also have heard that many companies are just doing it like in two or three days. So I'd be curious to hear what best practices you apply to design sprints. Yeah. So like I touched upon, it really depends on the challenge that you're facing in your organization. Let's take a bigger one. Yeah. So if you're facing a really big challenge that you need lots of experts in, you can definitely go and look up the design sprint from Google Ventures and see their process of what is the typical way to run a design sprint. So there's a lot of resources out there to learn from, and then that will be one part of your prep. Another thing that's part of your prep is to get the business understanding. So if you are the product manager or the person leading the design sprint, having the understanding of what is the business challenge we want to test at the end of this week is also really important. So do we want to see if this is delighting? So something that we tested just to give a simple example is we wanted to build a dashboard for our customers for a feature that I was looking after. A dashboard can be so many things. So how do you know that it's the right dashboard giving the right information to the customers? We decided the design sprint was a useful tool to study this. Then myself and the design person that I was working with at the time made a short presentation for management to say, Hey, we need this investment of this amount of time from these people, make sure that we have the list of the right people. And again, this is something that you can take forward as a list, a listener can take forward to say, Hey, I want, I've got this big challenge. Here's my business question. The design sprint might be the right tool. Go and pitch the idea to management to get permission to use a lot of people's time. And then there's also an important part in any workshop. You need to make sure that either yourself as the product person or someone else who you trust is the facilitator to make sure that the workshop runs smoothly. And again, as we've all said, it's a lot of prep time. So even though you're selling a week, your work as the person leading the workshop is a lot more than a week. And there's also follow-up work to make the presentation, both for the leadership team to say, this is what happened. This is what we've learned, but also for the scrum team that you work with to say like, Hey, this is what we've learned. Therefore, this is likely changes to happen in the coming months or the coming six months. So that's a summary. So what would you say should the final output of such a sprint? Obviously learn, like learning is the best thing. So you've either proven or disproven the business idea that you started with is the right thing or not. So in the example of the dashboard, the key question was, what is the right information to put in the dashboard and how to present it to our users, to our user base using clickable prototypes. So you're not from a design sprint, especially if you're doing this, the week workshop, you're definitely not going to have any real working code. So that's an expectation you should throw away immediately. And that expectation from your stakeholders, you're likely to have a clickable design prototype. You're likely to have a day of interviewing at the end where you hopefully have five to eight customers that you've interviewed. And then the output is a report saying, Hey, we were successful in this hypothesis. We were unsuccessful in that hypothesis. My recommendation is we should do this in the next three months as a reaction to these learnings. And hopefully if you have some successful hypotheses or were successful with some of your business questions, you can say, Hey, this is really clear for me to update my roadmap to say, Hey, next quarter in two quarters time, here's something we should do. And it could well be that everything fails. And then a response is maybe we need to do another experiment or another user test, maybe not a design sprint, but myself and the designer or the product manager and the designer can sit. If everything, if it's really bad outcomes of what went wrong, what could we do to improve both maybe the sprint design sprint itself and the results. And maybe you don't need a second design sprint, but you definitely need to do another round of user testing. And I'd rather fail within one week instead of building the wrong product and failing then. So I think obviously, but it's still a discussion where some leadership teams are still not convinced to make that investment or this, I call it, I like calling it the safe to fail experiments. Yeah. It's something that you need to sell because as I said before, it's not the right, it's not the silver bullet for every problem. Absolutely. So you need to make us before even selling it upwards, you need to think for yourself, think with your colleagues, whether it's the right tool for your challenge. And then again, it's, it's a relatively easy sell once you and the core team that you work with are convinced, because you're saying like, like you just mentioned Christian, we're learning within a week rather than learning within three, four months, whether the business theory we have is good or not. Yeah. One problem that I saw a bit is like when the businesses are not like really interested in learning or being successful on that specific thing, but they just know they want to build it. And unfortunately there, there are businesses out there that make decisions like this. And obviously then it's also hard to convince them. And I had it myself. I literally had a client saying to me once, I don't care if the users use it or not, they need to use the product and we can force them to use it. And I was like hearing this from, it wasn't a product person, it wasn't a product organization, but that's where you see the problem. And it might usually not be as radical as what I just shared, but still, I guess the whole business needs to be in this mindset of, we don't know what we want to build. You need to be open. Also, you have a vision, you have a strategy on how to get there and you need to figure it out on the way. And it might change as you move. One thing that could help in that direction, which I saw at least in the context I was working in at the moment is have a preliminary study, usually qualitative to show people how far their assumptions are from how people use it. So to put it in a real world example, I was working for a company called Waters that does pharma and everybody thought people don't use their mobile devices in the lab. And no, no, we shouldn't do anything around apps. This was a few years ago. We shouldn't do anything around apps, tablets, whatever. And we wanted to do a design split around this to figure out what kind of ideas and what kind of output can we have around apps in the lab and tablets and so on. So then we did a small study within a lab showing them how everybody presses the machine and then wants to see the status of the machine on the phone while they have their lunch, which was really powerful and helped in that direction. It depends like you offset, but I think it could help. Yeah, I think real life examples are the key and are the most important thing. Speaking about the real life examples, one thing that I'm always curious to hear is, especially like in the context of a team and of the product manager and the product designer, what would you say is like the most important tip that you would give everyone else like for the collaboration, like maybe Jalf and Tudor, you both could share the most important tip for collaboration with product manager and product designer? Yeah, I think for designers at least, or in my mind for designers, it's you need to trust the product manager that the vision they're setting and the business inputs they have actually make sense, even though maybe they're not clear for you at that moment in time. So it's looking at, our work is pretty transparent apart now. So I know where Joab is involved, who he talks to because these teams are open. So he has contacts with people that I almost never talk to within marketing or within operations, within different parts of the organization. And he might come back with some feedback related to in which direction the product should go. And I think it's important to trust the product manager that they have the knowledge to steer design in a specific way or another. And not just think that, yes, I run tests and I look at data, but that's one part of it. So don't be just looking into a single direction, believing that's the only way to go. Yeah, completely agree. I think what Tudor mentioned on trust is the most basic thing that you need to have with your colleagues that you work with. Teresa Torres is a product manager and speaker that talks a lot about product discovery. I'm a big fan of what she talks about. And it's not something that I would say as a product manager, you go and you'd be like, Hey, this is product discovery. Let's go follow that framework. But if you believe in that, or if that's something that you want to follow, make sure that you make it on your scale first. So you do the way that you want to do product discovery with design tech, the right people around you before saying like, here's a process that we should all follow as product. So I think small steps to make sure that there's communication going on all the time. Like I said, at the start of the show, Tudor and I are chatting on Slack every day. If we were in the office, we might talk in real world every day. And that's the best. And plus trust is the beginning of the relationship. I think these are great closing words for this episode. And one more little thing to add here is that the communication part is so important that we would also appreciate if you could share your feedback with the feedback form that we have added to this episode. Thanks to Joachim's great idea. We would appreciate if you could let us know how you liked this episode and what you missed and what we can do better the next time. This also to highlight the importance of data that you also raised at the beginning as key element of everything that we're looking at. We're solving many problems with one feature. Yeah. Awesome. All right, guys. Have a good night and thank you very much. Thanks a lot. Bye-bye.