Follow up: Asking stupid questions & playing dumb

Welcome to the Product Bakery again. My name is Christian and I'm here with Alex today with no guests, but it's lovely to have some private time with you, Alex. Hi, Christian. So Alex, I think we had last week a very cool and interesting interview with Paul talking about asking stupid questions, but we did not only talk about stupid questions. We also or I took away a couple of questions for myself and I was just wondering, and also to, for the people who didn't listen to the previous episode, we just realized that actually every product manager, product designer, product person, whoever has access to all information out there. So you can read thousands of books regarding how to build an organization, how to build a product team, how to become a better product manager. But I just asked myself, why is not everyone working like that? How do you think about this? Yeah, it's a very interesting question because we've heard it, right? And all this like assisting or consulting a bunch of different companies and usually they all have the same problem. Product managers don't have a good process in place that at the same time also harms the way they collaborate with other people, harms the quality of the product that they ship and so on and so forth. And it is something that I've observed a lot as well. Like on, I would even say not only is there access to the information, but a lot of people know how it should be done. A lot of people know how to work, how the right processes are, how product development in theory works. But I do see a big gap between knowing the processes and applying the processes or working in a good way. Yeah, to me, it's a little bit like the chicken and egg problem because where do you start? Is it only product or is it maybe fucked up engineering processes or is it the strategy that is pushed from top to bottom? So I think there are many factors. But let's say it's not product because I think we can all agree that oftentimes it's a management issue or again could be an engineering issue, a stakeholder issue. But that's actually where I was coming to because the thing is not where the problem starts. I think the question is what you make out of it because what many people tend to is trying to fix the other side. So let's say you are a product manager, you have issues with engineering speed and you're going to tell the engineering leads all the time that they have to improve their stuff and vice versa. The engineers say, oh, our product is not working and they're just focusing on the other part instead of starting with themselves. Okay, but that would again bring us back to a topic that we constantly discuss, which is like collaboration, right? In theory, it shouldn't be like a finger-pointing thing. Oh, he does something wrong. You need to do this different, but it needs to be working together towards figuring out what are the right approaches. And this can be the designer, this can be the product manager, this can be the engineer, but it's all about problem solving and all our job descriptions say problem solving. So in theory, it's like the problem solving aspect of sitting down as a group, figuring out why the things are not working the way they should be working and trying to fix it. It's true. Before you go that step, I would even take a step earlier by just looking at myself and asking myself, am I doing what I'm supposed to do? Because as you said, as a product manager, I know how the engineering team has to work, but I should also know, hey, if I'm managing a backlog, it should be prioritized. It should be clean. Ticket should be readable. I should have the why in place when I'm attending a meeting and pitching people what's coming up next. And the question is, especially for product managers, are they having these answers? And if not, I think before you look around and tell people that you are not empowered or that you don't have the time or that you are not able to work with other teams because of X, Y, Z, first of all, make your own homework. You know what? There's one thing that actually comes to my mind if I think about this topic as well. Back in the days when we worked together, right? At least once a year, we took the time to go to a conference together once a year. But I think like whenever I go to a conference, I often, and I'm like just also reflecting on my own, I often hear things that I don't that are not new. But then again, just hearing them gives me a little bit this reminder to go back and do things differently. So I could almost see also a little bit like being the problem of the being a problem of a routine. Because we do have a lot of things to do, we easily get like in this routine of doing things, delivering things, maybe doing them the wrong way. And we never take the time to reflect or take the time to, as you say, think of how am I doing the things. And I think that's like also where the disconnect comes from actually knowing how things should be done to implementing it because we don't have time to implement it. We don't have time to reflect to it. And we are like constantly in this loop. And sometimes we need someone like Paul coming in as an external to tell us how to do things, even if we know it. And I think that was also one thing that we tried to analyze. And also one thing that Paul said, oftentimes companies need to get someone external to tell them how to fix it. Well, why is this? People know how to do it, but they don't have the, they don't pull the brake. I have a question. Let's say you have learned something or you got reminded about something that you should do differently after a conference. Let's say, I don't know, not using paint, using Figma, something like that. Now you know what I mean. So how long are you able to keep up the momentum? Either I implement something new immediately or I don't keep up the momentum. And if you implement something new, are you still able to keep it up? Yeah, but I think then again, it's a little bit different also on different levels, right? My work is mostly focused around thinking about processes. So it is my role to take the time and think about it and to improve the way the organization works. That's actually a good point. So I do have more time to think about this. But if I think back in the days when I was like delivering interfaces, running research and everything in parallel, good luck trying to first of all, come up with new processes. And second of all, get everyone aligned, do some pre-wiring, a fancy McKinsey term, to actually get it implemented, to get it in place. We're also talking about change management, right? Because you have an organization that's running the wrong way, running in the wrong direction at the wrong pace. You need to change the organization. Absolutely. And the question is, how can you do that? Because from our observations, as well as our audience reaching out to us, the question gets always dropped. So what can I do as a product manager to make a change, right? Or as a product designer? Because for sure, it is a management topic, but still we tend to be the people who are at the end of the chain and have to do the work and get confronted with the things that are not working. So the question is, what can you do as an individual? I have the solution. We all quit. We all become consultants because as an external, it's easier to do it. Yes. But then you have a lot of competition. Well, that's fine. We can still cooperate with them. And maybe we make a good idea out of it and start our own company and fuck up the same things. No, I think one good way to start is, as you said, the moment you're going to come back from a conference, you're still back in this old loop, right? So you don't have time to reflect, or you have some changes you want to make, but you're not able to execute them because of not enough time, a lot of stress, pressure, or even resistance. So what can you do now? And here comes the thing that we also touched slightly in our last conversation, which I really liked talking about is influential product management. Like this little tiny baby steps and helping people to rethink status quo. Because you have many times the situations in meetings where people just discussing things that absolutely make no sense when you listen to it. And by asking dumb questions or by giving some hints into a new direction, or even agreeing, but still asking questions, even though that's total shit that someone is telling you, which doesn't make sense because you have data, trying to slowly make the change instead of pushing people and telling them they are wrong. We have to do it differently and taking time to make change. Yeah, I agree. And I just would like to add, I know, and this is also a little bit my fault. We keep to fall back and always talk about product management, right? But it's not only product management. I see the responsibility on, again, everyone's side, right? The designer, please feel the same responsibility to take baby steps and influence maybe even the product manager or the engineers. And at the same time, anyone in the organization should have that mindset, openness, and approach to working with people. And let's take an example from a design perspective, right? Let's say you are building a new screen and people tell you to design it with a standard iOS form instead of a form that you like and makes more sense and fits much better into the CI, into the whole design system and whatever, right? But sometimes you have to take the step and do the things you don't like, even though you can tell people what the consequences will be, right? So you can slowly start telling people or make suggestions for improvement for the next time, or warning people that certain things have to be designed in a way to speed up development speed. So there are many arguments that you can bring. I think it's even easier, right? When you're getting a task, you need to ask the same dumb questions that a product manager would ask stakeholders. You may be directing it to your product manager or maybe to stakeholders, because then again, it's up to you as a designer to understand, okay, if someone asks me to do this, okay, it already starts there that nobody should ask you to do a screen, right? You should be involved in the whole discovery process. But if that's the ask, you need to make sure that you have all the answers to the questions in order to be able to work on it. And if there is a request or a specification in the request that says, okay, it needs to follow X, Y, Z, ask why? Why do we need to use that framework? Why do we need to build that screen? And I think that will also slowly get people more into the right mindset of maybe not approaching you with a solution, maybe trying to pull you in earlier because the questions are relevant, and they need to be answered at one point. And then again, it's all about like also building the influence, building the trust. And it's maybe, as you say, in the first time you need to deliver something, and it's not perfect. But as you start delivering, and ask by asking the stupid questions and getting enough understanding, you start delivering more and more quality, and adding more and more value, people will automatically pull you in earlier. Exactly. I was just about to say that. And people automatically give you more freedom to deliver, because that's like your expertise. Yeah. And coming up with good questions, as you said, it is the start, and you have to just take a step back and maybe zoom out a little bit and try to see the big picture. And if you don't understand it, just ask. We're in a different age, right? It's not about being in a production line and constantly doing the job that your manager tells you, and tamping in and out your timesheet. It's an age where people need to think more, where people need to contribute, where people can have impact. And it's also a time where you should not be afraid of conflicts. Because asking questions can make people angry. It can lead to some heated discussions, but it's something that you also should be aware of. And what I'm always telling product people, it's part of the game. It's part of your job to have the conversation that you usually don't like to have. Yeah. And it's also about learning and having a conversation so that they don't escalate, learning the stakeholders and how they react. But I think... Thanks, Scott. We are having conversations that we like to have, Alex. Well... Let's talk about it offline. Well, with that, I think I'd be curious, when was the last time you asked why? Let us know on social media. Have a beautiful evening. Bye-bye.