Forming & working with task forces

Welcome product people. Today I'm here again with Christian and we're again chatting about product topics. Christian, how are you? What a coincidence. Yeah, strange. Maybe we should make this podcast more about holidays in the future, but Holidays, crypto, politics, so many nice things to talk about, but we stick to product. Yeah, so product in mind. How is your coaching going at the moment? What is like the topic that most companies are requesting? If you remember three and a half years back when you and I worked at SumUp as design lead and product lead, there was a phase where we had this big topic of redesigning our apps. Do you remember? I think it's still not completely done. I believe a redesign is never done, but something I was just faced with again was the whole topic of forming new teams and forming a task force. Yeah, it wasn't an easy decision on how to roll out or how to actually work on the whole redesign or design system with the team setup that was in place. How do you develop such a thing with product teams that are split across different parts of the journey? So what's the answer? I think it's a good topic to talk about and to provide some context. Back then, we wanted to redesign our apps and there were many things going on. So we had multiple cross-functional teams. Back then, they weren't that cross-functional. Not every team was equipped with a mobile engineer. And we asked ourselves, okay, should we take time to hire new people or should we take the given resources, even though I don't like the word, and form a small task force that works across the other teams, has the power to make certain decisions and being faster in finalizing the scope and the project instead of wasting too much time on continuing and finishing setting up the new teams. And that was a big challenge or a big question. So to answer your question, what's the best way to do it? I don't think there is a silver bullet, but the way we did it back then, I think was according to the circumstances we were in, quite good decision. And I just thought we should talk about task forces in general and how to set them up and also the pro and cons by just getting started with something like a cross-functional team or a domain-specific team that focuses only on one thing, because the main idea of a task force is a limited scope. So like a cross-functional team has their mission, they have their product they're owning and they're working on while a task force is really made to do something, to succeed ideally in something, but then also getting dissolved and bringing back the old state by having people in teams instead of some team that just owns the design, right? So when would I in theory create a task force? Well, in the perfect world, you never need to, but that's not reality, right? So sometimes, as I've mentioned, you are in a hyper-growth phase, you had backend and frontend teams or domain-specific teams that worked on certain services, but you realize, okay, we need to start becoming more cross-functional and letting teams work more autonomous. And yeah, we wanted to urgently redesign the app because we got a lot of customer feedback. I think we call the app sometimes our Frankenstein, because different fonts, different sizes, a keyboard that was not intuitive enough. So there were many customer problems. I mean, it's the normal like growth pain that a lot of companies have, right? When you start out trying to figure out how it should work, building some MVP to proving that it can work. And then at one point you realize, oh, it's actually working. We have actually a lot of people who are using it. Now we need to fix it. Yeah. And there's absolutely no, no blaming about that or no shame about that. And back then we had this one app team that was owning the app and working on the app. And we thought, okay, maybe we take a couple of those people who have the history and the knowledge, stick it together with a product person and a product designer and give them the power to work out, redesign, to prototype it, to test it with customers, and then start working on it. And the big challenge and the big downside I remember as a product manager was we had, I think, 11 different teams who owned certain part of the app for, and we were, yeah, actually lucky or also in the hard position to make certain decisions and work on their domain. So there was a checkout team. So we needed to redesign a checkout, obviously as well. There was a team owning the referral part, the sales history and many things. And that's something that can make things very complicated and complex, and it can also slow you down if you have to talk and to align. And that is definitely something where I warn every company who's planning to create a task force, because what you definitely need is a clear communication to those teams and also a buy-in because giving people context and telling them, hey, there is right now no engineer in your team who can work on the iOS app or on the Android app. We have a task force and those people are making certain decisions and working out suggestions based on hypothesis. So that's a base that people need to understand first. And what I did, and it was something that I've learned from enterprise business back then, I scheduled with every product manager and also with their team's meetings regularly and discussed those things. And something that I want to share with everyone on the planet, if you do that, so there was one like silver bullet that helped me making sure that it's not going out of hand. I documented every meeting and every action items and every decisions we made in conference and I tagged the people. So to make sure that once we start implementing it and once you start implementing something, you have stakeholders. People forget something and they're not sure anymore about their decisions. And this is the point where things start getting slow and where you start getting angry, where politics start, where people get emotional. And I think it can be very helpful to, once you have made certain decisions, to share with people, document it, tag them, send out an email again, be like this bureaucratic person who is like documenting everything. But it's also at the end of the day, your insurance to avoid hiccups and going crazy. But still, even if you document things like people might change their minds or there might be new information in those teams and they might ask you to change something. How do you deal with that? Yeah, that definitely happens. And it's not easy. But the point is you always have like this time and effort that you need to evaluate. So if, for example, a checkout team is just working on a new feature that they have to launch, for sure you need to adjust. And if you have developed something, then you need to adapt. But usually, and that is also part of the product manager, for example, is you should know what they are planning and you should try to be ahead. For sure, if there is like a bug that forces teams to change something or a new law that comes out that makes things more complex, then you are in the boat, you are part of the game. However, the best way to avoid it is making sure that you share the roadmaps or that you get the roadmaps from the people and know what's coming up. And still, if sometimes people just want to have something different because they have evaluated certain things during customer interviews, user interviews, etc., then you need to ask also them, hey, if we do that, we're going to delay the whole launch for, I don't know, one, two, three, four months. And if you can't agree, then it's also up to the leadership team to make that call. So maybe like rolling back to the task for itself, what are the people that I would put into a task? Well, that depends on the task force, but if you have a redesigned task force and you know that your redesign doesn't involve any back-end work, you just want to launch a new website or in our case, make the apps more intuitive and more user-friendly, you grab iOS engineers, you grab Android engineers and you start working out something. And the way we did back then is 25% of our users were iOS users, 75% Android. And we said, we start with the smaller group because in B2B, you cannot roll out like screen by screen every week. So either you do a big bang or not. And for sure we could argue about that, but I have to say in our case, that was definitely the right call to make a whole redesign. And a whole redesign is not easy because you're going to change the whole app and you have to have like an alpha group, beta group, test flight access. You need to communicate with marketing to invite people to try out the new version, get early feedback and adapt. But it's part of a task force. It's like a full product job you have to do in that case. And there is no shortcuts you can make. You have to take ownership of everything sometimes. And that's something that makes a lot of fun, but it can be really exhausting and it can be really tough because the moment you're going to start facing resistance from other people or the moment where you are not clearly communicating into the company, it can bite you in the ass later. Yeah, I will soon have a similar challenge again where we will have to redesign a couple of things now that we're picking up also with the design capacity and we have time to really focus on these topics. In terms of like setting up a task force, I mean back then we've been working very closely on it. So we had a designer in place who was supporting us. We got the team together. But what would you say is the best thing to do? Hiring a new team? Pulling out people from existing teams? Repurposing an existing team maybe? Is there anything that we could do? Everything is possible, but it depends also on time and, for example, hiring speed, right? And also complexity of your product. Because the moment you're hiring new people, you still have one or two months where you need at least to onboard them. And you always need mature people for code review. And if you hire a new designer, and I think that's something you can speak better about than I, this person also needs to understand the design principles, needs to dig into the design system. So what helped us back then is we took existing developers, we freed them up on purpose. We prioritized globally by saying the redesign has a higher priority than the things they were working on. So that was actually the moment where we realized that's what is needed. And from a design point of view, I think you can also share what you did to make sure that we have a task force that is empowered to get the design resources and also understands what the customer need. Yeah. Would you say that outsourcing entirely a task force could be an option? Yes. Like, could I hire a remote or an agency and be like, okay, cool. Here you have ownership. Do it. That's the reason why we have agencies, right? Because there are enough companies who are sourcing out. But it depends on the company size and also the money you have. I would say you used to work in agencies. What would you prefer? I generally think it's great to have the people in the team doing it just because I think it's good to have the ownership, the buy-in, the kind of stake also on it. I feel like if you have a team of product managers, engineers, designers, and then the fun project of redesigning everything is done externally and they need to swallow it, accept it and continue working with it. And they didn't actively participate. I think it's always good if you find a way to do it in-house, right? Because you have a much stronger connection to the final delivery. And people also work differently if it's their own kind of product. And one very good argument was back then brought up by our CEO, which was, instead of outsourcing it, we do it internally because we have so many running projects and now adding another one is just not good for the whole company. We know this agile motto, start finishing, stop starting. And the more staff you have work in progress, the less likely you will finish something. And even though it's outsourced, you have still another project, you still have to communicate and yeah, it makes things just slower. So I'm a fan of focusing and doing rather less than more. I remember we also obviously like in the prioritization, we down-prioritized a lot of the things that were on active roadmaps. I think that's obviously also a part. You cannot do everything if that's your new priority. And if you are seeing it as the most important thing, that then enables you also in our case, we were also using the argument that we can move faster afterwards, that we have a higher level of consistency, that we can solve a lot of the customer problems that were raised. So you also need to say, we focus on this, the next feature for the payments team. Guess what? We just won't work on it because this one is like higher priority. And also very important because of the fact that we had this senior developers who became part of the task force, we decided by having in mind that we want to have this cross-functional teams. And we were also hiring in parallel saying, we need much more refactoring. So whenever you touch something, make it better than before, make sure you add documentation so that the teams who are getting stuff with new people can directly get a handover and work independently. And that was mandatory because without that, we would just have done the same thing like an agency, writing something, throwing it down and just asking people to swallow it. Yeah. Now, on another note, I remember very well our redesign project. And I also remember spending a lot of time in building the design system. So one thing that we didn't do so well was initially properly estimating the time, the capacity and everything that we needed to get things done. I think we were very optimistic. We, to some extent, believed that it can run in parallel with a lot of other topics. And then at the end, it just turned out to be a much bigger project than initially thought. Yes, I remember that too. It still hurts. And I also need to take that on my plate partially because I was also super optimistic. And the problem from my side back then was realizing that understanding the customer problems is one thing, but then underestimating the technical feasibility and not spending enough time in, for example, workshops or talking to the team and just assuming that what you have worked out in a smaller group is going to work. Even though engineers were involved, I just realized that we should have spent much more time in the technical feasibility checking and making sure that things are not blowing up because once we started developing certain things, the engineers told us, okay, we can do it like that, but it will take much more time. Or we take this native component and it's just based on design system and our principles, something that is almost for free. And then going back and forth and having the discussion internally. I mean, I also remember you and I sitting in meetings and discussing whether we want to have a custom prompt or taking the native ones. That sums up more and more and everything slows down. So that's definitely something I should have much more coordinated back then. And I was too optimistic and maybe too overconfident. Yeah. And honestly, if I also remember, we were all very optimistic, including the tech people, one specific one in mind, but I have to admit it was also a little bit a way to sell it to the company. Otherwise we wouldn't have gotten the resources, right? Yeah, that's a fair point. And something that I would do differently is spending more time in asking myself what the working mode should be. So do you really want to do Kanban by just trading tickets, going through it, having refinements and talking about it, but not estimating it or rather going with Scrum? And looking back, I think Scrum would have been the better option because we did not estimate it much of our work. It was really on gut feeling. And as you said, the engineers also tend to being rather optimistic and pessimistic. And again, later on, it sums up and out of planned four months redesign, it was, I think, 11. And also people start getting pissed because the teams have their roadmaps, they need to postpone the development or eventually launches. So it can become also very expensive. And again, planning is key. Yeah. And with that said, make sure you plan the shit out of your product. Plan a lot and you make mistakes to learn from them. We make mistakes so that we can share them and that you can learn from them. So make sure to press the follow button and check out our social media channels for more materials, more information and more mistakes. Amen. Have a nice day. Bye-bye.