Time Management & Saying NO to Meetings

So Alex, it's been a while and we finally managed to sit together on the couch and do the podcast recording. But I'm happy to welcome a new guest that we're having today. Yeah, we, I mean, we already introduced him in one of our last episodes. Today he's here in person again. So excuse any barking or eating the microphone, which might potentially happen. But yeah, thanks for having me over at your place, Christian. As always a pleasure, Alex. So what's on our mind today? Oh, that's a good question. Anything specific in your mind? Well, I had a coaching call today and there's a topic we've discussed, I think a couple of times, but I was just surprised again, how many product managers are struggling with the aspect of not having enough time. And I think this not only counts for product managers, but also designers, right? Oh yeah, absolutely. I think time is the biggest problem, especially with full calendars, a lot of like daily maintenance tasks that everyone has to do, updates, emails and stuff. I mean, I think probably one of the biggest problems is that there is no time to do actual work, right? Yeah, but I would also say it's not only about the time aspect, it's also about the role and the responsibility because, yeah, I mean, there's still product people who do things they are not supposed to do, I would say. And as far as I hear you sometimes, it also counts for designers. And I was just thinking to pick up that topic today. So what would you recommend? Maybe let's start with the problem statement or with the problem because, and it's also a question to our audience, have you ever experienced that you are busy with day-to-day business and you're not able to do research or customer interviews, user interviews, etc. And do you feel that something is going wrong? I would say a lot of people can probably relate. Yeah, and this is actually the challenge that many people are facing and that I was just confronted with again. So, yeah, there was one product manager who was struggling and, yeah, I have to, I can't use names, you know, but this person was struggling with the fact that they were doing too much, what was it again? I'm missing the English word, too much QA. And I mean, if you spend more than 20 or 30% of your time with doing QA with your team, I would say there is something wrong when it comes to your role description. I mean, isn't it in general something that should be more on the developers or on actual QAs? So my opinion is very strong when it comes to that and it's yes, it is. But I mean, we all know in startups at the beginning, you know, you do everything, you do customer support, especially when you're an early stage startup, you do marketing, you do also testing, but you need to find a time where you make the shift away from that. And that requires you as a product manager to say no or to start talking to your CTO, CPO, boss, whatever, and tell them, hey, I used to do that, but I can't do this anymore because it takes too much of my time. And I believe if you're not managed to do the shift to make the switch to not do those work anymore and to hand over the responsibility back to, for example, the engineering team or a QA manager or whatever, you will always be stuck in the workload. And I feel like it's, I mean, probably a slightly different topic. But like, I do think that PMs take on a lot of the tasks that nobody else wants to take. Yeah, because some people do not manage to say no, right? Yeah. Even though, I mean, the PM should in general be the one person saying no more than everyone else. But it's like all the way, like, I think there is always like this idea also that PMs are the ones writing tickets and moving the tickets through the board and stuff like that. But like, even that's something that probably shouldn't be necessarily only the PM's tasks, right? I think like the developers can actually take a lot of that load as well. And I think it should generally also help then the PM to have more time, right? Like, I think if the PM job is like writing tickets and QAing what's being launched, I mean, what's left from the actual product management. And I think if you are in a position where you realize that you don't have enough time to do the things you would like to do or that you want to do or that you have to do, whether it's strategy or talking to your customers, I think it's important to sit down and I don't know to maybe write down, hey, what am I doing on a day to day business? And how much time does it consume of my day or of my week, right? So if I come up with a list and QA's for example on top of that and it costs me 30% of my time or I don't know if I have to answer questions within the sprint, which takes 25% of my time, let's say, I'm just making up those numbers, then I need to start revisiting my current situation and ask myself what can I do better or what can I delegate to someone else? For example, if I do QA and I don't want to do this anymore and I also believe at some point it should be definitely taken over by the team, I think it's time to confront your manager, right? To say, hey, I cannot take this responsibility anymore. And then I would also leave it up to the manager to solve that because a normal reaction is that, typical reactions are that, for example, your VP product says, no problem, just set up a meeting with the engineering manager and tell him or her, right? Or talk to the CTO. And usually a product manager does that, including myself in the past. But I think here it's important to delegate this back to the manager, right? Because that's a bigger issue. That's not a product manager issue. That's something that needs to be discussed on a leadership level and also defined. And it's important to make clear that this is the responsibility of your boss. To initiate at least the process to discuss that and you should be invited to those meetings, but as a participant, not as the leader. But is it only like the responsibility of the boss, like, or how much do I as an individual also have the room to, I mean, I think it's at the end, it also comes down to the way how I work with my team, right? And I feel like if I see that I'm the only one doing QA, like, can I directly delegate more to the engineering manager or do I have to necessarily delegate it? Yeah, that's actually a very good question. And it's not easy to answer because it depends a lot on the structures and the way teams work. I mean, I just said what I said based on the call that I had today. For example, if you have like a CTO or CPO who are constantly pushing to deliver, who are also the founders of a company, for example, I mean, there's definitely a big conflict within the roles, right? So I think especially there, it makes sense to escalate this to a higher level. But I mean, if you're good with your team, you can also discuss this within the retrospective saying, hey, I can take that workload and I believe as a product manager that you should take over as a team and then you can discuss. But it's also important to know that this is a process. It doesn't matter if you do this on a team level or on a leadership level, such a change takes time. But the product manager is the one who should or who can, not who should, but who can initiate that process. And I believe that's important. And that's also a sign of product leadership to address those topics, to address the concerns that you have and to make sure that you come up together with a solution. And what would you say would be a good balance really in terms of like the work distribution or the different tasks that a PM should do throughout the day? I mean, you know, coffee in the morning first should be 10%. No, again, it depends on the company and the structures, right? But I think there should be, if you look at a week, there should be always enough time. And I talk about hours to focus on strategy. I mean, actually to not work, but to think, to sit down and to just think is so important. And, you know, these days people expect you to work and to do something crafty, you know, by writing stories or by, I don't know, moving tickets, as you mentioned. But this is not all about product management, right? It's to sit down and to think, to look at data, to evaluate what's going on, to talk to customers, to hear what they're missing and to not directly to jump to actions, but rather ask myself what is a sensible or good change for the product and looking at the bigger picture. And this is something that cannot happen if you are fully loaded with work and you don't have time. Yeah. And I see the very exact same thing, like also within design, right? Where, I mean, the thinking, the exploring, the trying to come up with new ideas that then can lead to new strategy or new tests or new experiments that you actually want to run. That is extremely important. And I think it goes back into the conversation also about being proactive versus reactive that we have a lot of time. And if you want to be proactive, you obviously need to have that time. At the same time, and I think another part to this proactive thinking and thinking about strategy, just like talking about myself, what helps me a lot is to have these conversations with my product peer. So just with an hour alone, I think thinking in isolation is also a pretty tricky thing or thinking about like strategy. So it's definitely something where I need to then have, okay, this is the document that we're working on, or this is like kind of the presentation that we're working on and we can discuss it together and we can spare different ideas that then helps me like also move forward when I have the time to do it. Yeah, I mean, it's actually good that we talk about it. And I was also about to ask you what are the most common, I don't know, work blockers or day to day tasks designers do that they maybe not should be doing? I mean, a mix of things, right? Like there is always like, okay, I'm just like working on some very specific designs that are being requested, right? So where the PMs or leadership or devs or so on. So I think like sometimes just like the actual design work doesn't allow or uses up a lot of like the time that you would need to actually like think more about the future of the product. Another big part is definitely like meetings, alignments and stuff like that. So like sometimes also formats that come through the business, right? Like it's the stand-ups, it's the retros, it's like a lot of like rituals where everyone's always being invited, but maybe it's not the best time spent for a designer. And so, yeah, I would say it's probably a lot of that. Then, I mean, you document things, you have like different conversations also within the functional area of design where align with other people, where you give feedback. It's, I mean, at the end, 40 hours is just like not a lot. And the biggest problem is actually like also context switching, because if you have only a few hours here and there, until you're like really getting into that mindset, and until you have the focus, and you're ready in the next meeting, that's what also fucks you up a lot. And that's why I'm also always telling product people to make sure to schedule meetings as close together as possible, right? So if you have, let's say at 10 in the morning, a stand-up, it makes sense to do the backlog grooming right after that, instead of doing it in the afternoon and forcing people to go into this continuous interruptions and context switching modes. But I think this whole topic of generally this whole meeting culture that you see in companies is to me like, I mean, honestly, it's a disease. It's a real disease. So people spending so much time on meetings, and most of the time people say, hey, it wasn't worth it, and I did something else, right? So I'm just thinking about, I created like a kind of, I don't know, I'm not sure how to call it, but like a kind of yes-no metrics to decide whether you want to go or should go to a meeting or not. Maybe we can, actually, we should link it into this podcast description. So please, if you're interested, make sure to click it, I will link it. So because I think it's very important to ask the question, am I needed first of all? Can I contribute anyhow? And if the answer is no, maybe you shouldn't go there. And if the answer is yes, then you should still ask yourself the question, can I send someone else there? Or can I get the information afterwards, right? So the first question is actually, am I someone who's needed in terms of contribution, or is it just for me to receive information? Because if it's a meeting where I just receive information, I would definitely ask myself if it makes sense to go there, or if I can read afterwards the TLDR email or something like that. So I know it sounds very simple. If there is one. If there is one, yeah. I know it sounds simple, but it helped me a lot back then to better schedule my time and also to say even more no at the end of the day. Yeah, I mean, I totally agree with the concept. I have to say, looking at my personal calendar, I mean, obviously, it also changes like with different roles and the different touch points that they inherit with a role, right? But for me, it's like really, sometimes it's, I mean, well, the role description is pretty much meetings at the end. But yeah, that also means that strategic work and thinking gets moved into the evenings and into the after hours because there is simply not a lot of meetings where I can say no. Yeah, yeah, I can understand. But here's the thing, at the end of the day, whether it's meetings or you want to do more strategic work or whatever it is, the very first step is to figure out where you spend time you're not supposed to spend time. And in my opinion, that's the very first step and the very first obstacle that you need to solve in order to move on, right? We don't need to talk about how to do better research or how to change processes in a bigger style. First of all, you need to make sure that you can free up yourself to be able to think and then come up with solutions and pitch it. As you said, involve other people like your product peer, your design peer. But in order to do that in a good and effective way, you need to start with yourself. And that's actually my point of view to start with that. Yeah, I think that's a good point, right? Like going and analyzing the time and then optimizing based on that and freeing up enough time. I think the calendar is actually like a really important tool here. People back then were, when we worked at SUMUP, when they passed through my desk, they were always saying to me, Christian, you're just looking at your calendar all day. Are you working? I said, yes, that's what I'm doing. I'm thinking about my time. It's so important. Yeah, yeah. Cool. Well, then, I mean, I would say time management starts with a clean calendar and with a good understanding of each individual's calendar and the time that we spend. And say no. Absolutely. One of the most important things in product. So anything else to say? No. Bam, that was effective. Cool. Then, Stronky, it was great spending the evening with you. Oh, one more thing we should not forget is to not forget to click the subscribe button. Oh, yeah. Subscribe and talk to you next time. Bye bye.