 You probably can't even see this fully in the picture. How does a company like Lego, and this is a rocket made out of pure Lego, just so you know, how does a company like Lego use design sprints at scale? Find out in this video. Oh, I'm kind of scared that it's gonna fall. So recently on a trip to Tokyo, I got to sit down with Ike Brandsguard from Lego, and we got to talk about design sprints in detail. Lego was really a pioneer when it comes to integrating new innovative systems into their company. And in this clip from the Product Breakfast Club podcast, you're gonna get the deep dive into how they did it and how that runs today at Lego. So what you're gonna hear is a clip from the podcast, you know, one segment that we think is pretty important. So not gonna waste your time anymore. If you have any questions, put them in the comments. Really hope you enjoyed this one. Here is my interview with Ike Brandsguard from Lego, and we're running this interview at Ike's Hotel in Tokyo. So occasionally you will hear people walking around in the background speaking. I really hope you enjoy this. You can find Ike on LinkedIn, if you write in Ike Brandsguard, B-R-A-N-D-S-G-A-R-D. And I'm sure you'd be happy to answer questions about how Lego used design sprints internally if you have any follow-up questions after this podcast. Hello, Ike. Hello, Jonathan. How are you doing, man? I'm fantastic. Let's actually get into one of the main reasons I really wanted to chat to you. I think it was the period of April to June. April to May, early June. April to May, early June, 2017. This is when I guess like a huge portion of the Lego internal agency paused everything that was happening and decided to figure out new ways of working. Maybe let's go back to the start because companies don't usually do that. It sounds like a super dangerous thing to do. Can you tell me what was the reason that this pause happened? The company has for 10 years just had a tremendous success with double-digit growth and not a lot of companies experienced that. We had some idea why that happened but some of it was also fortune, I suppose. So we had 10 fantastic years. Then we could see this starting to slow down a little and then we did some research. We used big data and did a lot of interviews and digging into this and we found out that we were probably being too formal-ag in the way we did our communication. We basically just did it the same way over and over again and did not really reinvent ourselves. And then we had this idea that if we wanted to change that, we just, we needed to do something very different. But if you do something for 10 years, it becomes a habit almost, right? And it's really hard to break out of habits. We got a new boss of the agency, French guy with a lot of courage. When I was there a few weeks ago just to use the words of your colleagues, they said, Rene has some really big balls. Yes, absolutely. They didn't say courage, just so you know. I'm just telling you. But it's his French and it's French, right? So it's courage. Okay, okay. I like that. So his name is Rene. He persuaded his leader peers that we needed to take this break to actually make this happen. What was from his perspective and from your perspective, why was the pain so big to actually convince the leadership that you have to stop? Was it that you guys felt like if you didn't really stop, you wouldn't be able to break the habits, you wouldn't be able to innovate? Is that the reason? Yes. So he had been there around a year at the time, I think. He couldn't really figure out how to stop the organization from doing what it was doing. So where's the handles? How do I do this? We tried to do it in smaller ways, but it didn't have enough impact. I think the metaphor he used was, this is a train that's running. How do I stop the train? I think this is probably pretty much, you know, the emergency break you just pull when you didn't just stop the entire train and then something happens. If you guys hadn't done this pause, if we're looking over the next 10 years, do you think the patterns would have stayed the same and this would have caused more struggle and like what would have been the end result of that, of this not changing, I guess? I think we would still change, but just at a different pace. This was a step change. This was kind of a revolution. So if we haven't done this, it would be more of an evolution. Of course we would keep up, but we would probably lag a little behind all the time and now this was actually an opportunity to get a little ahead of the curve. So you guys stopped the pause happened in 2017 and you and your colleagues were kind of given a, let's say a task, I guess, to figure out as the agency, how can we actually work in the future? Yeah, that was, it was actually a bit of a crazy meeting that one because my very good colleague, Henrik and I, we were called in to the office of Rami and one of the other leaders of the agency and told that so guys, we're doing this thing, we are going to call the pause. So we're going to take a break for two months and then we need to look at how to work differently. And you know, you guys, you have been working with these iterations and this agile stuff. So we want to do something similar like that. So are we up for that? Yeah, yeah, of course. Super excited. And by the way, so you know, we want this done in nine days. We will pull the break in nine days and then you guys, you will just make sure that 200 people they work in iterations in some way. And had it been four years ago, I would just have ran out of the office and said, never ever, this is crazy. But we've done a similar thing a couple of years back when we introduced something called scale agile framework. It's an agile process where we took a lot of people and just from day to day almost kind of made a change like this. So we were like, all right, we think we can do this. I mean, we've seen it before. So we think it can be done. We just need to find the proper method. We went back to our drawing board, talked to a couple of other colleagues who have done different agile design thinking activities. And then we agreed that, okay, since we are going to have so many colleagues who have never ever done anything agile on a regular basis before, we need to basically teach them and make them super comfortable about how to do this. Stuff like Kanban and Scrum and just bigger picture of design thinking and teaching them the principles of that. We didn't think that would be the right way. We thought it would take them too long to kind of become good at it. Usually when you work agile, you need four or five iterations before it becomes comfortable. Then you improve from that and then we would be done with the pose. And then the design sprints seem to be the perfect thing. We've been doing design sprints a couple of times. And then we thought to use your words, Jonathan, it's a recipe. You're really instructed exactly how to do this. And then we of course started with the Jake's book. We picked out some facilitators who could do this for us. Somebody who was used to facilitating and could create some kind of structure around this. So we actually chose a lot of project managers, had them read the book and then they basically had three days to get ready to do this. We created a more detailed schedule for them that you can find in Jake's book. So it's like, okay, so you will meet at nine and from nine to nine 12. You will make the introductions from nine 12 to nine 15. You will show the first video from Jake and so forth just to make them feel comfortable about this. And it worked. You chose a couple of project managers that were going to be facilitating these design sprints. You and Henrik read the book first. What made you choose the design sprint? So it was that it was so well-defined that it was a recipe. So it has the iterations built in, but also it's really like an instruction manual on how to do this. And what we had learned, maybe we have done a handful of these before, was that when you do a design sprint, there are some things that feel a little out of place, a little awkward, but it doesn't really matter because very shortly after then the clock will beep and then you just move on to the next exercise. And the sum of everything you do in the week kind of produces an output that have worked for us. If you look at, let's say, using the sprint process compared to using, you said you guys had been kind of doing some design thinking-y things before. Why not just, I mean, you already mentioned that the reason was you wanted like almost the minimum effective dose. The thing that would work the fastest with the least amount of effort might be the design sprint. What is the reason you didn't maybe just go with design thinking? Because at least from my perspective, most large companies of the size of LEGO would have actually gone the design thinking route. Henrik and I, where we come from is digital. So we've been doing a lot of software development. So it's actually less design thinking we had, you know, under the skin and experience will. It was more agile practices within the software development like Scrum, Kanban, Scale Agile Framework. We had some colleagues who also knew about design thinking and we knew that some of the principles in the design sprint has the roots in design thinking. I also knew about IDU and some of the stuff they've been doing. But it also seems like this is something you need to practice, right? It's a set of principles. And you start with these and then you kind of need to find your way. I mean, Henrik and I, what we think is interesting is the process, not in itself, but what it can do to people to help them achieve whatever they need to achieve. Where the people attending some of these things, they're much more focused on an output. They need to deliver something, right? That's valuable to the company. A product, a concept, a campaign, something like that. And if you select design thinking, you would also inherently kind of need to reflect about how you're working, right? We just wanted to focus on the stuff they needed to do and take the overhead of thinking process away from this. Of course, they needed to learn it and get familiar with it, but at least they should just trust the process was really one of the main trends. It's like, guys, don't challenge this. Don't ask too many questions now. Trust the process, run through a week, and then we can discuss when the week is done, but you need to kind of have all of it. Then you'll see what it can do for you. Did you notice a difference between how people felt about doing it on the Monday compared to how they felt once they had the prototype on Friday? Yeah, of course, they were a little anxious going in on Monday. A lot was actually super excited, right? Because they could see the same pattern. It's like, all right, we're doing the same thing over and over again, and it's not completely Groundhog Day, but at least we know what we're doing. And usually when you get out of your comfort zone in a nice way, then it's exciting, right? So you don't know how the week is going to end. You're going to meet some new colleagues you probably never worked that close with before and you're working on something you haven't worked on before. So I thought that part was interesting and most of them just played along. And I think that's the only requirement you need from somebody is that they want to play along. I think an advantage that people in the agency had compared to if I think of some of our clients who are trying to implement the design sprint into their company, one of the reasons that people push back against it is because they don't have the opportunity to pause and try it out. When we're trying to implement the design sprint, they're trying to crush it into their everyday work as well. You know, at the end of the day, then they have to do all their emails and they actually have to do their real work. And I think it's not that they don't want to do it. It's just that they don't have the permission from the top down to say, look, we want you to really try this. You're absolutely right about that one. It's not time you need to carve out from everything else you do. You actually need to be allowed to do this. It's focused, right? You can take a lot of theories about cues and waiting time and stuff like that. It's waste, right? You take that out of the equation because you're so focused in the week and that's why it works. And your managers need to support this. So we also had a rule that either you're in or you're out. So it's not like you're in for two days and you're out for two days. That doesn't work. Then you're not in. And we had enough people in the pool to kind of choose from and then we would just reduce the amount of design sprints we will do within a week based on how many people could commit 100% for the sprints. How many sprints did you have running at the same time? So we had up to 10 running each week. Holy crap. Yeah, so I think at the end of it, we had at least 60 sprints and now we've done 150 maybe. Wow, that's insane. How did you choose the projects to actually run the sprints for? Yeah, so that's actually the thing the book doesn't tell about, right? Dammit Jake, sorry Jake, don't buy sprints. This is kind of like design sprint at scale, right when you do this much. We quickly found out that the bottleneck was really not the sprints and getting people on board themselves. It was actually digesting and processing the output from the sprints and preparing the input for the next sprint. So we would create something we ended up calling the control tower. So they kind of looked at all these airplanes, all these sprints flying around to make sure they got off the ground really well and they also landed again really well and they would prepare the brief for the sprint teams. We did a presentation for this group of people at the end as well. To the extent we could and that was most of the time we would do the testing because it's super valuable. But then in addition to that we would actually make a presentation for this group of people and tell them what did we do doing the sprint? What did we learn? What was the prototype? What did the testing say? What is our recommendation to have now? We also needed to kind of stagger it a little because we would just take the output from one sprint and then put it directly into the following week. But that meant that if we saw the demo on a Friday we would need to get ready for Monday. It was not possible. It was crazy. And if you are looking at eight to 10 different teams presenting their stuff you're having a fantastic day, right? Because you're seeing all this awesome stuff coming out from a lot of clever people but your mind is just exploding at the end of the day. So how do you kind of cope with this? You simply need time to think about this and then consider, okay so what is the next step we're going to take from this? We also got more organized. Usually what happens when you do iterations like this for a period of time is that patterns start to emerge, right? So we could also see that, hmm we know that some of the overall challenges for Lego is in these different areas and then we could kind of take the different sprint outputs and then put them into a matrix and say, okay now we are covering this part of our challenges and now we are covering this part of our challenges and then we could see, okay do we have any gaps here? Is there anything that we need to look at with these sprints and the sprint teams that they should investigate and find a solution for a problem that you try and dig into? So that made it a lot more structured as we went along. But to be honest, it's not how we started. It came as we built this thing. So the control tower, how many people were in this kind of group? Five. Five people. Were you in that group as well? This control tower? I was facilitating it. So I was not making any decisions in there. I just made sure that it took place and that we captured the outcome of it. So the creation of the projects because this is a very common problem in a lot of companies I work for and I know a lot of people will be listening to this podcast who are constantly asking me about this and how this works in large companies. How did that actually work? So maybe two questions. Number one, how was this brief created? Number two, how did that get communicated to the team who was just about to run the sprint? We had some creative directors who were responsible of writing the briefs and then we got the head of the agency with me approving them and said, yeah, this is the direction. So he was kind of overseeing it all. And then the teams, they got it on Monday morning when they got in there and we had a brief template that we used. It's the one we usually do. So it's about, okay, so this is the challenge. This is who it's for. This is some inspiration. And it's just a one-pager. It's very simple. And we use it a little bit like user stories to take some agile comparison. So it's a conversation starter, right? So the team would get this, they would look at it and they would have some questions and some elaboration was needed. And then they would just have a conversation with the person who actually wrote it. And then when they were thinking that, yeah, now we are good to go. We understand exactly what the issue is and what the challenge is. Now we think we can work our way towards a solution. And if they got in doubt of derouted during the course of the sprint, they would just call in this person and just verify whether the direction they were taking were the right one. Often we would also have the person who wrote the brief as the designer to make sure that they kind of got it in the direction they wanted. I mean, this is a question that goes slightly back in the timeline, but I'm just kind of shocked about this. How did you get the confidence to go and say, we will do the design sprint in this pause and nothing else? As I mentioned, we did this scale-addial framework introduction some years back, which was just a leap of faith. It's just like, all right, let's do it. We need to change something. We need to do differently. So let's just plunge into it and I've gone super confident in iterative processes over the years because you super quickly learn, not me personally, but a group of people who are doing this because you reflect on, okay, so is this working for us? Are we achieving what we want to achieve? And if it's not, what do we want to change? That's actually something we added to the sprints as well. So I mentioned that we trained these facilitators in this. I would meet every morning and every afternoon with the facilitators. In the morning, it was actually mainly to give them confidence in this. At the time, I was not an expert on design sprints, but at least I could give them confidence that I were. And they should just go in here and everything would be fine. So just go in there, follow this recipe and you will be fine. And then in the afternoon, I would get the facilitators back and we would discuss what worked well, what didn't work so well, any questions, challenges, something that you interpreted differently. And there was a huge learning opportunity for everybody, not the least me. And we would do this every day. So just take one day at the time. So when you start doing this, it's not like you need to understand everything that happens throughout the week. Just focus on the Monday. Have a broad idea on what you're going to accomplish in the five days or four days. And then just take one day at the time in detail and actually during the day when your team is working on things, look it up in the book and just prepare for the next exercise. So it doesn't take a lot of preparation, which I absolutely love. It's really, really like the best part of the sprint for me is the lack of preparation you have to do because then there's no excuse, right? To actually do the sprint. Right. And then we would do a more formal retrospective usually on Thursday when the teams were doing the prototype, then I would get the facilitators in and we would do a one hour retrospective. Okay, what is working really well? What is not working so well? And then organize it and say, all right, then for the next one, we will tweak this thing. And usually the design sprint itself works super well. I think the only thing that they had a little challenge with was the map. Everyone has problems with the map. So you would do it as kind of a warm-up exercise and then you would move on and everything would be good. When you do these things, when you get down to practicalities, you're in a good place, right? So it's like, we need more doting bots or more candy. Right. Stuff like that. Perfect, yeah, yeah. So the end of the two months, right? It's the, I don't know, end of May. What actually happened there? So here we kind of digested all the different sprints and the outputs and then we did one big presentation for upper management at Lego. Our chief marketing officer and some of the team, they would come by and then see some of the things we did. After that, we agreed that, all right, we're actually going to do this. So these prototypes, these concepts, these ideas, now we're actually putting it into action. And we've been seeing some of them come out this year and some are still in the works, usually projects at Lego take some time from you get the first idea and until it hits the shelves, it's like 18 months. You can definitely tell that it's not purely digital. You actually need to get some plastic grains and mold it and getting onto the shelves. But it's going to be really interesting to follow this. If you look at the amount of projects that happened in those two months, I don't know, you said how many sprints in total happened in the two months? I think around 60. Of course, we experimented a little with this. So sometimes we would take, if one team came out with an output where we felt that we're not exactly sure it's there, then we might give the exact same brief to a completely different team. Also, sometimes we would take the outcome from one team and say, all right, guys, this is really good. Why don't you kind of polish it and perfect it and then use another sprint of actually getting it production ready? But we learned that neither of those two ways of doing it was particularly effective. It was actually the best output or outcome was when the original team just created a done deal. It's like the 20, 80 rule, right? So the first team who does it will create 80 or 90% of it just brilliantly. And then you can spend another week and you will only get like 20 or 10% more and it's not really worth it. And sometimes a different team working on it would not actually produce a better result. It would just be different. So just having them work on it in one team is definitely the most effective way to do it. So after the two months, I mean, this is just less than a year ago now. What has been the change in the way that you guys now work within the agency? Are sprints being run regularly? Do teams voluntarily choose to run a sprint when they feel like it? How has it changed the way you work? Of course, we got some very concrete output out of the sprints that would solve some real issues for us. But I think at least half of what we accomplished with it was a change in the way we work. The teams are now on their own. Either they will select their point in time where they think that now it's time for a sprint. We need to get things started or we hit an obstacle where we need to propel ourselves forwards and the sprint would be that. And I think it's the first time in my career at Lego, I've seen it kind of get momentum. Usually you need somebody to drive it, right? You need a leader, you need a facilitator, you need some project manager, some process people. If they get out of the equation, it will stop. People usually appreciate it and like to work this way, but it doesn't kind of, it's not self-motivated. It doesn't become a habit as well. No, so I think where I decor on the most was with some of our creative teams who would just consistently do it every second week. So they will have every second week, they will do a sprint and then it will work in a more regular way, if you like. And people ask for it. It has a lot of cool benefits. So I think it's a super-timbling activity. We deliberately tried to mix up people because we were going for a little more raw innovation. So we thought that if people not work together on a daily basis, but they come from different areas, right? They would inspire each other more and it's definitely true, they will. But the benefit for them is that they get to know some colleagues they've seen before, right? You've seen them in the coffee line but now they actually know them, right? So we could see afterwards there was a lot of buzz of people chatting and talking. So the whole office area just got more lively after doing this. Also, if you are a person participating in a sprint, usually you would have some kind of expertise that everybody knows and you know yourself and you will kind of be a little typecast that that's the stuff you do. When you're in a sprint like this, whatever the sprint requires needs to be chipped in. And maybe you are the person who can chip it in, right? So maybe it's your interest, maybe it's something you aspire to do, maybe it's something you've done in your past, maybe it's something you do in your spare time but you bring it into the sprint and then all of a sudden your work becomes less, you can't call it mundane, but at least it's not as restricted. I think that's a huge point that you just made that it gathers momentum on its own without somebody having to push it. And I think it's the first time I've ever experienced that. Now I've been working with companies for the last 10 years trying to help them with their innovation processes, product processes and you're completely right. What would happen is I would leave and it would stop. And I think the reason, and now when I look back at it, the reason it would stop was because people often felt like the process was kind of just something they had to do. It wasn't something they necessarily wanted to do. They didn't necessarily always see the benefit, for example, when I used to teach companies design thinking processes or you know about personas and all of this kind of thing, especially people who were not designers. So you know the developers and the business owners would just be like, okay, Jonathan's gone. Let's go back to the way we were working because this stuff doesn't work right. They didn't really believe in it. Even if some people believed in it, there wasn't enough people believing it for it to gather momentum. So I would have to keep going back and keep helping and keep helping. I was working with a sports shoe company recently. It took maybe one sprint, just one normal sprint and an iteration sprint for it to spread like a virus throughout the company. The sprint is not being pushed on them. They asked the team who did the sprint with us, can they teach them how to do the sprint now? And then it goes to another team and another team and another team. And I think that this is a huge point, right? It's so practical. It also makes people's lives easier. I think there are some things in the sprint that don't get talked about enough. For example, the fact that discussion is removed from making decisions. Normally people are so sick and tired of sitting around talking about what they want to do and what they should do and what's the right decision, especially if it's a creative exercise. And the sprint kind of removes these and processes these conversations. And I think that's huge. People don't feel so tired at the end of the day. Like a nice example is when I went and visited you guys in January, one of the developers, and by the way, developers notoriously hate design processes, came up to me and like had a video that they were using, you know, one of the small cut down sections of the design sprint to do their retrospectives now so that they don't have to talk. And I think that's such a cool thing that people get excited about it, that they take ownership about it and that they feel empowered with the way they're working by using the process. And I think that's why it's so sticky. Absolutely. Having a mix of somebody who I've done a sprint before and somebody who hasn't, that's also a really good way for it to kind of spread like a virus. Right. And it works really well. And I just love the thought that I don't have to drive everything. I think that's the absolute best proof that this is actually valuable for the people who are doing it, which is the whole point. I mean, for the business, yeah, you might introduce it and you get the desired outcome from it. But I really, really think that you have only true value if the people who actually participate in it, they wanna do it on their own. It gets momentum, it becomes part of the way you actually work. We just kind of put it to the test. So here in the autumn, we did at Lego what our CEO called a reset. So we had to let some people go. Another reset? Another reset. Oh, one of the whole company, right? Yeah, it's not the pause, it was a reset. So we had to let some people go. We restructured a lot of stuff. I mean, it was the biggest change I've seen in my time at Lego. It was really interesting to see how all of this would come back together. And people are really asking for this, right? So it's like, we want more, we want more sprints, we want more teams, we want more fast decision-making. So we're not doing enough. Just before this reset last year, we actually tried to say, all right, everybody agree in the agency that one week, every month, we will have no meetings because that would allow for two things. Either you kind of are ready to participate in a sprint if that's required, or you just get focused to get stuff done, right? Which is also what the sprint does. You're not working on a billion different things and attending 20 different meetings during a week. So that part of it works super well, but then we stopped it and I think we need to pick it up. I was trying to be a little radical and say, hey, why don't we have meetings for one week and then no meetings for three weeks? So we can- That's them all together. Exactly, so let's see if I can get a stamp. That's something that Jake, the guy who's usually hosting this show as well, he speaks about, when you start a job first, you're super excited about it. Your calendar is clear. You're ready to do the creative work. You're super excited about the company. And then one meeting pops up and it's like, okay, this is the lunch to catch up with this person. Then another meeting and then another meeting. And eventually, two weeks into working at a company, your time is constantly, you're switching context the whole time, right? You rarely have like four hours of just working on one thing in concentration. And I think that's also something, and that's really cool to hear that one of the principles of the sprint of being able to really batch the time and really do concentrated focused work in one context that that starts spilling throughout the rest of the company and you start making decisions outside of the sprint that are taking principles from it, which I think is super important as well. And it works. It's just a really good feeling and you really get stuff done. So people embrace it. Do you see you guys sticking to this process for the next few years and really like making it part of your regular habit or do you think it's going to be something that is like the current trend and then you'll move on to the next thing? No, I actually really think this is going to stick at least for a foreseeable future. The thing with a big company like Legum, things just take time, right? I mean, you have small bubbles of teams and departments within the company who are working in a particular way. So, and right now, this is really spreading throughout the company. So we try to inspire our colleagues and tell them what we've been doing. So, and then it's kind of up to them where they want to plunge into it and try it as well. But it's requested a lot. So a lot of people of my colleagues, they ask if I can come and tell them how they do this, if I can facilitate a workshop, if I can teach them how to do this. Outside the agency also? Only from outside the agency. I've actually kind of left the agency now because the agency is kind of self-sufficient with it. There's enough critical mass. People know about it. There's so much experience in there. I can't really move that a lot. It's a high performance team within this. So I can make a much bigger difference by doing this in different parts of the company. And it's interesting because some of our departments who you would think that this was even more suited for, they don't really do it and they're really curious about it. So our raw product design development areas. And I also think that's the interesting aspect of it. For me personally, it's taking it from a digital environment where your constraints are different and then taking it into different parts of the organization and see how does this way of working, how well suited is it for this? Can I help my colleagues? So they work in a smarter way, achieving their results in a faster and better way than they do now. So that's kind of the mission. So far it's working pretty well. Do you still call yourself an agile coach within Lego or have you changed it to design sprint coach now? No, no, it's agile coach. I actually didn't used to be an agile coach. I used to head up project management. I've been a project manager for my entire career. But as of this year, I formally became an agile coach at Lego, but I actually don't think the difference in what you want to achieve is that big. The way you do it is very different, but not what you want to achieve because at the end of the day, what you want to do is to have a group of people working towards a shared goal as effectively and as fun as possible. So let's finish this off with something that maybe would help some of our listeners. Also a tricky question. If you were to go into a large fortune 500 car company tomorrow and you had two months to, I would say usually the task is help us to innovate faster, help us to work faster. You only have you, so you have to orchestrate everybody else. Won't be the way you would start that. First, I need to get some buy-in from the decision makers, the people who have the fortune of the company in their hands and then get their acceptance for, okay, so we're going to work this way. And then I would pick some of the most curious people about that could do this to kind of get momentum. Personally, I'm inclined to start small and let it grow from there. But if I look at what I've actually done at Lego, it's always been pretty massive, right? A lot of people in one go is like, boom, big step chains and we land it on the feet every time. But from a risk perspective, it's just more risky. But it creates the chains faster. But I still think that if you get some people on board who wants to do this, it's a really good way to get started. So, and then you can choose everything between that and then just training everybody from day one and the following one day you're just working this way because it's building that you learn, right? People are generally pretty smart. They will adapt. They will learn this really fast. And if you take the effort to do it retrospectively, look at yourself by the end of each week and then have a discussion about, okay, so how do we want to collaborate with everything we learned now and then change that going forward, then you will get there really, really fast. In the course of product development and big companies, a week's worth of work is nothing. People might think it is. As you said before, ah, but we can't allocate our time to it and we need to work on our daily work. That's bullshit. Of course, you can take one week out of your schedule. You'll probably go on vacation once in a while, right? That's also a week away from work. Now you're actually taking a week that's super focused on your work that will propel you forward. So I would also dare the people who either doubt it or wants to do this to just do it. I mean, just plunge in. The risk is relatively low because it's a proven process. The investment you do as a company is very low. All things considered, it's only a week for a handful of people. So do it and then we can discuss it on Friday. And if you think it's a bad idea, let's not do it anymore, but I pretty much guarantee you that this will work for you. So maybe just to finish it off, what might be interesting for companies or people listening is the reason that you and I are here in Tokyo is that we're going to be running a lightning decision jam session tomorrow. Lightning decision jam for anybody who doesn't know is a very short one and a half hour approximately decision making and creative problem solving process, which takes the principles, the important principles of the design sprint and crushes it down into a very small workshop. We developed this at AJ & Smart as a way to show usually stakeholders what the power of the design sprint is without having them commit to the entire thing. But it actually ended up being a process that we ended up using every single week internally to get things done. What I'm amazed about is that also when I visited Lego to notice how many teams were actually using this as well, which is really, really cool. Maybe you can talk a little bit about how that has been useful for you this exercise. Well, when I visited you guys in Berlin back in July, it was part of what we did in the workshop, but it was kind of a snack. It was kind of an in-between exercise and to do exactly what you mentioned, that you can kind of sell in how the design sprint works, but it only takes you a couple of hours. It's extremely efficient in actually making a group of people, making decisions, so it works very well in killing endless discussions. And we're really embracing it, particularly a lot of my leader colleagues really like this way of working. Usually you will get some kind of power structure when you're in a meeting, right? Whether you want it or not. Usually the guy or girl with the power doesn't want that, it just happens anyways. But by using this process, because it's so much silent decision-making, you kind of take that power thing out of the equation and it's generally just the best idea or the best decision that gets emphasis. And that's really good, plus it doesn't take several days to do it. So I've been doing this quite a few times and also built it into regular workshops that has the elements of the beginning of the design sprint, not the prototyping and the testing part, but more identifying the call for problem and then pointing at the solution that we think we would go with and what the Lightning Decision Jam does is putting that into some really actionable items that you can do tomorrow. And the bias for action is the thing that's pretty important, right? Like that you don't just say, oh, we're gonna have a one and a half hour meeting in chat and then there'll be some notes at the end. There's no way of ending that exercise without having solutions and without people saying, I'm going to execute that task. Yes, so it's this person doing exactly this at this particular time. That makes it super powerful. And now you just mentioned bias to action. So Lego just got a new CEO and that's the thing he mentions, bias to action. Let's get stuff done and this is perfect for that. There can be a lot of chattering and talking and when you leave the meeting, maybe you're uncertain actually what the outcome was. But this, it makes it super concrete in a very short amount of time. So that's what you and I will be doing tomorrow to take a group of leaders at Lego through this. My boss, the head of the agency, he really likes this way of working, the Lightning Decision Jam and just wants to try it out on the leadership team. He's part of to see if that can help them propel this forward. I think also a cool thing about Lightning Decision Jam is that everybody can facilitate it. Anybody in a group of people can do it. So you just need somebody to kind of take the lead on it. So bias for action or bias to action, bias for action is the only company mission statement sort of bullet point that I've ever heard that isn't just total bullshit. Like this kind of push towards just like something practical, right? I hope that becomes a trend over the next few years because there's definitely currently this sort of vagueness when you look at company mission statements. You know, it's like about we're going to innovate. What does that even mean? It means nothing. Bias for action at least means you're moving forward. And I think that's really, really important. So I think anybody interested in learning about Lightning Decision Jam, you can just Google it. I also might put it in the show notes if I have time so you can click it. You'll find a video of exactly how to do that on the internet. Thanks so much for giving me so much of your time. Looking forward to the workshop tomorrow. Looking forward to some sushi and sake later. Have a great day. Thank you Jonathan and you too. I'm really glad that you and AJ and Smart appeared into my life. Thank you, sir. Thank you very much. And now please give me some more Lego. So I hope you really enjoyed that video with Ike Brandsgard, even though if you had it running in the background or whatever, I hope you enjoyed it. Definitely go and check out the full Product Breakfast Club podcast. It's out every single Monday. There's a link in the description down below or just open up your phone and download a podcast app and type in Product Breakfast Club. So every Monday, really great episode of the Product Breakfast Club. You should definitely check it out. It's also good fun. We also have every week here on YouTube. We have a new video about product design, about workshops, about design sprints, about innovation. So every week here, so make sure you're subscribed and also maybe hit that bell. What else do we have? We also have a really kick-ass Facebook group called Innovation Hackers, which you can check out and you can apply to. And that's just a lot of people sharing different techniques and processes in the design world. Finally, we have a daily vlog on Instagram stories and that's at AJ Smart Design. You can find everything down in the description. Really hope you liked this video and do leave a comment. If you have any questions, we'll answer them all. Thanks so much. Have a great one.