 Welcome everyone to the session, Creating Value First Product Organizations by Kai Gil. We are all happy that you guys have made it to the session. Without any further delay, Kai, over to you. Well, I'm Kai Gil and what I'm going to talk about is how to succeed in product development. There are a lot of techniques out there but they don't actually help you to succeed and there are some basics that seems to me, according to me at least, we're missing some really basic fundamental things to succeed in product development. So you see I'm holding up these two violins. Now there are violins that I bought for my son and one of the violins I bought for 400 euro and the other is worth 10,000 euro. So now if you look at them, you know, on a function and feature kind of user story kind of level, they are actually kind of identical. Yet one is worth 400 euro and the other is worth 10,000 euro. So what's going on here? And, you know, the question to you, the way you describe your requirements for the project, for your products and projects and services, would that really capture the difference in these two violins? And if not, what are you doing? I don't know. And just for fun, can anyone guess which violin is worth 10,000 euro? Let's do that. Which violin is worth 10,000 euro? The one in my right hand or the one in my left hand? The darker one, the left one in your left hand. Yeah, the right hand. Yeah, left. So it's really, you know, there's no obvious way to say which one of these just by looking at them because they really look the same. They are more or less the same. Now, the left violin is made in China. It is 400 euro and it's not actually a bad violin in that they have actually engineered it to be 400 euro. They have put a lot of effort into bringing that price point down while still keeping the sound good enough for students. My son, you know, started off as a student. I didn't want to buy this extremely expensive violin and then, you know, there's no interest in being a violinist. So they had to make it not just cheap but good enough and it sounds quite good. Then on the right side, it's handmade, you know, in Poland, Polish person and, you know, it sounds just amazing. So the thing is, if we're, you know, if you're doing some kind of user story, that's more like doing tasks, not really creating the quality level or the values, I typically call them values, the qualities, attributes, those good things that we really want so much. Those things you find maybe in Apple products, but you also find them in Android. There's a different angle, a different twist to it. So that's one of the key things we're going to be talking about today. Let me move on from that probably. So what I want to do is I want to show you how you can become an expert in succeeding in your projects, 99%, you know, maybe 100%, very close to that. As an engineer, I don't want to talk about 100% here, but I'll show you that this way of doing things gets extremely high success in projects. And if I'm even halfway right in this, you guys better, you know, scream with joy because that's not really what you guys are experiencing today. Okay, so there's a report from the Standish Group. It's called the Chaos Report where they survey thousands of projects all over the world. And the one from 2015 I have some data from. And even though agile projects are three times more likely to succeed, you know, like 39% rather than 11% and some kind of average, it's still mainly failing, right? So if 39% is likely to succeed, that's a whole lot of failure projects. Here's a little graph of that. So here's waterfall with small, tiny little projects, medium and large projects. And here is agile. So, yeah, it's better than waterfall, but waterfall is shit. I mean, that's a disaster to do things when you're actually developing new things. You're not copying, right? You're creating new things with new technology. There's so much new, so much unknown. There's no way waterfall is going to do the job, right? So let's just get that out of the way. Then agile is also failing. These are the failure, right? So what we're trying to do is mostly succeed. And there are some key things there already hinted at with the violin that is just leading this systematically to fail. So let's go and look at some of those key things. Now, here's a Tesla Roadster. I'm not, I'm sure you don't have too many of those on the street. Actually, this one doesn't exist except in prototypes yet. But look at a couple of things. They are not, what are they not talking about? Because there's something about these electric cars. You know, sorry, I sort of gave it their way. They're electric, but they are not bragging. These are the front pages of this page of the, you know, their current sort of offerings. They are not saying, oh, buy an electric car. Why? Because nobody wants the technology. They want the outcomes of the good technology, right? The outcome of these Tesla cars, the way they're put together, is that they're good for the environment. They're fast. They're silent. They have, you know, great range, etc. So these are the outcomes. So if you, so Tesla got to get this, and I don't know, Tesla is maybe not so hot in India, but it is hot in Norway. I have one of these cars, the S, and it's a fantastic product. And yeah, it's electric, but that's secondary. You will find it, you know, you scroll down the page, it will talk about the electric motor, this, that, and the other. But it's focusing on how great the car is. For a long time, the front page of Tesla was the safest car in America, right? It was the safest car. So this is something we need to catch on to. Now in Norway, we are not famous for cars. We made one many, many years ago called Troll, and it didn't go very well. And then we made an electric car as well. Oh, look at this one. This won't be good to have in India, right? Okay, we made this one in Norway. Now, look at the advertising. 100% electric. It looks like they're quantifying something as well, but they aren't, right? Electric is either electric or not. I mean, you had this hybrid thing, but so maybe there's something to it. But the whole point is nobody wants an electric car. And Norwegians, we advertise, I'm from Norway, we advertise, you know, this new product. Go and run out and buy this car. It's 100% electric. And Tandel is saying, however, being electric is one of the outcomes, isn't it? No, it's a technical solution. So now you need to bring this back to you, right? Most of you are, well, some of you are in car business, I think. I was having the workshop and we had Bulwó and was it Ford? So maybe some of you are from Bulwó or Ford or some other car manufacturer. No, electric is not an outcome. It's a technical solution that can be changed out with a gasoline, with propane, with nuclear, with whatever you like. It's just one technical solution. And the users, the buyers don't really care. They do say, like in Norway, people say, I want an electric car. Some people do say that. But what they mean is I want the outcomes of an electric car, which is good for the environment. It's quiet, it's fast. There's a lot of really good stuff with it. So think, by the way, being advertised, 100% electric. That was their main slogan. They went bankrupt and then somebody bought them up and then they went bankrupt again and they finally vanished. I think they were acquired three times and kept the slogan, though. So I think that to succeed these outcome values, like you saw at Tesla, they need to be quantified. Notice on Tesla, it was all quantified. The speed, the range, all kinds of things. If you look at their website, they're clearly very quantified, very systems engineering minded. So I think the number one skill you need to have to succeed in product development is to capture the stakeholders, what the stakeholders sees as success, their success values. That's your starting point. So that means you can't use user stories to capture it because that's only focusing on the user. That's way too limited. What you need is stakeholder focus. And users, of course, you need that as well. But that's just one stakeholder out of your 30, 40, 50 stakeholders that you need to capture and understand what they see as success. So you need to capture what the stakeholders sees as success, their success values. And then you need to understand where they are today and with quantification where they want to be in the future. So you quantify their success, where they are, where they want to be. There is a gap. If you can close that gap, that is going to lead you in the direction of success. Then every decision, everything you do, every prioritization, every task, every action of everyone in the team can work towards getting to that result. Okay. A little bit about me. I have been an apprentice of my father, Tom Gilb. Tom Gilb has actually done lots of stuff in India. I have too been, not lots, but I've been working in India a little bit. And I've been teaching these techniques, mainly to large progressive corporations that want to be the best in the world. And I've not been so much out there for people to learn it because we've mainly been working for these guys. One of our biggest clients here is Intel. Intel have trained 20,000 engineers in this technique. Me and my father, we've trained the trainers, and then they've trained on, and it's been a voluntary process within Intel, not mandated by anyone, but it's just been the way to do things. Everyone knows if you want to get Intel, if you want to be an engineer that has a good grasp of your projects and skills, you need to go and learn this value first. They call it competitive engineering there. That is the same thing. Okay. I just skipped some slides here. This is me with a little longer here. I actually look more like that today with a little bit of corona here. And my father, and then this is Virginia. Meet Virginia. She's a CEO of a startup. And this startup, they produced a waterless toilet for third world countries, for villages that don't have running water and sewage. So they would do their business in the bush or in the river or wherever they would do it. And that would be hygiene, health risk. So she was creating this waterless toilet that also produced energy. So, you know, create energy for both, you know, charging mobile phones in the village and getting hot water for showering, et cetera. Now, when we met them, Bill and Melinda Gates Foundation, they had issued $1 million price to the startup that could, you know, come up with the best idea. So when that happened, of course, hundreds of projects all over the world were trying to, you know, pitch their product as the product that should win the Bill and Melinda Gates Foundation and million dollars because, you know, that'll do a lot of good for people like Virginia. So, and they already had sort of a prototype. Now, what we taught them was a couple of things. So it started off with stakeholders. So this is kind of fancy. I'm going to focus in on one. So here you see the stakeholders. NGO, community, Melinda and Bill Gates, Lewat, sponsors, media, et cetera. So the point here is there's not users. You know, users, yes, but Gates and Bill and Melinda Gates ain't going to install this toilet in one of their mansions, right? They're not the user here. So to succeed in products, what you need to do is you need to have a working list like this of all your active stakeholders and then you need to attach it. Sorry, I need to go off. Then you need to attach it to the values that they are interested in. You know, their improvements and what they see as success. And then you need to quantify that with how well are they doing? How much better can they get because of us? Because of our products and services. That's sort of the key to succeed. Succeeding in satisfying your stakeholders. So if you want to do that, you need to understand what they want and that's how you can do it. So let's focus in on one of these values. So here's a little sort of template that I use when I quantify values. This is a simple simplification of it, but we have a value here, sanitation, and then we quantify it. So whenever there's a value, I always have like this template. Okay, next, quantify. I never talk about highly user-friendly system, something like this, because user-friendly is a value, it has variation, so I need to quantify how user-friendly. Okay, but now we're talking about sanitation. So the proportion of waste that is collected in like a village in an area, and you know, they go into a village, nothing is collected, it's all going into the bush, and then they set the goal of collecting 75% of that area. And then there's something here for prioritization, say hey, at least if we don't get, you know, we aim for 75%, if we don't even get 25, we're kind of a waste, we're losing, we're failing. So this is a failure point. So mainly I'll be talking about succeeding. That's defining success, but here it's defining failure. In between is not quite success, but not failure either. So once you have it quantified, it's not either success or no success, there are degrees of success or degrees of failure. So this is, so if you look at all of, let me go back, if you look at all of these little ones, these are all quantified values for the toilet where, you know, this was, this is just one of them. So they quantified the values attached to the stakeholders, you know, as the stakeholders, what is it that you want? What outcome, like 75% of the waste in the village is collected? That would be an outcome, not electric. Whether the toilet is electric or hand pump driven, like that was one of the comments, that's not the outcome. The outcome is the waste is collected. You see the difference, right? The car, electric or gas, that's not an outcome. That's a how, a solution. And you need to be super clear about the difference between outcomes and solutions. And we are not. As a culture, we just don't, we're not there yet. Okay. So, so make sure, this is just like a reminder, make sure that you have a list of stakeholders, not just your users, not just user stories, 20 to 50 stakeholders per project is, as a rule of every project is different, but if you have three stakeholders, you're missing something. You know, you need to get up in the numbers of 20, 50, otherwise you're missing, you're not understanding it. And then you need to define the outcomes, and you do that quantitatively. So here's the Luwot person. What happened was, here's a Melinda Gates Foundation, and guess who won the million dollars? It was Luwot, and this is among so many people wanting to get that money. And they did this because they were able to present the values, the outcomes of the various stakeholders you know, where they were, where they want to be from the village to the Gates Foundation to all the various stakeholders. So it's pretty cool to get the million dollars for a little startup like that. And I hope you're seeing this. Okay. So what you need to do to succeed is define success well and then lead all decisions, all actions, all efforts towards creating the defined success. Look at this, this caterpillar here. Lots of ants, they're pulling the caterpillar, this huge caterpillar related to them in the same direction. There's no, no ant is sort of pulling, or pushing this caterpillar in a different direction. That's what you need to succeed in a project. There's so complex, there's so many options in your project. So if you have unclear outcomes, that means the guy, you know, the guy in your project that you think is always an idiot and doing the wrong thing, he's actually probably pretty smart, just pulling it in a different direction because he has a different understanding of what we're trying to achieve. So what I highly recommend is you get super clear, sort of top 10 values of, in the, you know, this type of quantified outcomes that we want to achieve with this project, and then you have everyone pulling the project in the same direction. So I'm going to show you three super power skills that you should use to succeed. And one is what we said, capture the value outcomes. Number two, you need to be able to prioritize. Now these two skills in agile, if you look at the agile community, there's very little useful information out there. There's tools about this and tools about that. There's stand-up meetings and this, you know, this, that and the other. But actually how do you capture the outcomes quantitatively is kind of not there, except if you go to guild.com, you know, my work, my father and my work. But, you know, in the big picture is not there. And then number two, prioritizing. Now if you think Moscow or some other high, medium, low kind of prioritization technique is prioritizing, it is not. That's labeling what you haven't prioritized. You've already done the prioritization, but how did you do that? And then you label something as high. And it's really bad to label it because it changes in time. You actually need a dynamic prioritization system that changes in time, sort of like if you're hungry, then you eat, and then when you've eaten, you're not hungry anymore. Then you need other things. So that's dynamic prioritization. So you can't just say, you know, eating is priority number one because you just eat and eat and eat. You know that it needs to be dynamic. And I don't see that available. And then when it comes to delivering value, actually my father, Tom, my mentor, he has been sort of the grandfather of Agile, the guys who made the Agile manifesto, they got their inspiration from him. And he was back then talking about delivering value in short cycles. And they're like, yeah, we need to do things in short cycles. No, it's not doing in short cycles. It's delivering value in short cycles, completely different mindset. So you need to have for, you know, like the scrum guide it says, for every sprint, you should, you know, produce a potentially shipable code, something like this. This is wrong. This is mad. This is crazy. It is not cold. Nobody wants your code. Like nobody wants an electric car. They don't want electric car. They want the outcomes of it. So if your code has no good outcomes, it's not the interesting thing. It's outcomes you have to deliver. So, you know, everyone, when you go back and do sprints, the sprint is about delivering outcome to stakeholders. Okay. Super power skill number one is to capture the outcomes your customers desired. Meet Jens. He was tasked to buy Microsoft. His company was asked to install a CRM at a big telephone company. And he got the job from his company, which was called Avenid to do the job. Now, what most people would do is probably roll it out, look at the CRM, look at how do you install it and roll it out in some way or fashion. He didn't do that. He went knocking on doors to the people that are his stakeholders. And among them were the chief technical officer, a proper C-level executive in a big telephone company. And he's kind of a T-shirt and Jens kind of project manager. And he said, hey, you know, forget CRM, forget what I'm here and hired by another company to do. Like Microsoft hired me to install the CRM. Forget that. What is it that you want to achieve? That's a question you need to ask. What do you want to achieve? And it turned out they were losing 9.3 million euro every year from contracts that they had that were expiring without anybody doing anything about it. And he took a look at that and said, well, if I don't roll out the CRM, if I just focus on solving this issue, I can do that in two weeks because the contracts have a date, this expiring contracts. Now I can use the CRM and I can install that in some kind of local little fashion and suck out the contracts that will expire in, let's say two months and feed that to the salespeople and the salespeople can follow up and renew the contracts. And he did that and it worked. It worked in the sense that it didn't just work in sending the information to the salespeople, but it worked in the sense of not losing 9.3 million euros a year. So this was a huge win. Jens was from that point on treated as a hero sort of in the telephone company. So when he came there to continue installing the CRM kind of, he kept asking, well, who are the stakeholders? What values are they looking for and how can we solve those issues? And for the CRM people in the world, they have this big competition who has the best CRM in the world. And this installation by Jens won the best CRM in the world that year. And Microsoft was so happy about that that they shipped him first class tickets to the US for training and with a five-star hotel and training and everything. Jens was just laughing. He's like, oh, I was there in the first class seats and drinking wine. And it's kind of cool. So when I talk about succeeding in projects and we look at those agile projects and so on and so on, that's a huge percentage of the agile projects fail and some of them succeed. When they talk about succeed, they're not talking about winning the Bill and Linda Gates million dollars or, you know, winning the best CRM in the world and getting special treatment from Microsoft. But that's what I'm talking about. When I talk about 100% success, most of the projects that do this, they don't all win an award, but they get super happy customers because they focus on delivering value to the customers, not functions and features and user stories. You need to get rid of your user stories 100%, just get rid of them. Now, I was teaching this to some people and this guy, Niklas, came up to me and said, I understand, but it's so difficult for me to measure and in his case, it was usability. And I said, well, Niklas, is it difficult to measure or is it difficult to quantify? And he hadn't even thought about the difference. So that's kind of how immature we are but how simple it is also. You need to get a handle on this. You know, if you think it's difficult to measure, that's kind of the wrong equation. You need to quantify first and then measure. So for instance, you know, if you go swimming in Norway, this is how we do it. We dig a little hole in the ice and we pop in there and it's cold, right? So how do you quantify temperature in the chat? Anybody, how do you quantify temperature? Just, you know, a little, make it really simple to see the difference. Yeah, yeah, okay. Well, you see Celsius or Fahrenheit, yes. Dipping your hand, no. Dipping your hand is a way to measure. So you quantify with Celsius and Fahrenheit and you measure with, I can't say that, thermometer, or you can dip your hand. Or you can, you know, there are many ways of measuring and there are different ways of quantifying. So in the same way that there are difference between Celsius and thermometer, you have to look at whatever quality or value that you are needing to quantify the outcomes of for your success. You need to understand there's a difference between quantifying usability and measuring usability. Okay, so that's superpower number one. You need to be able to capture the outcomes of your customers and you need to do that with quantification. I'm going to skip that. Okay. Then number two, you need to be able to maximize to deliver value outcomes to your stakeholders for your efforts. There's always going to be more things that people want than you have resources for. So you need to be really good at prioritizing. And again, there's not, you know, in the adult community, they don't show you good ways to prioritize. So it's crazy. You have really, you know, you need good ways to capture the outcomes. That's number one. Number two, you need good ways to prioritize. We're all the prioritization techniques. That's what it's all about because you always have unlimited resources and unlimited things that you're trying to achieve. And those two don't go well together if you don't know how to prioritize. So there's a saying in Norway that, you know, you can't compare apples and oranges. Actually, in Norwegian, we say apples and pears. Epp, little padet. And in many countries, it's apples and oranges. Do you have such a saying in India? If so, let me know in the chat. You know, you can't compare apples and oranges. Well, of course you can. Everyone compares apples and oranges all the time. Yes, you call it apples and oranges or you call it something else. Well, of course you can. It's an international saying and it is as dumb as it is widespread because when you go into the store or down to your market and there's apples, there's oranges, there's pears, there's other fruits there, what do you do if you're not comparing them? Of course you're comparing them. So how do you compare apples and oranges? Rather than saying you can't do it, let me ask you, how do you do it? When you go to the store, how do you do it? How do you do it? Literally. In the chat. Freshness. Yeah. Price. Yes. Color. Yes. Smell. Yeah. Okay. So these are the values you have, right? You want it fresh. You want the development resource, the price. So as an example here, I say, okay, taste, nutrition, shelf life, resource. And then you're trying to get the ones that have the highest value for the resources, for the cost. So that's how you prioritize apples and oranges and that's what you need to learn to do in your projects. You need to look at two different database systems and you need to pick one. You can't use both Oracle and, I don't know, MySQL. You have to pick one. So you can put them up and then you need to have, you can't do this if these aren't quantified, right? You need taste, nutrition, shelf life to be quantified and clear where you are, where you want to go. Then you can take your various solution ideas like apples, oranges, and these are symbolic for your solutions. And then you can say, well, this apple solves 20% of my families. Now you might like other fruits better than me, but this is my family's sort of taste requirements for fun. So this is 20%. This is 50%. And actually, pears are 90%. And then you can do an apples to orange quantified evaluation of what gives me the most value for my resources. So you can look at, these give me the most value, but actually pears cost more than apples. So here, because apples are maybe in season, so they are cheaper. So apples will give me more value for whatever, for every unit of money I spent. So let me show you another little case. This is Confirmate, this Mitru Johansen. When Tom and I went to them, these are the number of people. It's a tiny little sort of startup company. And here they're doing this kind of table. It's a little bit more fancy because it's real. But here they're looking at usability. There are one, two, three, four, five, six types of usability that they were looking for. And then they quantified it. And then they were looking at each cycle and which cycle would give them the most value for money. Very quickly, this is just doing the apples and pears for each cycle, for each sprint. So they had these sprints. They sort of shipped their code over to the US. And then they were testing. So then they started the next sprint while the previous sprint was being tested. Now, here are some really impressive results. So Confirmate, they do market research report, sort of market research. And the time for the system to generate a service, this is quantifying the value. And then the pass level was two hours. And then at this point of when they wrote these slides, they're reporting it was down to 15 seconds. So this is not like 5% faster or something because when you quantify, you can really stretch yourself and stretch your team and say, hey, I want to be, this 10x is very popular. So you can do 10x, but real quantification of, not just saying we're going to be 10x, but quantify the 10x and do it. So 65 minutes to 20 minutes, 80 minutes to 5 minutes, 15. So 250 simultaneous users with a response rate of less than 500 milliseconds to 6,000, actually on the same hardware. It doesn't really matter. That's the solution. But they told me this was on the same hardware. Now, what happened with Confirmate was they had one big competitor called Paul Strain and was a much larger, more successful, if you like, company than them. But because they did this, their customers, all the customers only went to Confirmate. No new customers went to Paul Strain. They captured 100% of the market because these numbers, you might think, oh, that was bad, like two hours when you can do it. Well, the competitors were still here. They actually, they had, you know, everyone saying, yeah, we need to do this to make it faster, et cetera. That's not, that didn't work. That's what they, that's what this led to. But by having clear quantified goals of, you know, reducing this to, I think it was 10 seconds less. You know, this was just on the way. They did drastic improvements in all the quality attributes of their product. And there's no way the competitors knew how to follow that at all. So that's kind of cool. Now, the developers loved it. For four years, they had, you know, doing this, they were so successful, such fun to do this. One thing that happens for developers that made them, so nobody quit for four years, nobody. Now, one of the things is because the developers were told not what to do, like create a button up here and it should be green, they were told what outcomes to expect, you figure out what to do. It was much more empowering and interesting and, you know, triggered the juices of the, the creative juices of the developers. So they loved working there. They just acquired, they grew very fast. And actually, you know, here's Pulse Strain, their main competitor, here's Confirmit. And here, a lower number is better. Seconds to generate a survey. And then suddenly Confirmit does this in 15 seconds. There's no comparison. All the customers got there. So they ended up take, you know, acquiring their big competitor. And they sent Tom and me over to what used to be Pulse Strain and trained them. But Pulse Strain couldn't compete anymore. They were just left in the dust. So they took them over. It's kind of cool. Just, you know, just really five more minutes. Yeah. We can do Q&A or I can go for five minutes. What do you guys want? If you want to do Q&A, then probably next one, one minute you should close this and then jump off to Q&A. Okay. So I'll do this and we'll do Q&A. So, yeah, so last superpowers. That was superpower skill number two, prioritization, right? So superpower number three is to deliver value to stakeholders for every sprint, right? Now, meet Paul V. He got hired for a job at what's called bring, bring dialogue as a section of bring. And they have a product there which was cleaning customer databases. And so that is, you have a customer database and the emails gets old, et cetera, and you send it to them and they replace the emails and phone numbers and addresses and then send it back to you. So your database is truer to reality. So now he told me that the problem he was tasked with was just to, that they had an old code and he was asked to reprogram it into C++, I think, from Kobold. Now, he also told me that the three product owners before him was fired. They didn't manage. It's not, you know, it's a complex, an old complex program and it was hard to do. So, and he also had one month to come up with a plan and present it to the board and if he succeeded, you know, if they liked it, he would keep his job. If not, he would be number four that was fired. So then we looked at the initial sort of requirement to say, okay, this is database, this system that cleans databases and it needs to be reprogrammed into C++. I asked him, well, you know, who are the stakeholders and we had a list of them, but one of them was, of course, the users and I say, okay, you know, what's really the problem? The real problem was it was too slow, slower than the competitor. And how slow was it? Well, it took two hours. I say, great. Now what we could do is we could focus on the two hours and bring this down to one hour, 30 minutes, I don't know, 10 seconds. I said, but before we go there, let's look at, you know, what happens before and after? Is there anything before and after this database is cleaned in our computer system? So yeah, there's a whole bunch of processes before and after, like the user has to send in their database and then maybe it sits in a queue and then it has to be prepared to go into the system and then afterwards it has to be quality controlled before we send it back and then they have to install it and say, well, how long does that take? About 40 hours. So I say, okay, who's taking care of these other processes? And you know who, right? Nobody, Mr. Nobody, they thought just fix the computer program. So I say, well, Jens, no, not Jens, Paul, what, you have to do this then. So, okay. So we set the goal of reducing the 40 hours to 10 hours instead of the two hours to 30 minutes and then we, so we started off here, it was July and we drew a line down to sort of 10 hours. Now I said, Paul, we're done. What do you mean? Well, you said you had one month to plan. Actually planning is done. You can go home for the remaining 29 days of the month and come back and start working. I was like, I don't want to do that. Well then you need to start working now. There's no point in planning and planning and planning when the part of doing things in short cycle is to learn and you do something and you get feedback and you learn. You know very little about this project right now. It's a waste of time to plan. So he started doing. So before he went into the steering committee, he had already shaved off four hours. So he used that month where she was put aside to do planning. He actually started reducing the time. Before he went into the meeting, he had shaved off four hours of the two available. So the guys were like, what? And he explained how that worked. And then of course he got the job to continue. I mean, they were already beating those guys who were failure, the three guys before him. And then actually then nothing happened because in summer we don't do anything in Norway. We take a month off. And then in September, 15 hours, 13 hours, 12 hours, eight and a half hours, he brought in another system, brought it from five hours to half an hour. Pretty damn cool. So this is what you need to do with each sprint. That's the superpower. For every sprint you don't produce code, you might have to, right? There's nothing wrong with it. A lot of times that's exactly what you do. But that's not the point. The point is you improve the value for the stakeholders. Some value, some quantified value that they really care about. Now they really cared about it. Paul got promoted as responsible for all projects. So, you know, he came in responsible for this one project out of, let's say, 40 projects within his division there. And they say, wow, you know, remember the other guys who did this, they actually, the last guy, I don't know the two first guys, but the last guy he took over for, he had put in place a scrum team. So they were doing scrum and they were failing miserably. And then this guy comes in, he actually kept the scrum team because scrum is good in that it can do things in short cycles and it's a good way to organize the team. So, you know, he kept it. It's like, great, great. I'm not waterfall. I'm not big bang. I'm doing things in short cycle. I have a team that can work together. That's great. But you need to drive this with value improvements. So he put that in place and they drove it down to 8.5 hours. He got responsible for, you know, big promotion for him personally, right? And say, let's do this with all the projects. Okay. So I'll end here. So that's super skill number three that you need.