Building relationships & keeping stakeholders involved - with Emilie Lindström @Outfittery

Welcome again to the Product Bakery podcast. My name is Christian and I have the pleasure today to talk to my dear co-host Alex, as well as Emily Lindström. Perfect. Thank you for that. Someone trained. I'm half Swedish. Really? No. Okay. That's the thing. I didn't know that background. Even my blue eyes could potentially. For everyone who hasn't seen Christian, he doesn't have blue eyes and he's also not blonde. Well, in all fairness, guys, neither am I. True, but you have the Swedish name. This is true. Cool. So Emily, let me quickly introduce you because you also don't have the most traditional or straightforward product background. You started business initially and I mean, as you say yourself, like you have your heart and leadership. So you started actually like as a team manager working for a company who was focusing on customer communication or outsourced customer communication. I think from there you were like also in this managerial roles for quite some time. Like you were a recruiter of a recruitment director from the company before you then moved to Outfittery where you were also a team lead and then slowly transitioned into your product manager role where now since more than four years. So maybe you can just tell us a little bit about the journey and how you actually ended up in product. Yeah, sure. So people is my passion as a foremost. At Outfittery I had the pleasure of working quite closely with the tech department already when I was in sales and when I was working with quality assurance. So I was always asked like, how can we change this? Is this the right process? And all these things. So I kind of was nibbling around in that area. And then when the fantastic Natalia who had the role before me was going to leave the company, she was like, you should take over. And I was literally Googling product manager. I was like, what is this? That did not help. I can tell you Googling product management to get a quick understanding. You did not find my website, I guess. Well, no, unfortunately not. Maybe that would have helped. But in any case, I was talking to the technical leads of the company and all of the people that were working and also the data guys and all of these people quite a lot. So they were having like internal interviews and kind of tried to see if I could be a fit. And I mean, I was just intrigued because I was like, I have no idea what these people are talking about. Like, I don't understand half of it, but they're asking for someone who has insights in the area that I have and who also has been the customer in this case, because this was the role for the internal toolings where I had used and worked with. So I think that it was a very good fit and I have had a lot of fun working with it. But it was a jungle in the beginning, just under, I mean, coming from a completely non-technical background. I mean, I don't even think I knew what backend and frontend was by then. I mean, like the simplest things. And I remember the first kind of scrum cycle that I was guessed to kind of like just sit in on, sitting in on planning meetings and all of these things. And I was like, I don't know what these people are talking about. Like, I don't know. Like, this is just like, I don't understand the words. What are, what's the language here? So it was a lot of fun, steep learning curve, a lot of crazy people to get to know. Then also getting to know the product as a working environment and kind of just the whole scrum and agile and all of this thing. So it was really, really fun. How did it change the way you're now looking at the product, being on the other side now? That's a good question. I think knowing a lot more about, first of all, like getting really nerdy in how things are working technically, but also getting really nerdy into kind of user flows and user experience and all of these things does change how you see things. And I know I'm supposed to say that customers always know best and all of these things. And yes, they do to a lot of extent. But having the luxury that I have, having the customer so close to me because I'm working with the people using the tools, I have them right next to me. And I think one of the things that I'm learning quite fast is that they will ask to have every single information they can possibly have. And then I'm asking them or I'm looking into kind of the statistic on how much things are being used and it's not used that often. So I'm like, hmm, that was my first kind of discovery into maybe they don't know exactly what they want. So that was the first kind of difference because I was the same way when I was like, oh no, we need every single piece of information that we can at every time in the journey using this tool. So I was putting everything at the fingertips and then obviously that was not the case, but it needs to be portioned out when it's needed. And thinking of your first Google search and the materials that you found, like if you would have to talk to someone who is about to really get into this new world of product management or product ownership and so on, what would the things be that you would tell them? What does a newbie need to know to get started in product? Many things. But I think that there are sections that you can that you can portion them in to. I think it's really important to very much get a complete understanding of the Scrum mythology or the add-on mythology or whatever mythology your company will use. And I'm not just and actually getting so much into it that you can start to question it because I think that a lot of companies just set this system up and then they work with it. I mean, I've been to retros that it just felt like nobody really cared about them and we're not really respecting the ceremonies at some point, but then you can also go to these retros or have a grooming that is just phenomenal and blows your mind and you're like, oh, this is why we do these things. So I think I did not, coming from a personality where I don't like structure and I like doing different things every day for me, getting into the Scrum cycle was quite a strange experience. So from that point, I think this is something to get a broad understanding of what that means to be able to utilize it as quick as possible. That would be one thing. Also getting into getting to know the team very well. I like people. So that was something that I was enjoying quite a lot. But also then, I mean, I fitter as an international company. I don't think I had one nationality in my team that matched another. I worked with Brazilians, with Polish people, with Russians, with German people, no Swedish people, unfortunately, or fortunately, I haven't decided that yet. So there was this mixture of people and getting to know and kind of, I think it's super important to work on team building in that matter. And then also getting to know your stakeholders and really getting into the process of planning and meeting expectations, but also setting your own and be clear of your expectations moving forward. When you as product manager get started, the very first thing that is kind of the wall you will run against is this agile framework that requires a lot of discipline. If you're someone who has never experienced or faced that, it's like, oh, what's going on here? Yeah, all the ceremonies, all these meetings and all this kind of particular things they talk about, which are maybe first of all hard to understand, but then at some point it becomes natural and you understand the pattern behind it. And I also like a lot that you mentioned that it's so important to get known to the team because when I'm coaching product managers or even by myself, that was always one of the first things that I focus on because the human relationship and the human interactions over processes and tools, as the Agile manifesto says already, it's so important to really know to whom you talk and what is going on behind the scenes. This is also how you move things forward, right? So I mean, some developers, they really like to know so much about the business processes and the reason behind things and the logic and why and the human part of things. But then I have developers who doesn't really care about that, but they want to know the rationale behind why things are built the way it is, for example. So it's, I mean, you get more efficient if you know how to cater to them, to trigger whatever they need to get interested in the topic that is on. And one of the worst things that you can do as a product manager is trying to answer these things quickly or not taking enough time and passion to really explain them in detail. Especially when engineers, I mean, these are smart people. So when they get it, they really get it. But as long as they are walking around with question marks, you cannot expect from them to do a good job. I fully agree with you that it's really important to spend time to explain things in depth. Yeah. When it comes to the stakeholders, I'm a little bit curious because you mentioned this so explicit. Yes. What is very important for a newbie? Looking back to my first, so I mean, I've always been so lucky. I've had the best stakeholders, holders on earth. They've been phenomenal, very engaged in all of these things. But I think I also took this for granted. So kind of looking back to what do you do when you don't have a good relationship with stakeholder, or when it doesn't really work smoothly, or when you feel that they are not engaged, or whatever that could be. So there's a few things. I mean, I know that back then, my boss, just when I started, he was like, I want to know your vision. And I was like, I don't even know what my job is right now. I was like, I don't know what I'm doing. But he was like, What is your vision about about this product? And then I was googling vision. No, it wasn't that bad. But I was looking into what how I wanted to present my ideas for what this could be. And I took quite some time, and I got the freedom of doing this. And then I actually presented this vision to the team. And I said, Could you guys sign off on that this is the vision of the toolings? Or do you what should I add to it? So I worked with them quite a lot of it. And with the team now, I mean, the technical team. And then I also spoke to my then product managers. And I was like, this is what I feel is missing or where we want to drive forward. And this is the goal. And then I took it to the stakeholders as well and said, So, hi, I'm here. I'm new. This is how this is me. And this is from a product perspective, the product mission. Do you agree that this is where we want to go? Do you want to, like refrain and then had a workshop around it together with them, which was super efficient. And this is something that I did very early on. And it was very lucky to kind of then coming from sales and coming from a kind of teaching environment. So this was quite easy for me to do. But it also worked. And I think this is also one of the things that I'm now that I'm looking back at it, why the relationship actually worked is because we had a very clear, stable, kind of fundamental thing. But then other things that I wish I also kind of reminded myself of earlier is like keeping up the communication with them. Both ways. This means that they are they can set up patients for me and I can, I also need to hold them accountable that they show interest and they do this and to really state this in an early kind of way. But because this is something that I know that I've been sloppy with also moving into home office and all of these things. I'm like, Hey, wait, I haven't spoken to this guy face to face in forever on this. Like I haven't talked to my one of my stakeholders in two weeks. Why? And then I'm so you get sloppy of it. And I think this is something that as a newbie setting these kind of boundaries very early and expectations that goes both ways, but also keeping it up and making sure that you know what you're doing. How regularly are you meeting? And is it like, kind of casual checking in? I think this is very hard to I think it's important that you have a meeting structure in place. But I'm also not really buying religiously following it. Because there will be times in when it's just like a slack message is all they need. Maybe they just need to be added to the ticket that they're asking about. And you can be like an FYI in the ticket, or it's something that is super simple. And or it is actually something that also demands more, but I do very much encouraged to have the time set aside because I'd rather do and check in with them and say, Hey, everything good? No, yes. And then leave it like that, if nothing can be done at the moment. So did you from day one knew who your stakeholders were back then? Oh, three years ago, let me think. Did I know this? Now? Do I know? No, I'm just randomly talking to everybody in the company. Yeah, no. Yes, I didn't. I didn't know. But I mean, it was also, back then, my responsibilities were, were like half of what they are now. So it was a lot simpler back then. And now I have two departments that I'm trying to help as much as I can. So it's a bit bigger, the scope. But back then, it was a lot more, a little bit more straightforward. The reason I'm asking is that I see many times that people, product managers, especially take it for granted saying, Hey, yeah, I know who my stakeholders are. And there is this sales department, and there's engineering, and there is marketing, and I have to regularly communicate with them. Then like, okay, can you name me all people now? And then they start, yeah, and there's this guy and this lady. And yeah, and now I'm not sure anymore. And I'm like, okay, so maybe the first thing is rewriting it down, especially in bigger organizations, obviously, when things are more complex, to get an overview. And it's just a matter of five minutes to write down who your stakeholders are, and also understanding what type of stakeholders I'm serving, because there are people with a lot of interest, but not necessarily a lot of decision making power, or vice versa, people who have a lot of impact on your job, but potentially not care or even care a lot. So it's important to understand talking about loving people to know to whom you talk and to know what kind of information and in which interval you serve them. Definitely. But I also don't think to add on to them having weekly meetings or having this kind of catch up session. I mean, just making I mean, we use demos, right? So we have all of these things to actually draw people into I mean, we had a really cool thing set up, actually, due to Corona stopped it, but we had a showcasing, which was kind of a relaxed way of doing it, rather inviting the whole company and making sure that everybody knew what's going on. And this is one thing, but I also think that you should be very clear that if you are a stakeholder, you're also responsible to be alert, because this is something that it's, it's, I mean, I do not know how many times like Emily, you need to communicate with everybody. And I'm like, Yes, but why isn't everybody communicating with me then? I really believe that this needs to be a two way communication way as well. Because this is how you build long lasting collaborations, right? Just on that, because I've seen also sometimes people are not alert, as you say, and then maybe they just read something in release notes, or like really at the end, and then they have the comment where you're like, Okay, but why did you not have this earlier, like in the different demos and notifications and meetings where we actually talked about it? Did you ever experienced that as well? Yes. Story of my life. I'm at the moment, redoing a lot of work I did last year in terms of user testing and user experience because of the exactly this. So yes, I have to redo work, which I hate, probably is going to be even better. So that's good. At the end of it is just a lot of extra fuss about it. But one thing though, that I really enjoy, when it happens, and when it happens, good is to have a proper kickoff. Because I really believe and I also find it so liberating in terms of the communication, cross team and cross functional and everything. So basically, what we want to do, and what we have tried to do is when there is a new bigger thing that will happen, I mean, we're not talking about the smaller changes or anything, but a bigger initiative that will come. The product manager together with the project manager usually work on something together and then do a bigger presentation for every single person that might be of interest. So and they can just reject coming but then we can also always refer back to Hey, the kickoff is where and we have clear expectations on the people who's coming like we're expecting you or we want you to come for the reason that you are an expert in your field. And you will have insight on how we can do this better. So before we even start to shape it into a story or an epic or anything, bring all of these people in. And it might seem like a costly thing to do because it's like bringing a lot of very important people into one room. But at the end of the day, if you can get these things out, I mean, I have had like epiphanies in these meetings when some guy from the data department or something where like, Hey, but what about this measure? And then it's like, Oh, yeah, that is the actual success measure, not the things that we've been looking at, we've been looking like, and then things kind of unraveled differently. So I think having these initial kickoffs, or whatever you want to call them really opens up the transparency and people and also, but also is a call to engagement, right? From people, or two people. Do you feel that it's difficult? You feel that it's difficult to get all these people in the room? Or is it something? Yeah, definitely. Right now, it's very difficult because of home office. I mean, I would be the one who would be like walking to someone's desk and ask why they rejected a meeting so that I have no problem with I will also slack people now and asking them why they're not want to come and listen to things. But also this, I mean, this is not a blame game at all. This is really just letting them know how important their opinion is. Because that is at the end of the day, I do believe that we could have avoided so many dumb mistakes or stupid sidesteps or whatever we took on the way, if we would actually just have really talked about it, to extent in the beginning, but it's difficult. At the same time, I think it's, I mean, it's amazing that you actually value them and their opinion so much. Because one thing I've also seen, especially like when it comes to stakeholder management, there's people who tend to, let's say, think that they know it that they are the expert matters, you know, like you as a I'm speaking for myself and designers in general, they're like, why would I ask one of my stakeholders if this is the right interaction? I know all the different apps, I know all the best practices. So that should be my call. But I think like, what you're saying is, at the end, the stakeholder is the expert, to one extent, they are, they also see different things, and they have some knowledge. I think we're all important in the process, right? I mean, I but I also very much agree with the fact that I should be the expert of the product that I'm working on. And I am. And I do believe that I am. But then again, my job is to find the right next step, right? That's essentially what I'm doing. I'm trying to figure out how to make the experience better for the users, and I'm trying to give them the best possible way. So if a stakeholder has an opinion, and now, I also know that there's not just stakeholders, but any people within the company, who might deem that they are actually the expert rather than you, when it's like, interesting, you are working with this, and I am actually working with this product. So yes, but this is also people, people always think they know better than, than they might do, right? There's also this nice saying, you don't need to know everything, but you need to know who to ask, right? Let's say I'm your stakeholder now, Emily, and I'm just a lazy stakeholder who is not working proactively with you or who declines meeting or doesn't appear. However, how do you deal with such situations? How would you encourage me to improve the collaboration and communication? I wish I had a clear answer and be like, this is what you do. But I won't bet. Yes. I mean, we're talking humans, right? The stakeholders are also humans. And so are we, I think at the end of the day, it also depends on, I mean, I am, I think that we should never be be afraid of actually giving feedback and talk to our stakeholders. I am not a fan of, even though my, my CPO might feel differently, but I'm not a fan of going crying to my CPO and be like, Mary, Mary, Mary, complain to him, I rather take action myself. And I think you can be very, very, very honest, but also then keeping the dialogue open with the stakeholder who's not showing up saying, how would be a better way for me to communicate with you? Or how do you want to make sure that you know what you need to know? So you don't have to hunt me down? When you need answers? I would rather provide you with the answers before you need them. Because this is my job. And then I also question people in that matter, like straightforward, like, why did you not show up to the meeting? Are you going to come to this meeting? Usually you don't. Sometimes people also need to be called out, even if they're good people. Yeah, I agree. I think the worst thing you can do in such situations is trying to avoid, I don't want to say the conflict, but trying to avoid the conversation. And also being candid and saying, Hey, I mean, the tone is always, I think the measure when it comes to that. So you can say, Hey, why didn't you show up? Or Hey, I was just missing you today. Is there something I can update you with? I can update you on. But what I think happens to many, many young product managers is just taking this for granted. And also being afraid of raising this because of they are new, just joined the company, etc. And I think especially then you should step up and simply ask. Yeah. I also think it's like getting them more engaged. I mean, there's multiple ways of doing this, which is also quite like simple in terms of so let them actually get to know your team as well. Like your developers. I think that the stakeholders should know the team. They don't have to be best friends, but they should know their names. They should know who's working with, with these things, but also invite them to make them be the expert because they are the expert in certain areas probably, or they will have a lot of opinions that matters. Invite them to a grooming, for example, if there is a topic that they would be very interested in, or that they actually can provide good information. So they also get to know the process and get to know things and feel like they are part of it. Because there's so many times when I because for me, as you might have recognized, I kind of see them as a very important part of the whole process. So I think it's important that they also get drawn into it. And I mean, yes, people are busy and people have other responsibilities. But at the end of the day, if we can make it smoother, by them having a very good and clean interaction in the team, I think that's a lot easier. When it comes to processes around stakeholder communication, you said you have multiple ways of pulling people in looping people in, for example, the grooming, etc. Is there any like a kind of best practice or something I could get started with if I want to, if I just joined a company to directly start a good conversation and collaboration with my stakeholders? Well, I think this initial kind of introduction where you would set the boundaries is the first step on this in terms of how do you want to have it? These are my expectations on you as my stakeholder. And this is how I would like to do it. One thing that I've come to realize it's, things get a lot more efficient if you're actually coming into a meeting rather than just having a, like, how do you want to do it? But like, this is how I want to do it. How do you agree or not? I think this is a lot more efficient. So have a plan and have an idea of what you want to do, present it to your stakeholder and get a sign off on this and this is how we work. I think that you can always bounce back to. I mean, the few times where I actually had some issues with kind of feeling ignored or feeling sidestepped with stakeholders, which happens to everybody. I think I've always been quite soft about it. I mean, like, hey, what's up? What's happening? What are you doing? One thing that I talked to a product friend of mine just the other day about, and he was like, but why are you not just pushing back on the OKRs? Like being clear of the goals that you have set as a company and as a department. And if the stakeholder wants to go and do something else or running somewhere else or doing something and is not aligned, just pull this person back in and be like, hey, this is what we agreed on. Or do you want to do something else? Then we have to renegotiate and we have to break things apart. But this is also why I think it's important that they are a part of understanding how sprints are working and how the rhythm is working. Because if the stakeholder comes in with something new, which happens, then it's very interesting if you can just be like, hey, these are the things that we know that we want to do because they are in our OKRs and they're planning in the roadmap, whatever you have as a measure. And now you want to do this? Yeah. OK, let's talk about it. I like that you are so soft about all this kind of things you just mentioned. I used to I used to have a boss who was just going to my to my team members and saying, hey, you need to build this. I was then just walking to the office of my boss and saying, hey, boss, you can't fucking do that. I mean, this is nothing that I would, by the way, recommend when I was young. Honestly, Christian, I think Emily's approach is definitely the better one. I just want to show a potential other option here. Yeah, but I mean, the reason, Christian, why you're not there anymore. My message here is this was at least a pitfall that I was falling into. And I had no one back then who showed me the other way. As obvious as this might be saying, hey, it's better to approach people proactively and ask open questions to to find the answer. But I wasn't back then on the stage, I have to say. I can tell you that three years ago I was not either. These are the things that I have learned during the way. And I don't think this is like an issue. I mean, at the end of the day, and this is why I actually very much love product management, not just because the work that we do and all of these things, but it's so much about people. It's so much about people and talking and getting to understand what is the next best step to take, nothing else. And I mean, egos will always come into play here in terms of people think they know best. Sometimes I know best, sometimes someone else knows best. And you've got to kind of take that take that away and try to see the situation for what it is. And this is difficult, but it's also what makes it fun, right? And this is exactly the reason we're doing the podcast, because we know the pitfalls, and we have done all so many mistakes. I think in our second or third episode, Alex, we discussed that, right, that we mainly learn from our mistakes rather than having someone who tapped at our shoulder and saying, Hey, are you sure you want to do that? Or do you want to rethink this one more time, maybe? Yeah, no, absolutely. But, Emily, so one thing I really like is the people aspect. And, again, if I think back on your whole career, you always work closer with people and you were managing people and so on. Do you see, let's say some parallels between like managing people directly and managing stakeholders? In terms of my personal philosophy of like never giving an answer, but rather always ask the question back to what would you do and how do you mean coaching people in sales, for example, they could come with a question and you would always be like, but hey, what do you think is the best solution here? And then they would actually have it themselves. I think part of that mythology or part of that kind of communication can very much be used together with your stakeholders and also together with the team. I mean, I have tremendous faith in my development team. I think they're all brilliant people. But they can also come to me and say like, hey, what are we going to do here? And I'm like, well, what would you do? Like, come on. I'm giving you the outcome. I don't care how you get there. I will trust you to get there. There's this definite thing. But then I also there with the stakeholders, though it's also or rather with not with the stakeholders, but let's say this. So I think that what I miss about not managing people and not working with people is just that, like I'm not, I can help my stakeholder to understand the product world more or to work better in terms of relationship with me and we can make plans together. But you're not a part of their journey in the same way as you would be when you're managing a person because you then can can help this person to evolve and get better. And I know this was one of the biggest things coming from being a team lead and a coach and all of these things. When I moved into into product management, and I was like, tech lead. Why do I need a tech lead? Am I not supposed to lead this team? Because this was my kind of idea about it. I was like, yes, of course, but then I also need to have the full spectrum of like developing them and everything, which I do together with a tech lead, because we do work very, very close together. But I also completely understand that there's a lot of things that I would be useless in trying to be personnel leader of a back-end developer. I'd be like, hey, you want to advance your career? Yep. Then I would have nothing. Write faster code. Yes. I was like, don't do any bugs. Bug less for a couple of months and we can talk about it. A 5% raise. You mentioned that. Exactly. Or how fast you debug things. I'll time you. I don't know. No. This also means that you do work with stakeholders, with the team, but there is also this part of functional leads, right? The ones that develop the team that you work with on a daily basis. Yes. And honestly, without them, I mean, this is the setup that we have at the moment where we have a tech lead working together with a product manager. And then we have the developers that we work in and also in teams for different areas of the business. Right. And without the tech leads, I think that it would be, I mean, there's probably a billion ways on how to do that. I haven't even thought about it. But from the perspective where I am, they're really, really tremendously important because they have the bigger kind of picture because otherwise you can get very, like if you're always looking at the same kind of code base, you can get blind. Right. So the tech leads are there to kind of see the bigger picture as I am to see the bigger picture of the product vision and continue telling the story and making sure that everybody knows where we are going. How often do you revisit the product vision? Is there a kind of process behind it with your stakeholders or with your CPO, etc.? Christian's favorite topic. Yeah. Oh, my God. Can we, I mean, if we talk about roadmapping, OKRs, visions, we can talk about weeks, weeks. I want to say that I have not yet seen this process work perfectly. Now I only am a few years in. We have tried so many ways to align the companies about what OKRs we should have or what the vision is. And I mean, we have a vision for the company we have. And then there's I mean, I have a vision for the tool landscape and how I would like that to be together with the stakeholders and together with the tech department, which I do revisit. But I would love to see a working process and how to work with that properly because we do not have it, unfortunately. I do think we have a lot of fun trying to figure it out and we learn a lot from our mistakes. And I know we have spent many long evenings in the office trying to figure things out. But it's it's definitely a bit complicated. So trying to get my head around all the different types of stakeholders, because I think it's just like always such an amazing topic. And I want to throw in one. And this is like my favorite stakeholder, because obviously coming from design, my main focus is the user itself. So this user being the stakeholder and the voice of the user having the influence on the product, maybe you can just share also a little bit, especially because you are so close to the users. How do you combine this? And yeah, I mean, we can leave it there. How do you combine this? Well, in many ways, I mean, I'm thinking so fair and honest, it's been quite a slow years in like year this year in it because the world pandemic thing going on. But at the end of the day, what I mean, I have the luxury of having a team where I can always release to and test with. And so we have a dedicated team that works with products and data from the styling team, which they are completely amazing. They have so many ideas and everything. And just for me, I have the luxury of I can just any day, any time I could go and sit next to my user and see how they work. So it's very, very luxurious. I am also the first one to hear if something is not working. So on that side, it's also quite the troublesome because if something is not working properly, I get bombarded from 150 stylists if something is not working. It's a slightly irritated relationship sometimes. Let's call it that. But the things that we can do together, also working and we do quite a lot of explorative workshop together where it's like, OK, so trying to really put them out of because they get also blind from using the product every day. And this is what I mean when I'm coming back to they think they need all of the information. So having quite a lot of, I want to say, kind of like tearing down barriers kind of workshops where it's like, OK, so what information is it that you actually need to make these conclusions that you need to make to do a good job? And what does customer style mean? When we talk, what does that mean? What is that? What is that concept? And I have had so much fun. I mean, this is my absolute favorite thing in the office to be able to do these things, to be able to find the right way of moving forward in terms of giving them because essentially we're giving them the customers. So we need to find a way of presenting the customers to them so they all can do their job as best as possible. So in collaboration with the people working on the web in terms of what information are we collecting about the customer, but then also figuring out with the stylus, what is actually like, how do we get to know someone from a few questions online? So it's super interesting to work with. Do you feel like that the users needs and expectations are sometimes different from what the stakeholders ask you? I was. Yes. I mean, since they do not know exactly how the users are working and so the user was there, hey, we need this and this and that. And then the stakeholders said we need to do more or faster because money. So this is always a balance act when we need to look into kind of like, OK, but we need to make sure. So, I mean, I would say I want to add a feature and they're like, will this slow down their process? And I'm like by like 0.02 percent. But I can guarantee you the uplift in returns will be better. So there's always this give and take. And I mean, here numbers do matter. So this is another thing. Always be ready to kind of fight with numbers when needed. Even if you can sell a good story, you kind of need the numbers to back you up. That would have been exactly my question. How do you emphasize your stakeholders? Apart from the numbers, are you bringing them also into one room and saying, hey, this is what the customer wants? This is what we initially planned on our roadmap, for example. And now this is the way of the middle. As a company, we're working on two legs. Right. So we're working on the customer having freedom himself and then we work on trying to give the stylist as much as possible to work with for the personal relationship. So we have these two legs. I think it's really good that we are allowing both freedom and super personalization, but it's also been a tradeoff in terms of where we put our effort in in the development and in the product world. So I mean, since some initiative takes a lot of time and we need to redo quite a lot of the platform to be able to offer certain things to the customers, then the stylist kind of side of things might get kind of like, oh, but it's working. And I'm like, but we need these things. So, yes, then it's when I would really be trying to show the reality for them as well. But this is also where you can always looking into, like, if we do not do this. I mean, I have like one service that needs a refactoring and I'm like, dudes and dudettes, we need to refactor this. I need development time. And they're like, yeah, but and I'm like, OK, the cost of this being down for five minutes and then kind of like just rounding numbers on how much we would lose if this service is down. So they understand rather than it's not a like it's not a I mean, I don't find it funny to refactor a service that I mean, oh, my God, I'm falling asleep just talking about it, but it needs to be done. Right. So I feel like developers are probably more excited to refactor things. I mean, yes, that's great. I love it when they are excited about these things. If it makes my feature development faster, I'm always in for it. Right. Right. I think this is one of the biggest myths, though, with kind of like the fight between tech and product. Because it's always like the product just want to do product things. And I was like, I want to do product things fast and easy. That's the key. Like, I want it to go fast and easy. And that should imply refactoring. Right. Yeah. Just before we wrap up, because we've also talked a lot about the different stakeholders now. One thing that I would be curious on, because I always love like real life examples, what was like the most challenging stakeholder you ever had or the most challenging situation that you ever had with a stakeholder? I would say the surprise that I got from literally not even 12 hours before sitting in a meeting with a stakeholder and then six hours kind of after that meeting, him doing the complete opposite of what we decided. And I'm like, wait, why are you taking steps in this? We just talked about it and kind of like moving around me and not talking to me and making decisions. And I was just like, and then because this also kind of rippled. effect into other departments contact me and being like, Hey, what's happening? And I'm like, so just like leaving me feeling extremely unprofessional, I wouldn't kind of like hung out. And that was really uncool. It took also some time to clean it up because then I was just like furious and I wanted to go into a room and yell at people couldn't because of office. But I didn't, however, try to kind of talk to everybody and basically said, like, if the stakeholder moves in this direction, just say no. And when he asked why say Emily and then make him come back to me. Uh, it worked and it's better, but yeah. What's the stakeholder directly approaching them and trying to so bad like in multiple departments. And I was, and then they slapped me and they're like, what's up, Emily? We just talked about this. Why am I being bugged? And I'm like, Ooh, I don't know. Yeah. But I have also like a kind of horror story to share if you'd like, I used to work on a feature back then. It was a big enterprise project, big customer behind it who pays a lot of money and as it happens, the feature was delayed, we have planned very well, but people just got sick and also at the same time we needed to clarify a couple of technical things with the other side. So the project was delayed two weeks and I was reaching out to the project manager lead and told him, Hey, listen, there are open questions. We need your support point a and point B is half the team is sick. Yeah. We really can't get it done. And then he was like, no problem, Christian. Everything is fine, et cetera. And for sure in enterprise business, you have this kind of escalation meetings that are happening. We sat down with the CEO and he asked what's going on. And I was explaining the situation as I did before. And then the lovely project manager person said, Hey, Christian, I actually can't understand what you're saying. First of all, we have everything written down, which was partially true. But then he said, I just have here in front of me, the numbers from HR, the average sick time per month per employee is two days, why didn't you calculate this in your project plan? And I was like, Dick move. But the big learning though, right? Big learning was as crazy as it sounds, always at the buffer that people can potentially be sick. And as, as hard as it was. And I, I swear I was in Germany, say I was on 180, I was really aggressive, angry, mad, everything at the same time. But looking back, it's like four years ago, that was one of my big learnings. I can really recommend to everyone who's planning projects and works on tight deadlines. Don't forget that we are, as you said at the beginning, Emily, we are all humans and we can obviously also get sick. One thing that I actually like here, and it's, so I think that there's, there's a little bit like almost an overlap in this, in the stories, but I think it's like, Emily, for example, in Germany, there's this term in the plan, a hound. So you put someone in the pen. I'm not sure if you've ever heard it, but it's like, Yeah. In your case, for example, you had an agreement with the stakeholder and the stakeholder went behind your back and to some extent, and I've been there also a couple of times to some extent also as company leadership and so on in front of the team, you need to justify a little bit. Like maybe he said it because of reason X, we need to justify it. Like you cannot throw him in the pan, which is what happened to you, Christian with, with your stakeholder, because like he was in a meeting escalating, pointing the finger at you. I mean, purely from a stakeholder management perspective, that's, that's the worst thing that he can do because like that's destroying everyone's relationship. Like I would never build something for this person. But I'm not building for persons. I was building back then for a customer, so you need to distinguish. Yeah. I mean, he and I managed to get around and clarified this, but yeah, there, I have to say I was sitting with him in one room and also explaining my feelings and my, my thoughts around this. And it was a kind of tough conversation, I have to say, but at the end of the day, we managed to get over it. He definitely had his learning. I had my learning as well. So, I mean, you cannot blow up the project because you are internally struggling. You need to be professional enough to look ahead of it. And. Sure. But I think like at the same time, it's, it's around mutual respect, right? Like I, if you mess something up, I make sure that we have the conversation so you know how you can support me, how I can support you and so on and so forth. Like it should never be like a finger pointing. It was definitely toxic. I don't want to play this down. Get that straight. Yeah. At some point I also decided to leave, but this is not part of the story. So what I want to say is at the end of the day, I needed to work with this person on day-to-day business, but it doesn't change the fact that the project is on the plate and you want to deliver. And I was emotionally really attached to this because we just launched a platform the first time. So it was my baby, the whole company just went live. So it's such a big project and being part of this is already huge. So I was really focused on doing the best for the company and not fighting around with people, to be honest. But I also think that one thing that I also would like to do for myself that like, or learn for the future, but also now that I hear you Christian talking about these things, it's actually to use the framework that we have to kind of balance in. So we have the retrospectives. We could be very sure that we have a retrospective and to bring all of this up and bring the stakeholder in. So they are a part of this because I do believe that, I mean, even if you don't want to go too personal or anything about anything with your stakeholder, but to actually just like get it out there and talk about things, I do believe that that will help from the future. But I do also like my last kind of thing of this is that to focus on the positives. I'm very sick and tired of hearing people say, all right, but this didn't work. How do we make a difference? And I'm like, yes, but okay. But let's talk about the things that did work because this is also like, if you're in a toxic kind of anything, okay. And then there's always this focus on the negative. So actually bringing up then. Okay. So all of these things didn't work. That's fine. We can talk about these, but let's talk about the things that did work and why they did work and how can we continue on the paths that actually did work. So I think this is something that is, it's an easy tool to use with any kind of anything, actually, that doesn't really go as you expected. You would be able to kind of bring this into the, into the ballgame and it's a different kind of mindset. And it also gives an easier going kind of feeling when things are complicated. Awesome. So bottom line, we've heard how important stakeholders are and how important it also is to manage stakeholders. If you would have to really take out the main takeaways of this conversation, especially thinking like as a product manager, what can I take out of this conversation? Make sure that he or she knows who you are, be open and honest of how you want things to work, drag them into things if they're unengaged and really try to make them more engaged by any, any means necessary or just invite them to the grooming. That's, that's also fine. But then I think also just what I said, try to, if things are going south, focus on things that actually did work and do have a conversation about how to continue the good parts. Cause I think it's sometimes we do end up welling around in terms of whatever welling is not a word, waddling, rolling around in the negatives rather than moving forward. And if nothing works out, you just take a can of this drumming and throw it at people. There you go. Yeah. Jesus Christ. All these Swedish insiders. Yeah, you don't know what this drumming is, Alex. This is the sixth mold fish that smells like hell. Okay. Okay. Before we close it, as a Swedish person, have you tried it? Süßtrömming? Oh yes. Yeah. It's. And is it, is it as bad? Or is it as good as people say when you ignore the smell? I do. I know. It's not worth it. With that, I would say, Emily, it was a pleasure to have you. Enjoy your, hopefully nice dinner and have a good evening. But Alex and I will now jump as always into the debrief. Thank you, Emily and music on. I really can't get enough of this music. Should we listen to it once again? No. All right. And welcome back to our debrief. I mean, if it's not the first episode that you're listening to, you should definitely check it out, because it's a lot of fun and it's a lot of I mean, if it's not the first episode that you're listening to, you should be pretty familiar with this format. So generally me and Christian just try to summarize a little bit or to share at least like our thoughts on it. So Christian, what do you think about the conversation with Emily? I really like how she gets started with stakeholders. This just sitting together with your stakeholders and sharing who you are and showing or presenting how you expect things to be is something that I should have done many times in my career. When I started a new project or started even a new job, that was definitely something that I recommend to people in general, when I work with product teams. And at the same time, I think this is, to me, like a kind of best way to get started, because the human interaction is super important. And what I really took away from Emily was to get a straight line from day one and to make sure that you have, at the beginning, directly clarity, and not only sharing what you want or how you expect things, also asking the other side, hey, how are you used to work with product people? What do you need from me? But I think even with the other side, it's easier that you, as product manager or, in my case, product designer, approach stakeholders. And they're like, what do you need from me? But I think what is also super interesting is to be like, OK, stakeholder. Besides, obviously, that I need to ship your stuff, what are the things, generally, that you need from me? Or, you know, like, sorry, that I need from you? You know, to really have this cover both sides of the spectrum. And I think that's something that's easily forgotten. And then on top of this, also having this regular synchronizations and meetings to make sure you loop the people in when you need them. Because they are expert on certain areas. I always like, for example, let's say you build a financial product. You have compliance people, people on the legal side. And you can definitely not do your job without them. So you need their input. And bringing them into a meeting, and adding them to a backlog grooming, and involving them into the discussion together with your team is so valuable, not only for them, also for your whole team to get this common understanding of the domain and the expertise that is needed to build the product. How do you think about that? But you need to do this sugarcoating, right? And I think that's, no, honestly, it's super important. It's not like, oh, yeah, you're the stakeholder. You're requesting things. It's like, you're the expert. And I've seen it. And it's the cost of bringing in people, which can be high. And sometimes you just cannot block a lot of people's calendars. And thinking of whenever we run design sprints or ideation sessions, super hard. And already by being simply rephrasing and also putting it differently, and, OK, we have lightning talks. You're the subject matter expert. Can you prepare this five-minute session at the beginning to open the conversation so that we know that we get the full context? I think that's important. And sometimes it's even just this short amount of time. They don't need to be there for the full conversation. But at least you get their involvement. You have their buy-in. You can follow up easily with them. You maybe ideally even have the excitement. And then you have a good working relationship. And this is what we're all aiming for, a good working relationship. Aren't that crazy, good, closing words? If you say so. I mean, we can continue extending our relationship by having another one hour of conversation. But I think for this session. Maybe you can tell me, Alex, how people can reach us when they want to give us feedback or have questions. Good point. Almost forgot about that. So we always have our hello at product-bakery.com email address. And you can drop us a line if you have any suggestions on how we should improve the format, who we should invite, who we should talk to. Maybe you're working in product and have something interesting to share. Feel free. Simply write us. And we will immediately get back. Great. So with that being said, let's continue the music. And thank you very much. And talk to you next week. Bye.