The trap of building the first "solution"

Hi again and hi Christian. Hello Alex. Christian, last week we talked about everything from product development processes, why we're not applying them in the companies and how asking the right questions can help us to influence people. And as I was like cutting through the episodes, I started actually thinking a bit more and more about like processes and to analyze also processes that I've seen and how I've seen like people working. And I think there is another aspect that I wanted to add and it's probably worth having a short episode around that one, which is the aspect of, I would put it under the general term of like quality. But at the same time, there's a bit of a notion of innovation as well, thinking a bit outside of the box, trying to go the extra mile. And I'm just like throwing in a couple of like fancy terms that a lot of people would use in consulting presentations. But let me get to the point, especially in busy times and especially when there's people who don't apply the right processes. I think there is also often the case that product managers, product designers, engineers settle with the first thing that comes to their minds. And I think the first thing that comes to your mind is usually not the best thing, right? When I'm hungry, it is. Yes, because everything would be great in that case. I'm pretty sure you've seen this as well. You do, let's say you do a story mapping session with some of your people and then there's okay, a good process and people start thinking about it, blah, blah, blah, and there's a solution. And guess what? That's what they are going to implement at the end. And I think one thing that is extremely important to product as a whole and even beyond that, I would say even marketing or communication in general is and maybe you remember also back in the summer days in our design process, I always had this rule of you need to explore at least three different ideas before trying to head in a clear direction. And this is like really forcing you to go into different directions because you might be happy and maybe the different directions are bad. But this forcing you might help you think in different angles, might help you come up with different solutions. And coming up with different solutions will on the long run help you choose the better quality output. Help me understanding, is your problem that people do too much of MVP thinking? It's a bit of MVP thinking. Okay, let's analyze MVP thinking, right? Because you can say MVP thinking is, I would say first of all, misunderstood. Yeah, the term MVP is misunderstood. But I think like, if you ask me MVP thinking in this context, I would say MVP thinking in terms of, oh, yeah, let's just build it and learn from it as an MVP. So settling with a solution that could be better because you didn't think about anything else because it didn't take the time to think about something else because we will learn from this. I think it depends a little bit also on the state, right? I think as a startup with no product where you start from ground zero, so to say, I would support that way of thinking by taking the first thing that you can build and think about as fast as possible while in a multi-product company or in a running product where you have to develop features over features and enhance the product. I am fully with you that people settle way too early. Yeah, but even I think settling, it's not about taking more time. I think it's also, it's a bit about having a different mindset to the approach. And okay, first of all, you should try to go into exploration as open as possible where you only think about the product and how you can potentially solve it. But I think we often have the solution and I'm not saying that it needs to be more complicated or it needs to take more time or you need to take a longer time. It can be on a sketch level, on a flow level, on a very low fidelity level, but the saying, okay, I see this as a potential solution to the problem, but what are other solutions and how do other people solve it? Because I think even if we talk early stage and you want to build to learn, you will always be faster in a prototyping stage and in a conceptual stage that you can still validate with users before you build MVP. And if we look at the right definition of MVP, it should just be a prototype to help you validate it. It can be implemented, it can be a paper prototype, it can be a quick prototype from any tool of choice, but it should just help you validate the idea. And I think if you do MVP and lean startup proper, I mean, then you would just like iterate on initially a very low fidelity level of different ideas, but trying to go broad. Yeah, absolutely. And I think people tend to jump too fast on solutions if they either have too many data or no data at all. Elaborate on that. So I mean, the reason why people just accept, so let's say we do a story mapping session, right? So we have an idea for something and we come up with a cool, fancy MVP. So you have the line that you draw and you say, this is the first version, which is the absolutely bare minimum where we could already argue it's maybe settled too fast. So why is that happening? I think it's either having too many data in place by saying, okay, that's the only way to go. So we know the customer wants a signup form. I'm just making now a very specific, crazy example. So it has to be the signup form. It has to be in that way because they just want to enter their email address and their password and that's it, for example. Or the other way is, I have no idea what I'm doing and I just want to get the shit out of the door to gather data. And I think, as Buddha said, the path is somewhere in the middle. Yeah, the path is somewhere in the middle. Spending some time on elaborating more ideas. And on the other hand, also making sure that you do not overblow it because we also know that it can also turn into the complete opposite direction. You spend so much time on building prototypes and ideas that are not coming to the place where you actually build the product and start shipping. But I was just wondering, how do you think about the whole process of combining this prototyping with data and research? Because to me, it goes hand in hand. Yeah, definitely data and research needs to be connected to prototyping, needs to be connected to the validation and so on. But I think even one step earlier, right? Ideally, you go into process, you have data, you have insights from users, you have insights from different stakeholders, you have a request and that's where it starts. Often, there is a request, as you say, we need a sign up form. And I think it's about mostly in that time and in that time to try and quickly ideate. And if you think about also what makes things like design sprints or specific workshopping methods and methodology so great is because they force you into that mindset. So think about something, probably I once made you do some crazy eight sketching. Eight sketches, eight minutes. Bam, ideally diverse sketches, different ideas, right? Why? Because and actually quite interesting, like I think everyone also learned brainstorming at school, right? There is no bad and good ideas. You're just trying to generate ideas. And I think this is a step that so many product people jump because they don't think about wild ideas. They don't try to give them the space to be creative. They try to stick to the first idea that seems to make sense to them. And I think this is where I would just say it's important to take that time to also and also organizationally create a safe space so that people can actually try and come up with different ideas so that they're comfortable saying, okay, there is like 10 different ideas. Seven of them suck. Three are good. Which one do we go with? Maybe it doesn't need to be the sign up form. Maybe you need something else. Maybe you want them to write you a message. Maybe that's something where you get more out of it. But if you settle on the first idea, because it's the one that seems logical, you miss out on a lot of opportunities. And then you can obviously, you also need to combine it, right? Ideally, you look at what are possible ways other competitors solve it. How do other industries solve it? Like you can try to find like inspiration everywhere. And while this is something that probably a creative agency can do pretty well, when we talk about creativity in a space like product design, it often gets a little bit like in the background. And I think like just having these like open brainstorming sessions and to ideate more and to try to think about multiple solutions before committing to one, that will help you drastically improve the quality. And you ask, why are people skipping that part? You observe that people skipping usually that part. And I think we should be also frank to each other. For sure, the more ideas you have, the more time it will take to validate them or to prototype them or to build them or to test them out, which is not a bad thing. So we should be all clear about the fact that there is a time factor. But what I think is very helpful is to time box, to make sure that you not overblow it, right? Because many people, and this is one of my old bosses always said that, the German phrase translated badly in English, you should not die in beautiness. So don't try to make it too perfect. Set yourself a time box. There's always this nice saying, right? If someone tells you to clean up your apartment in three days, you're going to clean it up in three days. If you have three hours, you're going to do it in three hours. If you have 30 minutes, you're going to do it in 30 minutes. And it's the same with prototyping and idea evaluation. So make sure that your time box and you can time box it in any time you want, but make sure that you're not overblown. But just so that this doesn't get misunderstood by anyone, like the ideation exploration doesn't mean that you need to test all the ideas. It's like really more an exercise to make sure or to also validate for yourself. Did I look at potential paths and is the first idea that we had collectively really the best to choose? If that's the thing, and if you're coming out of that exercise and you say, okay, I still believe I should stick to the first idea, validate that one. I think it's like really more just like making sure that you don't miss out on a great opportunity simply because the first idea was more convenient and more comfortable. Like comfortable, like you sitting in your chair. Yeah. I think it's time for me to turn off. To prototype how fast we can go to bed because it's quite late here in Berlin. But I think, yeah, you made a point. Make sure that you time box and make also sure that you test what's most important. We always have more ideas than we can test and build. So it's about building the right things at the right time. And I know that sounds like a dream to many people, but you can always make that dream come true if you do something. So get started with thinking more about what you want to build and also giving yourself enough, but not too much time to evaluate. All right. I think with that, we can call it a day. Let's do that. And to everyone else, if you liked this episode, don't forget to share it with your friends, networks, colleagues, family, and leave us a thumbs up or a follow. Thumbs up to you, Alex. Have a good night. Bye-bye.