The Product Development 101

More important than that, we talked about product discovery, we had a guest who pretty much followed that whole theme. Now, as you know, obviously, it can't stop with the discovery, right? So at one point you also have to build stuff. So if you have to kick some asses and you need to get the product out of the door. Who you gonna call? Christian! I mean, I know having worked with you, I know you're a bit of a magician when it comes down to the whole Jira setup and so on and so forth. And you've usually, you usually were writing the best, you've usually wrote, you've usually wrote the best tickets. So two things that come to my mind, D.O.D. and D.O.R. and that's what I pretty much want to talk to you about. For some reason, I'm not feeling honored by you telling me that I was writing the best tickets. I mean, that's one of your core deliverables. It's like me being offended if you would tell me I made the best Figma files. Okay, it's true. It's fucking important. You're right, you're right, you're right. Well, so first of all, as you may hear, I'm a little bit sick, but yeah, still able to talk. So if you're wondering, my voice is a little bit, I don't know, how's it called in English? It sounds different. It still sounds beautiful. And actually, now that I have this beautiful setup here, I mean, it sounds much better than If I would click this. Yeah, so first of all, we need to let the audience know that Alex is sitting in front of his, in his office with like, I don't know, is it 60,000 euro equipment that you're using right now? No, it's not. No, let's not, let's not talk about prices. Yeah, good. You're right. However, product delivery. So I have to admit my, my point of view on product delivery has changed a lot. And I definitely don't want to talk about Jira today. But as you said, right, at the moment, the product discovery kind of ends. And I like to say kind of because we know it shouldn't end there. You move into the next phase of delivery. Yeah. So, and when it comes to that, I mean, there is like, you know, some people, some companies do waterfall, some do agile, some do scrum, Kanban and all that kind of stuff. And I have to admit that I'm, DOR, DOD is particularly tied to scrum, for example, but I'm moving away from that, you know, so I think like, having a common sense and a common understanding of how you want to build software is the most important thing to me. For sure, like frameworks like Kanban or scrum do help to have like this kind of, to set this kind of frame where you work within. But overall, I think like having a clear idea on how you want to develop software, ideally defined in a simple and lean process is what, what brings you to your goal, right? Delivering good software that has been validated by good discovery. So yeah, and I think this is the first thing I would like to share instead of thinking too much in frameworks or nitty gritty processes and Jira setups, the core question should be, how do we want to work together? How do we want to deliver something from an idea to production? And I mean, because you just mentioned at the beginning, the definition of ready and definition of done, no matter what kind of framework you do is to me like a good way of having a common understanding of what needs to be in place to be able to start delivering software to developing software. For example, definition of ready, what kind of information do we need to have in place? Bring us back to the good tickets. I mean, you need to know for whom you're building something, you need to know how it has to look at the end of the day. And I mean, if your ticket says upgrade database to whatever, I mean, what database, which programming language, what kind of metrics do you do you want to have? So being specific when it comes to product delivery is very important. But in my mind, it's like really more of a sanity check or setting a bit like the guardrails and the rules for the game to just like, make sure that you don't forget about anything. Because like I think we're like in this mode of like building and shipping and so on. And the longer we work for a company, the more we also think that we understand everything that we know everything. So we tend to say, okay, like I have this great idea, let's just build it. And I think it's at all levels. It's like the product manager that might have this approach. It could be the leadership, it could be the designer, or maybe even down to the engineer. Right. And then making sure that you have like this one step when it shouldn't be like something that extends the process, but it should be this one step that makes you think about it. And it makes you like reflect, okay, did I actually think about this? Did I think about that? Did I think about that? Okay, now I know I'm actually ready to move forward. Yeah, totally. I fully agree. I mean, let's assume that the engineers, product managers and designers do product discovery together. And the question is, do you even need like all this kind of things we just talked about, or you just go with it because everyone has the same understanding. But still, I mean, from experience, teams work together. And no matter how aligned they are, you tend to make mistakes, you tend to forget things. So therefore, it's as you said, good to have like this checkmark item list in place to make sure that things are there to be able to start developing something. And even with the most experienced teams, and even after like a long time, and if everyone's involved, I still think that it's important to have like these checks that like help you like also reflect on it. Like I can only speak about design, right? And in design, one thing that is very important is ideation, right? I mean, we talked about the double diamond when it goes broad, I'm not going back to that. But I think it's like, generally speaking, you want to try different things, and not do the first thing that you came up with. And that's true for product, that's true for engineering, and so on and so forth. If you're trying to come up with a new solution for your architecture, well, you probably look at different things. If you want to onboard a new provider, you probably look at different ones. I can tell you even the most senior members sometimes forget about it because like just like in the process, they're there, they build something, it actually works. Maybe even in the conversation, there is like this group bias involved. And if you then don't have like this one check that makes you sit down and reflect, you miss it. Totally. But here's the thing. I mean, all the things you said, right, when it comes to evaluation, and also research, and checking out multiple options, once you start developing something, these decisions need to have been made, right? And that's the point, right? The moment you start developing something, fun time is over. Because we're moving into a development process, we're planning to ship something to production, we have engineers who are using their limited resources to build one particular thing, which means things have to be in place. So I mean, discovery wise, we covered that last episode. Here we're talking about the checklist, the so definition of ready, I mean, if you want to use that term, that helps you to make sure, okay, we have acceptance criteria in place, we have a testing plan in place. If we need to migrate, we know how we want to migrate the customers. We need to have cohorts or whatever is needed to be able to get this thing smoothly live to production. And that's something that you need to have. I mean, if you're not following standards, and I'm a big fan of having good standards in place, you will fall into the trap of repetitively doing mistakes, ship poor quality to production. And you know, I mean, we can write a book about it, but there are already enough books about it, if you mess up this kind of beginning, beginning of the development process, actually. And the worst thing is that if these things are not in place, you have to spend your valuable time as a product manager or product designer, or even both to work with to correct your mistakes in quotes, or to work with the team on things that should be clear already. So which means you don't have time to do discovery or other things. Yeah. So therefore, you need to start clean. And it's sorry. And I think there's actually a lot that one can learn from the setup you would use like for development for all the different stages and for all the areas of the company, right? 100% I mean, at the end of the day, whether it's product development or marketing or customer support or sales, having a clear, clear, having a clean process in place and knowing what you want to do, and fulfilling standards that are high or that are clear, at least and aligned also is key. Man, you mentioned marketing. How many briefs will I see in my life of marketing teams that are literally just like not? Well, they just don't have these processes in place. They don't have a definition of ready. Right. And I think like there it's important to set the same standards that you just described. Yeah. And the problem is then they start doing something, right? They starting a campaign and then they realize, oh, we don't have designs in place. Let's reach out to brand design and request something. And you have already a big backlog of thousands of other things that you cannot do. They start getting mad. They escalated to whoever CMO or something like that. And you just produce shitloads of new follow-up meetings with delivering nothing, right? Yeah. But however, I mean, we can complain a lot, but today's focus is the product delivery process. And from discovery, you need to have, you need to make sure that you have like a clean project planned based on tickets, epics, however you work. And this goes to your backlog. And within the backlog, you need to make sure that, as I said, the definition of ready is matched and then you prioritize. And after things are prioritized, you start implementing. It doesn't matter what kind of framework you use. And here's the thing, something that I believe is very important is that a classic delivery process contains things of like having the backlog, prioritization, implementation, quality assurance. And then something that may not happen in every team is release planning, UAT, which is user acceptance testing and go live for sure. And this is where most of development cycles do stop, but there's one important step that follows afterwards. And I'm talking about the step of the post-go-live or post-implementation part, because once your feature is live, the development cycle hasn't ended, right? Because you need to monitor, you eventually migrate, you have critical measures that you need to make, and you also need to monitor the impact of your product, right? I mean, after you have developed something, you want to analyze whether it was worth doing it. You need to check if the customer base is increasing, revenue is increasing. And this is, in my opinion, something that circles back to the beginning of the product discovery cycle, right? Because you have new data and based on new data, you can start doing new hypotheses, new assumptions that you can validate and the whole stuff starts again. So that would mean like tracking event definitions and so on that need to be part of the definition of done before someone can close it off and move to the next topic? I would say it's part of the definition of ready already that you know what you want to track and having it tracked is point of the definition of ready, definition of done. And it's also something that we just discussed in the product growth episode with Adam, right? So you need to know what you want to track at the end of the day. And now... How do we measure success? The only problem that I have with the definition of done now is that by the nature of product development, you're never done, right? So the second you're now shipping this, you're going back to the tracking. So the definition of done just like means, okay, this is now when you can release something, but then the cycle starts over again and you need to make sure that you also continue tracking them. Don't fall into the trap of saying, okay, yeah, I mean, we're tracking everything. We have the data. I'm doing discovery and some other stuff. This is released. So I put it on the shelf and I forget about it for the next 10 years. Yeah. I mean, definition of done in terms of version 1.0 or the MVP, however you like calling it. Yeah. MVP. Let's forget about the MVP, please. The minimum viable product or the minimum viable service, actually. True. Yeah, but that's the point, right? I mean, I see many times that the whole post-go-live part, including circling back to the product discovery part is something that people miss, but they have launched it. Goal was fulfilled. There was like a little celebration party in the office. We have launched a new app. No bug tickets. Let's move on. And this is actually something that, yeah, for sure you can do, but the question is, what's the impact? And impact is something that is just super important, especially in the times where markets are changing. The current situation isn't easy. So you have to be sustainable. You have to make money. Revenue needs to come in from somewhere. And for that, you need to have clear measurement criteria in place. And even though we're talking about a product delivery process, right? I mean, the whole product management work is reflected in what's going on once you develop software. Yeah. I mean, I couldn't agree more with everything that we said so far. And I think, I mean, I couldn't agree more with everything that has been said in this episode. And I think like we probably hit the definition of done for what should go in a recording. Let me quickly check the list before I approve. Ah, yeah, you're right. No, there's one thing we missed. What did we miss? To remember our audience to press the follow button on their favorite podcasting tool. Thanks, Gart, you're riding beautiful tickets. Well, Alex, thank you very much. Thanks a lot. See you all next week. Bye-bye.