Product & Design Backlog Leadership

The new operating system that Apple launched, I mean, they changed a bunch of things, which is kind of painful, like system settings, completely different, can't recognize them. I'm getting lost in there, unfortunately. That's why I'm always waiting a little bit before I update. Yeah. But I mean, I think they won't revert these changes. It's not like Instagram, I think that the decision to go away from the system settings in grids to a side nav. No, but what I like is they really integrate the iPhone well. Now you can use the iPhone's webcam, the iPhone's microphone directly through Wi-Fi and stuff. It's kind of interesting. So I remember, I think it was in 2012, 13, 14, around when I was developing my first app with my friend, my first startup, we were always, so whenever we worked together, we were sitting in front of each other and we had like a very big screen next to us so that we were both able to watch the screen. And we were always struggling with being able to reproduce the iPhone on the screen, you know? So we bought an Apple TV and tried to set it up and apps and all that kind of shit. So it was super complicated back then. But I still have the feeling, even these days, it's sometimes not easy to, I mean, I know how to do it, but I think it's like, it could be better to be able to just stream your iPhone on your MacBook, for example, and then share the screen. Yeah. I would agree. That's, that's indeed something I struggle a lot with too. But I don't think they fixed the streaming the iPhone, but you should try the streaming the iPhone webcam. It's like, it's really cool. Nice. Nice. Anyway, how are you doing? Alex, I'm struggling. What are you struggling with? It's a topic where, I mean, I know you and I have been to your place. So I know that you, as a person who has like this eye for design and takes care of all this beauty in your apartment, has less struggle with me. But you know, I'm right now in the process of refurnishing my apartment and it's a nightmare. It's a nightmare. You know? So like, I think that the hardest topic is like to find the right lamps. So to be able to have like good light in your apartment, you know, I went to all those places. Yeah. I know. You are super strong. Lights are the single biggest or single most important thing in interior design. I know. I know. And that's actually the struggle that I have. Right? So I have like so many different things that I have to take care of. I bought a new couch, I'm working on the lights, I'm working on my sleeping room. So and like decorated stuff, colors and it's like, so I actually, I'm not kidding. So I said to myself, Christian, because you know, when I'm like in the zone and in the flow, it's like you start with looking at a lamp for my sleeping room. So then like 10 minutes later, I just realized, oh fuck, I need to take care of also lights for my living room. And then I realized, oh damn, I need like a new chair for my living room. So there are thousands of things. And the more you get into this process, the more ideas you get. So I was like, okay, what am I doing with all my ideas and all my creativity and everything that is popping up? So I said to myself, Christian, you need a furniture backlog. So I'm not kidding. I'm not surprised. Yeah, it contains also to do is like, talk to Alex regarding light. Yeah. Do you do your daily scrum? In front of the standups? Yeah. Yeah. I do standups. Christian, what have you done yesterday? What are you playing today? And what are your blockers? Is it like, what are you using like Kanban or are you working in sprints? So first of all, I just created a backlog and I gave it a top priority and I'm always working on the number one priority of my backlog. So you can rather call it Kanban kind of. But yeah, the reason why I'm sharing this is, so first of all, as I said, after this episode, I would like to pick your brain on my lightning situation. I mean, maybe maybe one of the fans wants to send you some lights. Yeah, that would be amazing. I just post my address. Yeah. Isn't your address in our imprint anyway? So all the lamps. I don't think so. Is it mine? Oh my God. I think so. Yeah. Well, if you want to send me some lamps, I can tell you the ones that I would like to have and that I still don't have. Not the cheap ones. Yeah, but the point is, I thought picking up the topic of backlog management is maybe not a bad thing because I remember back then when we worked together, the whole topic was not only related to product, right? As far as I remember, you were also in your design team doing a lot of backlog management. And I thought, yeah, it would be great to just chat about it and how you approach it. Because I'm curious to also hear that whole topic from a design perspective, because I imagine that there are a lot of synergies between product and how product and how design works. And I also want to raise the question, should there be two different backlogs? That's a very good question. And I think that's a question where a lot of people would have different opinions. But in the end, as you're saying, you created a backlog for your interior design or furniture tasks. I mean, I would almost say at the end, it comes down to organizing to-do's, right? You could also call it a to-do list, probably if you wouldn't work in product, it is kind of a to-do list. Fancier than that. Yeah. More enhanced, but yeah. Yeah. So I think if I think about backlogs, it's really more about, okay, what are the things that we need to do? What are the things that we want to do? And organizing them, prioritizing them, creating some transparency, especially when you work with more people. Interestingly enough, I'm currently also overseeing our new office project. So I do have a interior design backlog there as well. And yeah, I mean, for me, that's the main thing, but we can go into the weeds of how to set it up. But would you say that's accurate from a product perspective? Yeah. I mean, first of all, I fully agree with you, right? I mean, at the end of the day, you are maintaining the work that needs to be done in like a sort of list to say it very easy. But one question that comes to my mind, I mean, let's imagine the following scenario. So I'm a product manager, you are the designer of my team or team that you're collaborating with. And there are, let's say, I don't know, 10 tasks. Five of them are backend related and five of them are frontend related. So for the frontend related tasks, I need some designs or some design support from my designer. So my question would be, now you in your position, you would be eventually linked with your to-dos in my backlog, right? Or you know that you have to create designs for the certain tasks. So my question is, now from what you just have explained, would you have a separate backlog for the design team where these tasks flow into, or would it be rather linked? Or is where the backlog just for your design internal things you want to do apart from the product team? I mean, as with everything, I think we should probably start like with looking at the different kind of use cases or problems or jobs to be done, right? There is one that's definitely relevant, which is the working with a development team. Working with a development team that follows a certain process, that works with sprints, that works with a backlog, that works with scrum. Sorry, I have my dog. Your dog in your face. I just screenshotted it. Maybe we link it in the episode so that people can see the tail of your dog. I mean, the microphone does look a bit like a ball, right? So I think that's where he's coming from. I mean, he's bored with me. I love that. I love that. Not paying any attention to him. But so back to the use cases. You work with a team, Nemo, Nemo. He's so adorable. Okay, we will show the picture. Nemo, go to mama. Go. Do you talk Italian with your dog or English or German? A mix of both. The thing is, German works really well for commands, for some commands. For other commands, it doesn't. It's a little bit more too soft. So I try to pick the language that works best for the specific case. Which brings me to the use cases where we actually stopped. Sorry, I still need to get used to being a dog dad and the distractions that come with it. But yeah, working with a team, following the process of the team, especially in development, there is like workflows, there is processes that are fairly defined that you need to follow. And also timelines, right? Like with a sprint, what happens within a specific sprint? What do we need to happen in a sprint to be able to work on the rest? That is one use case. The second thing is obviously with a bigger team, the transparency of what is happening in the different teams. And that's then not so much on a scrum team level, but more on a design organizational level. What is everyone busy with? What are potential dependencies or potential blockers and so on? And then finally, you have a ton of initiatives that don't fit a sprint, that are maybe not directly connected to the development cycle and that are larger design initiatives or discovery initiatives. And I think for product, and actually, we can talk about this later if you see the need for something similar like that for a product manager. But I think when talking about research and development, and we talked about dual-track agile, we talked about discovery phases and so on. You have sometimes continuous discovery. You have projects that take longer on the discovery side, or you're working on a new strategy that's a longer task where research is involved and so on and so forth. So you wouldn't put them on the development backlog. So that means, yes, you do need a backlog specifically for these tasks. But ideally, and I mean, at least that's how I would look at it, you need to also mirror those developments, like the scrum team's tasks on that board, so that you can tick off the last use case of the transparency that we had. Because when creating transparency, you want to have the design tasks, the R&D tasks, but you also want to have the smaller individual ones of like, okay, what is my capacity as a designer or what is my capacity as a design team? So yeah, long answer short, I would personally go for different tickets and different projects, if you're thinking Jira. And then one board that kind of brings everything together for the sake of transparency. Yeah, and especially when it comes to the sake of transparency and also the longer ongoing initiatives, I think that's something where a lot of companies or product teams are struggling with, right? Because on one hand, you have like the ongoing development where the scrum teams, let's talk about a bigger organization, are demanding continuous input from the design team to be able to keep up the pace, to be able to fulfill all the tickets, match the definition of ready and whatnot, right? But then at the same time, there are these longer ongoing topics like being able to facilitate research, to make sure you plan upfront because life is not only happening in two weeks, right? So you look further, you plan for the future, and you also need to test things to make sure that you build the right things and you may be throwing something away. And I see this as a big challenge. And the question that's coming up to me is, when it comes to representing transparency, I think that should also happen like on a kind of roadmap level, right? So on an OKR level even, right? So if we know within a quarter we are planning to deliver XYZ features, so this should be not only reflected on a sprint level, but also looking forward when it comes to pre-planning and then being able to fulfill these bigger goals on a longer period of time that, yeah, people need to keep track on what's going on, right? And I think having a design team, particularly, that is tracking that outside the sprint is also very helpful because back then I had this very idealistic imagination of everything needs to be tracked within sprints, but especially research tasks or design tasks, I think it's hard and I think it's sometimes not worth it to put those into sprints, you know? But we also used product board for quite some time, which is to some extent like solving that transparency or like planning on an initiative level or an OKR level or on a strategic goal level. I think product board or even Jira, I mean, you can also represent many things in Jira, I think this is rather the visualization. I think the first step is to have a place where you as a design team, where you as a scrum team, where you as a product team track the things that have high priority and that are connected and related to the bigger goals like OKRs, company vision, roadmap, etc. So I think that's where it started. And I think that's where many questions arise within teams. So how are we handling it? Who is doing what? And where can I get information as a stakeholder, as a design lead, as a product lead and whatnot? So what I have just learned or what I believe over the last couple of years is that it is important that every team works in their best interest and should also, in a self-autonomous way, decide how they want to keep progress. But I think it's also important to bring each of those pieces together and make sure that you have a common source of truth. And product backlog, for example, can help to be able to collect all those inputs and visualize it in a nice way. Yeah, no, I think that's definitely true. I mean, especially when it only comes to visualization. I mean, even we now, we use product board for some time. It's so fucking expensive, right? Yeah, yeah. Unbelievable. Overpriced, in my opinion. I would say that's also the main reason why we switched back to Jira and the roadmapping feature of Jira. It gets better. Usually Jira doesn't get better. But I mean, that's back to learning from others, learning from other tools, from plugins and so on. Your idea. I think it also comes down to how you use product board. When you actually use it to prioritize features and things like that, it's a different story. It's very powerful, right? But when it's purely about the visualization, yes. Do it in Mira, do it on Excel, wherever you're comfortable with, right? But what I'm still curious about is like, it's not only design that sometimes has these tasks that don't necessarily fit a sprint, right? I think even within product, and I mean, we talked a lot about it, it's a pretty big overlap in tasks. Product managers do also a lot of discovery, they participate in research, they write documentation, they do some desk research, right? How do you usually recommend a product manager to track these? Obviously, everyone has a to-do list, but I mean, I always feel like designers really like the idea of having this strong community feeling of, okay, I'm part of a design team, that's why the transparency is important, why the sharing is important, we constantly give each other updates, like we use these tools. How do you solve this in product? Is it something you do similar? Yeah, so I would say it depends a lot on the organizational structure and the way a product team is structured. So let's say if you have very autonomous teams, you rather work in your kind of isolated area, even though you always have these dependencies to other teams. At least, I generally see in design, there is a bigger dependency than in product per se, because in design, we have a design system, design guidelines, a lot of aesthetics that need to be aligned across... Exactly, exactly. So yeah, 100%, right? So there are a lot of dependencies and there's a lot of involvement between different designers, a design lead. It's also related to branding, CI, and I could go on for hours, right? I mean, you know that much better than I. But it's actually interesting that product isn't really then tracking their tasks. Also within a sprint, they're not saying, oh, write the documentation for this. So that's actually the interesting part, I mean, per definition, a product manager doesn't track their work. They usually don't track their work. But I used to work in an engineering team that told me, hey, Christian, we would like to see what you're doing. Could you please start adding tasks to the sprint, right? So to be able to provide more transparency. We did that for a while. Yeah, we did that for a while. I mean, I'm more than open to try things out. But then at some point, we also realized, I mean, the engineers realized, okay, we're going down because we didn't estimate those tickets. And then they just got annoyed by all the tasks that I was putting into the sprint. But yeah, this is not the case. So product people usually don't do that. But if we talk about a product organization that is also very engaged and strong working together, it's also helpful to have a product backlog where product managers keep up their work and involve that, for example, in the daily or weekly product meetings and product stand-ups. So I have seen many things. And I have to admit, it really depends on the working style and also the leadership that is happening within the product team. I think things are more loose or more open to be tracked and defined while in design, you have so many dependencies. I don't want to say rules, but things that need to be applied and need to be discussed that it's more needed than in product, in my opinion. Yeah, and I'm happy to hear your feedback. Maybe you are pissed about the fact that product is not tracking enough what they're doing, which I can also understand. It's actually the first time that I think about it, right? But it's also, I think it comes from a place where I mean, A, the designer is in fact also closer to shipping the actual product when it comes to, I mean, design specs, the engineer needs to follow them. There needs to be communication around it. There is the QA-ing and so on, while the product manager works generally across the process and is pretty much helping also structure it. And then back to also designers really love to share. There is a lot of critique going on and so on and so forth. I mean, we do try to implement more of these things now also in our whole product organization, right? Like we're now having solution meetings and problem space meetings where PMs and designers can bring the topics, right? I do think that there is transparency is good. I do think that it's also good, especially on discovery and R&D to have like the transparency to the organization of what's currently happening and not only large strategic goals or OKRs, right? Like it could be that mid-quarter something comes up which is feedback from users or which is input from a stakeholder and you want to investigate it. Now, of course, this takes some time out of you. This takes some time out of the designer. This potentially takes time out of the engineers or at least the lead engineer or engineering manager who's definitely involved. So these things should be there. And what we have implemented is an idea backlog that can also be prioritized, which, of course, there is tasks that need to be done based on OKRs or the strategy that you have set, but you also want a way to track opportunities, problems, and so on that come up throughout the normal continuous development process and discovery process. You want to include also ideas from stakeholders and so on, and you want to constantly be able to prioritize that backlog based on the size of the opportunity and the impact and then do these smaller discoveries that should be very quick and ideally finally get them into a sprint backlog. Two things. Two orders. Yeah, exactly. Two orders. I think the whole idea backlog story, the topic that you mentioned, I think that's something that we should put into our backlog for another episode because I think it's worth having an episode just about idea backlogs. But what I want to add on top of that is the things that you have explained right now, like the stuff that comes in, the ideas that people bring in to be able to prioritize this together, I think that goes way beyond backlog management and we're rather talking about culture here. Fair enough. And I think that's super important because the things that you mentioned do require a culture that is open for feedback, that is open to have transparent communication about issues, ideas, improvements and regularly sitting down, discussing and prioritizing it together. And I think, if there are people out there who are having this and applying this, please reach out to us. We would love to interview you. Awesome. Well, I mean, I think we have some follow-up topics that we can pick up. Yeah, 100%. I think we rarely write them down and there's probably a ton of other stuff that we would still have to follow up. So if you're missing a follow-up or something, also reach out. Nevertheless, click follow and subscribe on your favorite podcast tool or go to our website, like the old school guys, similar to me. I need to get rid of my boomer reputation as a proper millennial. But yeah, it was a pleasure, Stronky, to see you and we talk again next week. Exactly, Alex. Looking forward to it. Bye-bye.