 I want to talk about friction. Friction is sort of the opposite of awesome. It's the stuff that gets in our way of keeping us from being really productive, having really great products, that sort of thing. And in the lean world we used to talk about this thing called waste. I'd say in software development we'll call it friction. Friction is not always bad. I mean if you had absolutely no friction at all, you couldn't drive your car. It would be like on ice. So there's a place for friction, but you really don't want very much of it. So let's talk about friction in our world. Friction in the product that we make, friction in the process that we use, and friction in the code that we do. This is a sort of a quick Kyla level summary of those those three areas that we really need to spend some time thinking about. So I'll start with friction in our product. And I want to start talking about this whole area of cognitive biases. You may or may not recognize Daniel Kenneman, a Nobel winner of the Nobel Prize in Economics, and he did a whole lot of work summarizing it in this book Thinking Fast and Slow, which is a very heavy book, but basically it's about cognitive biases. So in the book he talks about two systems of thinking that everybody sort of has. There's system one and system two. Some people say emotion and reason and that sort of thing. He says there's lots of labels. We'll just call them system one and system two. System one is fast and system two is slow. System one is reflexive. If I touch something hot, I pull my hand away right away. That's reflex. System two is slow and deliberate. And I don't want to do that when I touch something hot. But there's times when I want to be slow and deliberate. System one is very responsive to whatever happens. And system two is rational. I think through all of the ramifications before I make a decision. System one is all about expertise. That's interesting. Experts are operating off of system one. Fast thinking, responsive, reflexive. And system two is about analysis. And there's probably a place for it, both expertise and analysis. System one is about intuition and system two is about evidence. System one is about habits and system two is about plans. System one is about tacit knowledge. I kind of know it, but I can't really tell you just like how it feels. It's remember when Josh was teaching his little girl to ride a bike. It's the feeling of balance. You just get it or you don't. And system two is explicit knowledge. Stuff you can write down and give to a child and say, here, read this and then you can ride a bike. It won't work, right? So sometimes explicit knowledge is good and sometimes it doesn't work. System one is like being an auto pilot in a car or in an airplane. System two is like being in manual mode. And interestingly, according to Kenaman, our system one makes most of the decisions in our life. And system two checks up on system one and makes sure that the decisions are good and sort of is the conscience, I would suppose. And the other thing he says is that system one will override system two. So system two might tell us to do something, but if our motion says something else, nothing's going to change the way that we feel. And what system two is is basically lazy. System two would rather not think. Okay? So this is the way people are. It might sound familiar to you. And when we're actually working with our consumers and when we're working ourselves, we have these two different systems sort of fighting in our minds. So I would like to talk about the first friction and any designer in here would understand this, the cognitive overhead of a system that a system places on the people who use it. If it makes them think, then that's friction. Okay? If they can make all the decisions with system one, then it is fast and easy. And if they have to think, it is slow. So here's an example. This is a way to get in and do some purchasing after you've got stuff in your shopping basket. And it's a put in your email address, your password, and then you can log in if you got a password, or you can register. And the problem with that is you're trying to wake up system two and say, time to register. Huh? What password register? I don't want to do that. And so the analysis of this by some of the experts after they did some, they were losing huge amounts of people on this page. Why? Well, they changed one little thing. They changed from register to continue. They didn't try to wake up system two. And you don't have to create an account to continue. When they made this change, and you know, the developer said, why, what's wrong with register? We need all the information that they're going to give us for registering anyway. So how could that be that when they made that one little change, the number of purchasers when purchases went up 45% like immediately, the first month revenue went up $15 million, and the annual revenue $300 million. So you're going to read about this is called the $300 million button, which that is, right? That's a $300 million mistake. So when you're designing, you need to design for system one. Don't try and wake up system two. It doesn't work. So think about system one. System one is this autopilot. Their system one is cognitively lazy. You want to talk about cognitive biases, they don't want to make any decisions. The other thing is, when you're in system one, you're dealing with cognitive biases. For example, hands off my stuff for don't make me, of course, I'm right, or don't make me think, let's talk about a couple of these. So one of the cognitive biases is loss aversion. We feel the pain of loss twice as much twice two more times than the gain of a corresponding win. So for example, 44% of shoppers abandon the shopping cart, when they get to the how much extra they have to pay for shipping. No matter how little it is. It's like I already own this. I should have it. What do you mean I have to pay extra? By putting the cost of shipping in the product, they get a whole lot less people abandoning the shopping cart, because they're switching from they're switching to loss aversion, when you add money on at the end, the people weren't expecting. Or if you go to the airport, and they want more money for whatever seat assignments and baggage and all of that sort of stuff, very annoying, because loss aversion says, if you think I'm going to pay $25 for my bag, to me, it feels like $50, because I'm losing the money. It's mine. And you're taking it from me. I don't mind the price of the ticket one way or the other $50, but I really mind adding it on at the end. So loss aversion is a big thing when we're thinking about how to design to make customers awesome. And another one is confirmation bias. It's almost my favorite. Because I have confirmation bias and you have confirmation bias. Everybody does. And we seek out an interpret information in a way that's going to confirm the way we already think. Yes. So we look for other people that like agile because then down there. But if people have different ideas, we think, huh, they must be wrong. So we do that. And it's like, of course, and right. And whoever thinks might like me, of course, they're right to. This is one of my favorite cartoons. So the teenager says, Hey, mom, who's more open minded, liberals are conservatives. And mom says, Well, most people are open minded about ideas they already agree with. Well, what good is that? Right? So we have to watch for confirmation bias. And one of the interesting things is, since everybody has confirmation bias, one of the people when we're designing products, we have to be careful of who is going to have confirmation bias is going to be, for example, our product manager. There's research, I have a little reference down here, you can get it on the slides that shows that at least half of the time, the product manager is wrong about the results of an idea that they have. And if you ask a product manager, they'll say, Yep, that's about right. Okay. But they're have an idea and they seek out confirming evidence towards what it is that they already believe. And when you do that, and when you're dealing with confirmation bias, you can have a problem. And that's a particular problem with a product manager that we have to be careful of. But there are other biases. And the one that I think is the most interesting is teams have cognitive biases too. Or anyway, cognitive biases affect teams. And there's a book here called wiser. And in this book, the authors studied teams. Do they have cognitive biases? And what kinds of cognitive biases? And how many of you were at Noresh's talk a couple, you know, about this morning? All right, well, he was talking about this. The concept that deliberation makes a group dumber. That's, that's the conclusion of you are really big into teams. You don't want to hear this. Okay, your cognitive biases. No, no, don't tell me that I don't want to hear that. But what their research shows is that there are two or so biases that are normal. And most people that mean that when a team gets together and discusses something, they are going to be dumber than the sum of all of the individual thoughts of the people in the team, which is not really very good, right? So why? Well, there's two. One is conformity bias. And you know, if you've ever watched penguins, they just follow each other and they have a good reason because the first one's going to get eaten by the shark and the rest of them will be okay. So you know, as long as you're not first, you're fine as long as you follow. But that's penguins. Okay. And maybe we don't want to be quite like that. So what happens is that people who believe their opinions is in the minority. There's 15 people in this room. And clearly, eight or nine of them believe this way. They are probably not going to express their opinion. They will either self silence. I don't want to be an outlier. Or they're going to change their opinion. And either way, it makes anybody else who has the same minority opinion, it gives them much more trouble expressing their minority opinion. So the research that he cites in the book says that you take any group at all, and you create say a majority of conservatives and a minority of liberals. And that group after deliberation will become radically conservative. You create a group just randomly, same pool, and of a majority of liberals and a minority of conservatives, and that group will become raging liberal. Because people tend to go towards the majority opinion and change their opinion or anyway, not express an alternate opinion. That's scary. Because that says that we could be losing an awful lot of really good information on our teams, because we have some minorities, some people with minority ideas, minority opinions, outliers, some, and they don't have feel comfortable expressing their idea, especially when it becomes, it looks like it's in the minority. Or we have this thing called anchoring bias. So anchoring bias says whoever speaks first, whatever sets the tone tends to be the information that people take as the most weight. People tend to rely heavily upon the first thing that said in any group discussion. So if you look at those two biases of teams, you have a really challenging time making sure that you get all of the people on the team contributing their crazy ideas to the team. And there's a lots of things that don't let that happen, one of them being brainstorming, for example, because brainstorming tends to favor the, well, what did Neeraj say, the extroverts tends to favor the ones who speak loudest. It tends to not favor people who are working in a second language they're not particularly comfortable with, people who are in their background naturally more quiet, either from culture or from their way that they are. And those kinds of people could have very good ideas, usually do, but they have a much more challenging time making sure that the group considers their ideas, because if they start seeing the group going this way, it's very unlikely that they're going to say, stop, hold it, I've got this really crazy idea that you all are going to think it's stupid, but okay, how many times does that happen? And how many times is that idea really respected? So as I mentioned yesterday, one of the processes that I have come to like is the process called a design sprint. And one of the key things about a design sprint is you don't start with brainstorming. You have a group discussion about design of a product. And the first thing you do is start with quiet sketching. And you generate each person eight separate individual ideas over a couple of hours without talking. And then they're anonymously presented on disgust before you start having the group talk. There are many ways to keep a group from becoming, from succumbing to its biases. And that's one of them. And whenever you have teams, you have to think really hard about how do I make sure that a, you know, the manager doesn't speak first and anchor everything on the manager's opinion or something like that. So that's why I like this design process. And now we'll see if that thing still works. Where is my volume, guys? Remember my computer has, I'm going to do it again. Can you put that up nice and loud? Are you ready? To be more efficient and responsive, Google Ventures created the design sprint, a process for answering critical business questions in just five days. The first day of the sprint is for sharing information between departments and creating a simple user journey. Day two is sketch day, where the team works individually to generate creative solutions to the problem. On Wednesday, the team looks at all the solutions and decides on the best approach. Create a visual storyboard and you're ready for prototype Thursday. It's time to get productive and build your prototype. On the final day, you test your idea on real people to see if it has any value. If it does high fives, you're onto something great. If it doesn't, well, you've learned something. And the cost is only five days. So stop wasting your time and compress the endless debate cycle into a single design sprint week. So this is good, except I also am kind of biased against voting because that's another mechanism to have the minority opinion not be taken into account. So one of the things that we did at 3M when we were able to start up all sorts of new products is that if a person had an interesting idea and could gather one or two or three other people to try their idea out, they could do anything. And similarly in a team, I don't think you want everybody to agree and vote on what the team should do. I think that if somebody has a crazy idea and one or two other people are willing to help them move that idea a little bit further and investigate it, you want to be sure and make sure you're investigating a lot of different ideas, not just one. The whole concept in lean product development is set based design. Try many things and not similar things. Try one from this part of the design space, one from that part of the design space. So you are looking for crazy outlier ideas and finding a way to nurture them to the point where you know whether or not it's a good idea. So one of the things we want to be careful about working with teams is that we make sure we really leverage the diversity that we have in our teams. So let's go to the next one. That's about all I have time for to talk about with product. So let's talk about our process. I'm going to start with a story. Keep the volume up for the computer, okay? I'm going to do another little video here. And this is a true story. This is a story of Tom and he's in Cape Town, South Africa because I'm giving a talk and it's a breakfast sort of introductory talk and we're sitting at a table near the speakers place and I get up and start getting ready and Tom says, uh-oh I just lost a crown. He ate a toffee bar, right? Piece of candy and oops. And so if you ever lost a crown, anybody? Not good, right? Not especially because we were in the first week of a 10-week trip. We were not going to be home in the US at all for you know two and a half months. That's kind of common for us. And so I was in particularly happy and I was even less happy because one year earlier I was in Lima, Peru and again it was I swear it was the first week of a 10-week trip and I went to a pizza parlor and we had lunch and as I was eating my piece of pizza there was a piece of something in there that didn't taste like pizza and it turned out to be a chip from one of my teeth. I swear and there was a little bit of a hole and I decided that I it didn't hurt and maybe I could make it for 10 weeks before I got to the dentist and I did. I was lucky and when I got home I went to the dentist who made a crown, a temporary crown right? And she made the crown and then she gave it to me and put it in my mouth for a couple of weeks after which I guess it was 10 days and then the permanent crown came and I went back and I got it in there. So here we are in South Africa and we don't have any 10 days to wait for a permanent crown to be made. So this is a really big problem. So anyway Tom talked to some people at the table who said you are so lucky you are in South Africa. We have the best dentists in the world and I'm thinking like prove it. And so one of the guys gone on his mobile phone and looked around and some searching and dialed the number and says so there's a dentist about 10 minutes from here. We'll see you right now. I'll take you over there. And he did. Off they went. I got up, I gave my talk, halfway through the talk. Tom comes in the back door and he sort of waves like everything looks good. So at the end of the talk he says I'm supposed to go back at 3.30 and by 5 o'clock I'll have a new crown. I said really? So he went in at 3.30 and this is what they did. They did a 3D imaging of his mouth the dentist did and then took the 3D image, did a little bit of like stuff, wound a chip, ceramic chip, and put it in an NC machine and then he was in the NC machine. Not too much time. Maybe 10 minutes there was a crown, put it in his mouth and he was okay. And you know when he was engaged for that? This would cost approximately the same amount of that. Basically the same amount of money. 8 hours including waiting time. Like 10 days. So two weeks total time here from the time I got home. 8 hours total time there from the time that they called the dentist. Only an hour and a half that actually fixes tooth. So I'm only going to give that an hour and a half of actual tooth fixing value added time. Which means the flow efficiency in this process was close to 20%. Close to 20% of the time that he didn't have that he needed a crown was spent actually fixing the crown and there less than half a percent of the time was spent fixing my problem. Now which dentist provided the most efficient service? Think about this NC machine. How many teeth do you think it makes every day? Dennis says if I make two I pay for the machine. He probably makes four or five on the average a day of crowns and that is shipped to an NC machine which is busy all the time. So which is more efficient? Depends on who you look for. It depends on what's important to you. But if I'm a customer believe me I like that kind of efficiency a lot better than this kind of efficiency. So this is a concept of efficiency. What is efficient? And in this really wonderful book this is Lean, Nicholas Modek and Pyrrhonstern talk about the whole concept of flow efficiency versus resource efficiency. So from a resource efficient perspective the dentist in Minnesota is very efficient because she uses the NC machine and it's completely busy all the time and that's your expensive piece of gear. But from an efficiency point of flow which is a customer perspective the dentist in Cape Town was way more efficient because it only took one day to get that toothpaste. So busy is not the same as efficient. When we do work now think about the crown. There's a temporary crown. Is that adding value? There's mailing into the NC machine into the lab. There is the pile of teeth that are waiting to be milled and then there's the mailing back and then I have another trip into the dentist and take out the temporary crown. Think of all that extra work. That's not adding value. Only thing that adds value is cutting the tooth and putting it in. And so what you have when you have everybody busy is a lot of superfluous work. Think about this. How many features and functions are actually delivering value? Probably less than half of them. What if everybody and everything necessary to do a job just like the dentist in Cape Town was all there, was available, he was available. He had that two-hour slot at the end of every day left open for people like Tom to walk in. So what if everybody and everything necessary to do a job is in the same room at the same time and has everything they need to do a job. Now compare that imagination to what you do not. Everything else is superfluous. All of the juggling, all of the scheduling on and on and I could go that extra superfluous work that is not adding value. And then there's failure demand. How much of demand on your resources are caused by the fact that you make a mistake? Somebody sends in tooth and the crown is just a little crooked and they have to re-cut it and it's another two weeks or it gets mailed to the wrong place. When you have all that extra work you have ways for that extra work to fail. You have ways for defects to creep in. So when you have everybody busy that does not mean they're always adding value. So resource efficiency is not as efficient as you would think. Keeping everybody busy is not efficient. In fact if you think about it, this is from the Cosmotics graph. You can have high resource efficiency or you can have high flow efficiency. And people tend to want to be here. We want to keep everybody always busy, yes? And when you do that you actually aren't that efficient. You think you're up there but you're probably actually down here. Because there's probably an awful lot of stuff like temporary crowns. You're doing it but it doesn't need to be there. And so what you want to do is move over to here starting with flow efficiency first. In your process flow efficiency is the first thing then you can go for as much resource efficiency as you can get after that. So go for flow to begin with. How do you measure flow? This is a really simple equation. It's the time you spend actually working on a problem divided by the time the person with the problem is waiting for it to be fixed. Okay? So somebody has a problem, how long do they have to wait? Because they're the ones that decide whether or not you're efficient. And if you look at this and look at your process, how much flow efficiency do you really have? How much time does a customer with a problem have to wait to get it sold? That is the single most important question about your process. In fact, if you use that in a lean world that is the key metric. And I've seen a lot of people use it as the only metric in the company and it's a really rather impressive one. So just a really quick amount of how do I increase flow efficiency? How do I increase efficiency? Think about this. Which one's efficient? Okay. One of the things I would like to say is there is nothing, you know, a perfectly utilized highway is a parking lot. When it's completely full of cars and nothing moves, that's utilization. So that's not what you want. What you want to do is optimize for throughput, not utilization. We don't need our numerical machines busy all the time. We need time in and out in an hour and a half. So you need to optimize for your customer's throughput, not keeping everybody busy. So you want to minimize the number of things in process and minimize the size of things in process. I could go into that but I won't. That's just basic queuing theory. Very few things, very small things, and you will get a lot more throughput. Level the workload. Don't batch and queue. And you want to manage for pace, not individual tasks for the rate at which stuff gets done. Not have I done the schedule. And the last thing is you have to limit work to capacity. You need to know your capacity and then you have to not try to do more than you have the capacity to do. Otherwise you get backlogs. Which by the way are bad? Think about it. What does a backlog do to flow efficiency? Nothing good. All a backlog does to flow efficiency is make it bad. So from my perspective, backlogs are bad. You shouldn't have them. They're not good things. You want a time box. You don't want to say I've got to do all the scope. You want to say I've got three weeks. What can I do in three weeks? You want to pull don't push. And I have an interesting picture in that that I'm going to go and show you. So pull don't push. So say this is how much your output capacity is. What you need to do is say how many things do I deliver every, I don't know, whatever period. A week, two weeks, every release. How many items, how many features, how many changes, how many kind of things that I do, do I deliver here? And how many are coming in? Requests. And does this look familiar? This is what people want you to do and this is what you're capable of doing? Yes? Okay, actually almost every software organization I know of is in this situation. And the thing that you have to do, and you have to do it very proactively, is to accept the fact that stuff is not going to get done earlier rather than later. Which means you basically say, you know what? That's just wishful thinking. It's not going to happen. And the sooner we let everybody know that, the better off everybody is going to be. And one of the techniques for doing that is to create a limited queue, very, very short buffer, okay? And the purpose of this buffer is not to keep people quiet until their customers don't worry we're working on it. There's no variation in input flow. Nothing else. If you have an absolutely steady input, you don't need much of a buffer. If you have a seasonal thing, you might have to have a bigger buffer. What you want is always to have something there, but never to have too much there. Never to get it over full. And then of course it fills up, yes? Always. And what do you do with the next thing that comes in? What? No, this is your backlog. It's full. No more space. No more space. Yeah, one or the other has to go. You say, you know, you've got customers asking you for something, you have two responses. One is, dear customer, this is a great idea. And how I wish I had the capacity to do it. But I don't. Sorry. Or let's say this is a two week queue, okay? How long is it going to take for you to get at that stuff? If this is two weeks of work, stuff will be in there on the average of two weeks. If it's three weeks of work, stuff will be in there for three weeks. If it's six months of work, it's going to take six months. The shorter your queue, the faster stuff gets through. And if it's an honest buffer, not a pretend buffer, then you can say, the alternate thing you can say to your customers, dear customer, what a brilliant idea and you're going to have it in two weeks. And those are your only two answers. Yes, it fits in here and we know how long it's going to take to get done or sorry, we can't do it. Can we help you with some other solution? So that's the concept of pull down push. And bigger things, there's more to it, but I have to move on because I have like about five minutes left or something like that. So let's go to the last one here, which is code. Okay, so we have a product, things that we present to customers to make them awesome. We have a process where we want to focus on flow. And then we have code. And there's friction in code. You all have code and it all has friction, right? Hopefully less now than it used to a while ago. But you need to think about how do we not have friction in code. And there's lots and lots of talks here about that. I'm not going to try and replace them. I'm just going to sort of do a really quick thing here. And that is, there is something we know for sure. We know it from our experience. We know it from complexity theory. And that is, if you have a complex system, this does not work. Okay? You have a big something and you smash it with some big change. You have no idea what's going to happen. You can test the heck out of it. You can do all the stuff you want. But when you make a big smashing change to a complex code base, you don't know what's going to happen. All kinds of people wish you did, but the fact is, you don't. And the other thing we know for sure is what does work. This is what works. Yes? This is what works when you have complexity. You try something, you just poke it a little bit and you respond. And if you want to keep a code base under control, if you want to keep it from dying, if you want to keep it from surprising you, then your whole strategy needs to be really small changes. It's the only way to have an under control complex system. So you just set a start with this idea in mind. Small changes are the only way to make sure we have stuff under control. So that's why I'll just say one more thing and I'm sure you don't need to promote it much, but the first thing you want to do to make sure your code base is under control is figure out how you can do continuous delivery. Figure out how you can constantly poke your code base instead of having these big releases. Now big releases used to be every 18 months or every three years, then it moved to be every year and then it moved to be every three months. And today every two weeks is a big release. It really needs to be much more frequent than every couple of weeks in most code bases. Anything that's online should be able to be changed like basically all the time. So with continuous delivery you get stuff that's faster, better flow. You get stuff that's safer, way fewer unintended consequences and it's a smarter way to go. So just, you know, I don't have to go through this very much but these are the things that this husbandable says if you're doing this you're doing continuous delivery. Acceptance test driven development process, cross functional teams with all of the different people, product QA ops everybody, automated build, test, database, migration, you know, deployment, all that stuff. Incremental development on the main line. No branches. How many have branches? Okay, you got to ask yourself why but a lot of you don't want to answer. Software is always production ready. If not, stuff stops and makes a production ready and you deploy all the time. Now that doesn't mean that you can't do big changes. It means that you release separate from deploy. It's a different concept. Release is turn on the switch because I've decided it's time for this piece to go live. Deploy has been happening every couple hours or at the minimum every day all along. So that would be that and I'll just conclude with one picture here. When you're looking at digital organizations that really have a lot of success, there's some things that you see and some things that help make them success and that help get rid of their friction. One is they don't tend to have a monolithic architecture. They have small pieces, some sort of federated architecture. I'm not saying necessarily micro services but I am saying scaled out federated architecture. They don't do projects. Forget projects. They do constantly evolving products. They don't do features. They have problems that the team is asked to solve and the team figures out what kind of things do we want to do to solve that problem and test that the team can solve. They don't do estimates. I don't get why people would do estimates anymore. If you don't have somebody overlooking your shoulder and saying how are you spending your time, if instead you have somebody giving you a problem and saying do the best you can on this problem in three weeks, it's a whole different game and you don't need estimates. You need hypothesis. I believe that if they tend to have IT, they tend to have software engineers in the line business see more and more and more of this. Instead of outsourcing development, which we see less and less and less of, they're outsourcing infrastructure. They're heading to the cloud or something like that. They don't do testing at the end. Testing is a specification as opposed to does it work? They don't do periodic releases. They do continuous delivery. So when you get these kinds of things in line, first of all on that metric that I gave you, how much time is actually spent working on the product, the problem divided by how much time customers are waiting for it, that metric will get a whole lot better if you start thinking along these lines. So with that I think it's time and I should be taking questions. Is that right? Actually I'm one minute early so I can take one extra question. Yes, I'll go ahead. In a distributed product team I get the whole idea about not doing estimates and having hypotheses instead. What if you're not in the market to be able to test those hypotheses and you have more handoffs in between? Okay tell me again what if what? So if you're in a distributed product team, yep, you're building something in let's say Singapore for another market that's in another country and how do you know how does that team in Singapore know what to do? Yeah, exactly. No, tell me. You tell me. Product owner. Oh, okay. Why would we have one of those? Why would we need one of those? All that person is doing in this case is getting in between the team and the problem. Okay. I actually think the product owner is the worst problem that Scrum has visited upon the software development world that there is. Okay. Product owner as defined as Scrum is somebody that tells the team what to do, sets priorities, what an insult. Don't we have smart software engineers to whom we can give a problem and ask them to solve it? It doesn't mean there isn't a product manager setting strategy and figuring out the overall thing that we're trying to prop. But when it comes down to the details of what the team should do, somebody from over there telling a very smart team in Singapore of good software engineers, what's the next priority little dinky task, you know, you need to have a different process. I don't see any problem with remote as long as the people who can easily, who are tasked with solving the problem are also tasked with understanding the problem and figuring out how to solve it. Instead of having somebody over there figure out a solution, what do they know? Are you a product owner, an engineer? And they cut code? Do they know where the technology is moving next? Well then, what are they doing in between your smart engineering team and the customer that has a problem? Don't belong. That handover is really bad and we need to stop having it. Thank you. Yes. Mary, you mentioned loss aversion and in the context of that you showed an airline check-in. That's pretty much the business model for budget airlines. Yes, except Southwest, of course. How do they succeed then? Except Southwest. Okay, in the US, we have a really interesting counter example. The earliest first budget airline was Southwest and to this day it's the only airline in the US that does not charge for luggage. And they still, now they're huge. They kind of are one of the major players, but they maintain all of their, we will not aggravate the company, the customer with extra fees. And there are plenty of airlines in Europe that I won't fly because they annoy me. But that would be my preferred airline in the US because they don't annoy me. And when you have a whole package of stuff that an airline does that is about making sure that your customers are delighted, I believe you have a long term competitive advantage over somebody who's going to annoy customers. So I see the business model of those airlines and I think, okay, fine, but don't put me on one of those planes. Because if they're going to be saving money on luggage and stuff, they're going to be saving money on stuff that I'm not so comfortable with. So you think their days are numbered? Not necessarily. I don't necessarily think their days are numbered, but I would not invest in them. I would never put my money in them and say they're going to have a long term future that's bright. More questions? Okay, well, it's about time anyway that we head out and give the next group 10 minutes together. So thank you very much.