Stop Solutionizing & Start Problem-Solving

Hey Christian. Hey Alex, good to see you. Good to see you too. Unfortunately, everyone else only hears us, so we're still hiding our faces from the public. I mean, you can see them. I just updated my LinkedIn profile picture. I have to update mine again, too. And remove this fucking NFT picture. Oh, fucking NFT picture. Yeah, I mean, at least this one is worthless. Why is it worthless? Well, Alex, I mean, what's... Wrong speculation? Yeah, definitely. Too much gambling. Well, I mean, at the end, we all knew that NFT has some gambling involved and it needs the network. But we're not here today to talk about NFTs. I know you like the crypto topic. And we already analyzed it quite often. I have a question for you today, which, I mean, we're now doing this podcast since how long? I think it's almost two years now, right? Exactly. In September, it will be two years. Celebration episodes. Celebrate good times, come on. We can think about some goodies for our anniversary. Yeah. I mean, we're doing this podcast since two years, right? And, well, we're also been around in product since quite some time. We've seen conferences, we've read a lot of books. And, well, I think everyone working in product has, well, a certain level or basic understanding through education, reading blog posts, and so on. I mean, there is definitely enough accessibility to information. And I feel like I've talked to a lot of people and everyone knows, or everyone is a bit wide. We know not everyone does. But most of the people have an understanding of, okay, actually, user centricity is important. Focusing on a problem before then jumping to the solution or working on the solution is important. And so on and so forth, right? We all know the processes, we all know double diamonds, we all know discoveries, research. So the one thing that I'm always surprised, even like in kind of mature organization is how often people actually skip these steps, right? I mean, why is it so hard for people to apply the theory to the practice? Why are they not like defining a problem statement, but immediately like working on those wireframe solutions and so on. And I'm talking about like designers the same way as I'm talking about like product managers. And everyone complains that they are not user centric enough. But still, they always start working on the solution first, right? What is the problem? I have no idea. But I mean, I'm always jumping to solutions, Alex. So don't ask me. But I'm probably not the only one who is surprised by that, right? But I can totally feel you. Because I mean, again, right, every source on this planet is out there to be read, watched by people, but you still see over and over the same. I mean, let's face it, right? The same shit happen. Yeah. Just in different ways. But why? It's like, I mean, I've talked to a company, right? They want to talk about processes and so on and so forth. We talk about it. We talk about how to generally structure the design process. They have an understanding, they have a feeling. But then we talk about like how they work, or what they are currently working on. Oh, yeah, I'm working on this feature. And what's the problem behind it? So I really don't get it. It feels like you need to constantly remind them about the basics, because in the actual work, they forget about it. But just to be clear, I mean, there's a difference between the outcome and the process, right? Because sometimes, even though if you do the best research in the world, sometimes shit happens and people don't like using the features. Oh, yeah, absolutely. But what we're talking about right now is the process, right? By making sure that I'm starting with the problem first before I jump into a solution. I just want to make sure that we don't mix up things. No, no, no, absolutely. Because if we talk about that problem, I mean, just from my experience and what I'm observing when I'm working with companies is, I see the problem happening on two layers. So on one hand, you have like this hippos walking around, so high paid person's opinion who say, I need this. And then you have like a couple of minions who just say, okay, we're gonna do it because I like my boss to think that I'm productive and do whatever he or she wants. And then at the same time, there are also companies where this is not happening, where you have like good leadership teams, clear visions, clear OKRs, whatever. And they are just people who don't know the craft and just start doing something. But I think in some cases, they even know the craft. I'm not sure if it's then laziness, if it's like being overly optimistic about their own intuition and skills, but it's just like so easy to write down a problem statement. Man, problem. It's like I'm sometimes, like I'm really sometimes surprised how much forcing someone to then think about a problem statement, even if they know they have their perfect solution in mind, helps them go beyond the solution that they came up with. I think maybe so. I mean, it's tough to answer, right? And I think it's kind of individually for each company, but I think it's also connected to a third layer, which is culture. Because I mean, you know, I mean, there are also good product companies out there who always start with a problem statement first or who always start with looking at data because it's part of the culture. So if you haven't, if you don't have an established culture that ideally gets also formed and shaped by the leadership team, you will end up having people who, I mean, maybe even if they know the craft, some people are sometimes getting overconfident, right? Or they're just forgetting because they're in a rush. But if you have a healthy culture, it should remind people on a regular basis to not forget about these things. Yeah, I feel like it needs to really be like also the group, like everyone enforcing these processes or these like steps in the process, right? And you know me, right? I don't think you need to have a process and to follow it like a religion. A process is some sort of like a guiding direction. I don't think you need to always follow the same steps. The work usually doesn't always fit the same framework or the same process. So you need to be able to adjust. But I think it comes down to, okay, I start doing something, what is my mental checkbox of what are the things that I need to make sure that I can deliver the best solution? And part of it is like checking off some steps of the process. Do I have some data? Do I have some information from the users? Do I have some interviews? Can I do, what can I gather some additional information? Did I look at some of the patterns and solutions that are out there? And do I have like a clear defined problem statement? But yeah, it's I feel like, I mean, obviously, a lot of people working in product work under a lot of pressure, they have a lot of deadlines, they have a lot of like goals they need to meet. And I feel like it's also a little bit related to this right of like, okay, yeah, I'm just again, in execution mode, execution mode, execution mode, I'm pushing the things out of the door. That's why I'm not taking the step back to really think about these things. And if you force them to, actually like it with very little effort, you can get out a lot more. Yeah, but also, I think it's also like the perspective on doing research, looking at data and asking the why and checking out the problem. Because, you know, I mean, many product people think that it costs them too much time, and everything else will fall behind. So but the problem is, if you are like in this execution mode, where you always trying to get something done as fast as possible, you will never work ahead, right? And the idea of also working with a problem statement, doing proper research is to always work ahead on things and prepare things and plan things, which will then save you time during the execution phase. So I think also like this mind shift is very important to understand. Yes, at some point, you have to go the extra mile, right? You have to focus on your current sprint, and you have to prepare the next one. And even crazier, you have to prepare maybe the sprint after the next sprint. So which is like four weeks, if you do two week sprints, I mean, oh my gosh, right. But the thing is, once the first sprint has ended, the next sprint is already, let's say 80% prepared. I mean, how crazy is that? How crazy is that? And ideally, within the first two weeks, while you are in your first sprint, you can finish the other 20 missing percent in that sprint to make sure that the next sprint is ready. So you know, but the thing is, if you are always busy with answering questions during a sprint and finalizing designs, specs, and whatever is needed, you will never come out of this execution slash emergency mode. Yeah. I mean, let's, let's try to make it practical, right? I think there's two things that we can that we can talk about. One is actually like, what are the steps that can help one to always improve and like push for the right quality through process. And one could also be like, I mean, I started coming from problem statements, because that's something that's currently a little bit like on my, on my chest, and I had to get it off. It's your problem. Problem statements are my problem. But it's also a bit like for me, when, especially when I talk about like these problem statements, or the problem focus, it's also the question how to escape the feature factory mode, right? Because I do understand when, and there is no bad intention behind it, when stakeholders approach you with, hey, we need to build X, Y, Z. But I think there is two ways on how to approach it. One is, I come in, and I try to, and I just build that feature. Or one is, I try to understand why stakeholder X wants this feature, and what problem he's trying to solve. Because by asking this one simple question, it helps me to a take a step back, understand why we are, why this has been proposed, and then think of what are potential other solutions that we can build. A, faster, B, better, C, in different iterations, D, in order to test it or to validate it, and so on and so forth, right? So, I mean, it is kind of a fundamental question that also helps you getting out of this like feature factory into a more proactive way of product development. But I think like what you said, also around the different steps and planning more ahead and discovering and so on, maybe we can talk about the steps that one should follow to achieve that. Yeah, I mean, so I mean, I'm generally a big fan, whether you are a product manager, product owner, product designer, is, I mean, you need to have like a kind of backlog, right, on things you plan to research or you plan to build. I mean, feature factory is one thing, but there are also like technical things, database updates, whatever stuff that needs to be done, right? And I mean, as a product person, you are always, you know, working with all those different things that needs to be done. And especially on those bigger topics, like features or problem-solving technology, I think it's important to have, first of all, the backlog and to make sure to communicate that backlog, which is ideally not only built by myself or by the designer, by the whole team, to the leadership team by saying, hey, these are the problems we've identified and they are in line with our roadmap or with our OKRs or even not, and we want to change that. But in order to be able to change something, you need to have something in place, first of all. And I mean, product people should have regular chats with their product leads. So I think this is where it starts, right, on a strategic level. And once you agree on something, I think the most important step is to take the highest priority project and start doing the research and sitting down with the team, explaining the problem we want to solve, talking to the designer, initiating whatever is needed, right? Whether it's looking on data or talking to customers or maybe do a prototype and try it out in the real world. We can go very deep now, but I think the most important thing is to have something that you want to build and to start communicating that to the upper management to make sure we are all on the same page. I think that's the most important step. And another question that I have for you is actually because we're talking a lot on the individual contributor level. What can leaders do to guide their team or to even, first of all, no, let's forget about the team. What can they do to make sure that they don't fall into this trap of also asking the team to just build features? That's already the answer. Try to not formulate solutions. No, but I mean, it's as simple as that, right? And it's like education. Is it? No, it's, but I would say yes. I mean, it's like also something that I have to do when I talk to my team and when I talk to like, I also need to force myself to not hand them a solution because I also might be wrong. What if I'm your boss and I'm telling you, Alex, hey, we need to have this new Apple sign in feature on our website. Alex, your team needs to build it. I need it by the end of the month to show it to the investors. What would you do? Cool. I'm happy to help you with that feature. Maybe you can help me better understand what exactly you're trying to achieve by that. I don't have time. Just make it, make it until the end of the month, Alex. Believe me, I can be a pain in the ass. You will find the time. No, but I mean, that's a perfect example, right? And I think we both have experienced such conversations. And I think, as you said, right, especially there, it's important to take a step back and just ask, hey, I do whatever you want, but first of all, tell me why do you want it and what's the problem you want to solve, right? Asking the simple question as you said, it is that simple sometimes, but I have experienced even by myself in the past as an employee that I was worried about asking that question. Yeah. And I think this is a question though, that nobody should be worried to ask for because I think it's, let's invent a name. It's like a bit of a boomerang effect where if you ask the question, you're probably able to deliver a better solution and it will come back making the stakeholder happier, right? So I think on every level, you should always be able to ask this question. And I'm also telling this like, not only to my product people, but also to the brands and the video people, right? It is like really important to understand the why of a request, like why is someone requesting it, right? I mean, I think you also asked me like, what happens if my boss would tell me to build this feature? Being in a different position, I think it's also on me to then educate stakeholders to not only like ask them for the why and trying to understand it, but also educate them and ask them to not phrase solutions when approaching a different team, right? To be like, okay, cool. I get that you want to do this. We shouldn't approach the team with the feature, but you should like really think of like what the problem, and there we are again, what the underlying problem, and problem also stands for opportunity, what the underlying problem is that you're trying to solve, because you have a team of experts that works on that specific product area, feature set or whatsoever, and they can come up with better solutions. And the more freedom you give them also to be creative and to come up with it, give them the problem that they need to solve, or give them the goal, also in terms of like goal setting, like what do we want to achieve? If you have a timeframe, give them the timeframe and let them come up with a solution that they can build in the timeframe. And that's one thing that I think that I just want to add for Lida is also important. If you give your team the space to figure something out, to define a goal and to give them also like time to research and to identify opportunities, it's very important to do it within a timeframe. So, right, it's not enough to just tell your team, hey, we want to build something new here, please do your research. And then just wondering after one week or maybe two, why you haven't heard anything back. So I think especially as a leader, it's important to say, hey, let's do this. What do you think about time boxing it to one week or maybe two? And then also negotiating and discussing with your team members to find a timeframe that is fitting for everyone, but not setting any timeframe and just expecting something is also not the right way to go. And it's happening quite often. I can definitely sign that. Talking about time? Time boxing, we're ready over our time box. 15 minutes. But I think the 20 is still okay. Yeah. Guys, if there is any questions or any ideas on how to solve this, or just like your approach on solving or on bringing in problems into your product development process, let us know. Happy to pick it up again. Feel free to invite yourself. Awesome. Christian, it was great talking to you today. Have a nice day. Have a good day. Bye bye. Ciao.