 Ladies and gentlemen, thanks for joining the second last keynote of the day. Keep those thumbs up coming. We love that. Jeff loves those. Again, Jeff is someone who really does not need an introduction. He's a true legend. Someone that I have had the pleasure of working very closely with. I always tell people that he's been a role model for me, true inspiration. And the most shameful moment for me was sharing the stage with him when we both got the Gordian Pask Award. Oh, no rash. All right. We need to talk about that. That was an honor for me. But yeah, I mean, being a true honor to work with him, to learn from him, be influenced by him, some of his work on bringing user-centered design into Agile and now more broadly the whole product thinking into Agile has just been phenomenal. I think the originality of the work that Jeff does is just unbelievable. I remember having so many conversations with him where he'll sit down, he'll take a paper napkin, he'll just draw something and you're like, holy moly, like Jeff, how did you think about that? And it's just amazing to see that kind of a depth and we need all that wisdom from you, Jeff, today. We're going to suck it out of your brain. So without taking too much time, I give Jeff Patan to you. Thank you, Naresh. All right. I need to share a screen. We're recording, correct? Yes, we are. So you want to kickstart your screen sharing? You can see my screen. Let me make sure my picture is back on. And you can see my hands. I can ask you how many fingers am I holding up and you can see that. Great. Now I'm going to go back and forth between drawing pictures. I don't have napkins anymore. I've got a little bit better paper than Naresh just talked about. I'm here to talk about product thinking. I've been talking about product thinking ever since I started in software development. I started my career in the late 1980s, early 1990s, working for a small product company. And I learned software development there that way. And working for a product company is pretty cool. Generally people are pretty happy and pretty focused. Not always happy, but at least focused because everybody's working towards a common outcome. Now I thought this is the way software development work. It wasn't until in the mid-2000s that I joined a big consultancy and I started working with larger companies and banks and insurance companies and other people that I realized product thinking isn't built in to their organization or their culture and people work differently. What I want to talk about is the mindset and you've got to walk away from here recognizing when you've got a product mindset and when you don't. And what you can do about it because even the biggest companies fall out of this product mindset. Now I've got a quick question for you and I'm going to drop back to text here. What makes a product great? Let me see if I can pull up this discuss. If I ask the question what makes a product great or what makes it successful, what are the first words that come to mind and tell me anything that comes to mind? I see users love it. Usability, value. Now I'm not going to be able to keep up. Solves a user problem, fulfills the needs of the customer, fulfills the needs of value, commercial, monetary success. That's early for me. My handwriting is terrible. It'll get better over time. Makes life easier and usefulness. It makes users awesome. I'm going to get that one. Okay, you said more than I could write down anyway. But you get the idea. What I'm watching for, let me put quality in there. I saw that and emotional resonance. Oh my gosh, I can't stop writing these. Now I want to point out that nobody said finished on time or delivered under budget. Those are not product concerns. Now there's a model I draw every time and I want to redraw just enough of it so that I can put this stuff into context. In software development we spend a lot of time building software. Of course we start with ideas. If we're building a whole new product, the idea could be for a product. If you've got an existing product, those ideas are often for those features or enhancements. Those are the things that in software development we start referring to as our requirements. And yeah, people have heard me say this before. Anybody's heard me talk has. We're trying to turn these ideas into working software. We're turning dollars into software to start with. And since we're turning dollars into software, we worry about the time it's going to take. We worry about the cost. The cost doesn't pay for raw materials. It pays for people, humans, all of you listening to build this software. And then all this stuff is called scope. We spend a lot of time worrying about time, cost and scope. Everybody knows if you're building software or building technology for a living. This is the unbreakable, annoying triangle is the bad news triangle. It's bad news because you want to know what you can get, how long it's going to take and what's going to cost, but you can't. There's an old rule that you can know any too. If you fix the time in the scope, then the bad news is going to cost more. You fix the time in the cost and the bad news is you're going to get less scope. And you fix all three. The bad news is there's actually four. The fourth one is quality. Fix all three and quality squeezes out like toothpaste and a toothpaste too. But none of this is what matters. What matters to make a product successful is what your customers and users do and say. Look, we hope that when we ship this thing that they will see it. They will try it. They will use it. We hope that they keep using it. And we hope that they say good things. And when I ask you what makes a product great, these are the kinds of good things that people say. It's all this stuff that we're looking for. Now, all products aren't consumer products. By that I mean there are B2B products or things that we build for internal use. And we don't have to worry about whether people will see try use and keep using it because they have to. It's their job. But while we can make them use it, we cannot make them say good things. And then we look for other qualities like whether they become more efficient or more effective. By efficient I mean able to do more work, effective, doing better work. Those are the things that we look for. If we don't get those things, our product isn't great. It isn't successful. And we've got all these things that our customers and users do. But the point is you all work for companies or organizations. And your organization does not pay its bills with happy customers. It pays its bills with money. Your organization needs to sustain itself and to do that it needs cash. And it pays attention to revenue and metrics. And there are people inside that watch that. People see try use and keep using it. Well, that's when we get that commercial or monetary success. That's when we see things like ROI or lots of people say good things. That helps our brand awareness. Lots of people tell each other and more people buy. That helps our market share or how we do against our competitors. Your customers don't, ROI doesn't solve one of their problems. It doesn't fulfill one of their needs. It doesn't make them happy. It doesn't realize what your company needs to sustain itself. We turn cash into software and then we turn that software back into cash. And the way we do it is through this mechanism in the middle. Now I draw this thing all the time because I want people to separate what we build, the output from what we're focusing on when we think about products. And that's the outcome. The outcome is measured in what your customers and users do and say. This is super annoying. Our success is not what we do. It's what they do. And if they don't do it, we're not successful. And if enough of them don't do it, we don't get this business impact. Impact comes as a consequence and we measure impact inside, back inside the walls of our business. That's what matters. Now everybody knows that products are successful because of what our customers and users do. But yet we spend so much time worrying about time, cost, and scope. Now I want to change things a little bit. And I want to talk about a different kind of business, one where that time, cost, and scope kind of matters a lot more. Now I realize a lot of listeners are in India. I know that we've got some listeners that are in Europe or other places. I live in the United States. I live in a city called Park City, Utah. Park City is, it's high up in the mountains and there are lots of, there's ski resorts here, things like that. And I'm lucky I got a lot of space and the rush has seen this, but not for a while. This is my backyard or at least it was a month or so ago. My backyard was normally kind of crappy grass and a lot of trees and it's not really been usable. So this year we've invested in landscaping. We've had somebody come in with lots of equipment and level big parts of it. They brought in a lot of stone. They've done this stone work and created this patio. And the guy that I hired, this is Troy. He's my landscaper. He has a team of people. And I have a completely different question for you is, and that's what makes a landscaper great. So let's, let me flip back and make sure I can see what you're doing. I want to ask the exact same question. Sorry, let's see if I can do this. If I were to ask you the question, if you had to hire someone to do landscaping for you and not all of you have property to do that. Let me, good, you've got it. Delivers on time. What makes you happy? Yeah. Sorry, I can't write as fast delivers to my needs satisfying customer needs quality listens to you sustainability. And I wonder what you mean by sustainability and maybe the materials and things like that fits the budget. Somebody said drawings or prototypes, things that let me be sure I'm getting what I want. Well, yeah, cost. Again, by cost, you probably don't mean high cost. You mean moderate cost. It creates beauty completes on time. All right. I've missed some good things in there because I had my head down writing. Sit on time a couple times. I'm going to get that in there. That's good. Sorry, I'm having fun reading these things and I can't write them all. You get it. Now, let me explain the landscaping business to you because, well, it shouldn't be like the software business, but the way the landscaping business works is this. I'm a customer and I have a need. I have a need that I can't fulfill myself. So I need to find a landscaper. I need a landscaper. I need a landscaper. I need to go to the store or someone can do this. In this case, well, I ended up with Troy. I ended up talking with a lot of people and Troy has a full team of people to do things, people that do stonework and run that equipment that's in my backyard, things like that. And I explained to Troy what I want. His job is to listen and to understand. and forth with this description, because he ultimately needs to figure out what we're going to build, how we're going to build it, and more really importantly how much it's going to cost, and he will give me back an estimate. Now, this is where in the process I throw a WTF exception. The estimate is always more than I thought. I know there's a lot of things I want, and I've got a budget, but I don't know what's possible. I'm not a landscaper, I don't know how much this stuff costs, and even though I gave him sort of a budget, it still was just really high. This causes me to stress, and we go back and we go into this mode, I'm going to call negotiation, where we go back and forth. During negotiation, my goal is to get as much as I can, or as I can afford. I'm focused on my budget, and I would love it if he gave me everything for free. The problem is Troy has to make money, so he can't give me everything for free. He's got to pay all these people, he's got to pay for all these materials, and he needs to buy a bigger boat in a bigger house, and he wants to make money, but he also needs to keep his customers happy. He's thinking of those things while we're in negotiation. At some point in time, we agree on what we're going to build, I place an order, and in this situation we agree on it, we give him some money, and he gets to work, and he does the job. He worries about the timeframes we agree to, he worries about what we agreed to do, the scope, and he worries about the cost, and all along the way he's worrying about the quality also. He delivers what we agree to, he focuses on doing it on time, he focuses on keeping it beautiful, and those are the things he's doing. Now during this whole process, there are problems. He can't predict everything. We've had situations where there are cables buried in our yard that we didn't anticipate, so the original design didn't work unless we moved those cables and it was going to be too costly. Every time things kind of weren't what he predicted, we'll go back up into negotiation, go back up and question those estimates, and we go up and down this stack an awful lot. One day Troy cut my internet cable, and this sucked. I was working, and my internet went completely down. He apologized, he rushed electricians out to fix it. He was back within an hour or so, but I didn't pay for that. That was his mistake, and because he's making money, it comes out of his profit. Then, well, at the end, my yard is still not done. It's closer to done, but I'm hoping for a delivery. Now I'm drawing this whole process because it should look very familiar. In fact, let me title the top line requirements because this is the process that most organizations work with. This is the process I can almost guarantee that your company follows. In fact, in most organizations, if I relabel the business and this IT, the business gives requirements. IT gives estimates. Business is never happy with those estimates and we go into some negotiation mode and business is trying to get as much as they can for their budget and places in order. Things go wrong. It causes us to pop the stack, go back up the estimates and deal with complaints, and then we eventually do a delivery. That's the process we use. In fact, if you look at agile development off the shelf, I remember I started with an agile process called XP or Extreme Programming. My business card said product manager, but in XP I was referred to as the customer where I was fulfilling the customer role. In some cases, I could write the word PEO or product owner here or product manager, and I could write team over here. Product manager builds a backlog, brings what they want into the sprint planning session. Team estimates, some negotiation. At the end of sprint planning, we agree on what we're going to build. We do the work and at the end of sprint, we do a delivery and we take a look at what we're doing. Now, we end up focusing on all of these qualities. The annoying thing is we're not focusing on all of these qualities. This starts to be the fundamental difference between what product thinkers are focusing on and what we end up focusing on. Now, these things matter. If you don't deliver any output, then there's no outcome. We absolutely need to do this stuff predictably, but it's not the thing that matters most. If we focus too much on this stuff, this model does not work in your organization. This model works for Troy because of this one thing here, because of this making money thing. The way Troy makes money is he sells time. Because he's selling time, if he has too much work, all he has to do is hire more people. Every single person he hires, he marks up their time and makes more money. It's an awesome business model. If he has way too much work, he can hire more people. If he has way too much work, let me write these down. He can hire more people. He can just turn down work. The other thing he can do is he can raise prices. Raised prices will cause some customers to go away and allow them to make more money on the customers that he can afford to work with. What's interesting is I can almost guarantee, now some of you may work for agencies, things like that, but if you work for a product company, your company does not make money selling time. If I'm using Spotify or Amazon, I am not buying developer time. I'm buying a product. If I sign up for Spotify, I'm not going to judge Spotify by whether they're delivering the features I want on time. I'm going to judge Spotify by these product characteristics. This functioning, let me re-label this IT as a service model is the one that I see cast into companies and fundamentally changing the way we work and think. See if I can position this a little bit. The important thing for you to understand here is Troy is my backyard is not a product. It's my backyard. It's what I asked for. It fulfills my vision. I'm going to evaluate Troy on these capabilities. At the end of this job, Troy is not the owner of the product. I am. It's my product. I paid for it. One of the things going into my yard is this cool gas fire pit. We get a lot of snow here. It's very cold. I can turn on this fire pit and we can go out there in the winter and it's going to be fabulous. Now I like his design and it looks good, but when that fire pit goes in, if I see it, try to use it and then I decide it's kind of dumb and I don't keep using it, it is not Troy's problem. It's not his fault. He is not responsible for this outcome. It's not Troy's product. If there is more maintenance on this product, it's mine. I have to pay for it. The annoying thing in IT sometimes is IT builds a product and then they do end up owning maintenance of it. They do end up owning it oddly. A lot of things that make us a dysfunctional model, but the biggest single one is when we use this model inside of our organization, this is not the way your organization makes money. The way your organization converts that code into cash is this way if it's building a product. Now, let's talk about where I see that things go wrong is people starting to use or think that, well, let's be clear about this. When you're paying for custom work, the service provider is the product. Troy and his team is the product. That's the thing I look at. Troy and his team's qualities to hire him, not the product qualities. So when you start acting like a service provider, just be clear. You are the product. The thing you're building is no longer the product. What's more is the process you're using may be treating you like the product. I mentioned this about agile development and you need to be aware of the agile manifesto was written in 2001. It's 20 years since then. Agile is now the default process, but it was written from a service provider's mindset, meaning the people who wrote this in 2001, they were consultants and other people and they had this IT as a service model in their heads. This is why you see values like customer collaboration over contract negotiation. I want to be able to collaborate with somebody like Troy. I want to make sure that we're on the same page. When things change or go wrong, we want to work together. If you're on either side of that, that's a better working relationship. When you're paying for custom work, that's what works, but I don't negotiate with Netflix, Spotify, Amazon, Atlassian. I buy the product and there's not a negotiation over the price and definitely not a negotiation over the features that they're going to add for me. That value just doesn't make sense from a product context. The first principle in the agile manifesto is our highest priority to satisfy the customer through early and continuous delivery of valuable software. Now, that's great if you're in the software delivery business, but Amazon's not in the software delivery business and Netflix isn't in the software delivery business and GEO in India is in the software delivery business. That's not the thing. If you're a landscaper, I could rewrite that from a landscaper's perspective and say our highest priority is to satisfy the customer through early and continuous delivery of beautiful landscaping that works. I want you to feel when you're acting like a service provider. When you're treating the product owner like the customer, your business stakeholder like the customer and you're not paying attention to actual customers and then I want to give you a few ways to recognize or at least smell when you're acting like the product. I want to give you a few things you can do to stop acting like the product. The first tell is that you and your team are evaluated based on the velocity of your work or all those service provider characteristics. Don't mistake velocity for actual value. Value comes from those outcomes. They come after things come out. All your organization is looking at or all those service provider qualities and that's starting to be a problem. You're the product. If someone outside your team decides what you'll build and you rely on their approval before considering the work done, well then your team is kind of the product. Just like Troy relies on me deciding what to build and relies on me saying it's done, then Troy can't take responsibility for the outcome because he didn't decide what the output was going to be. Now if your biggest risks are always whether you can deliver this stuff on time or whether you've got all that scope and if the risks aren't really about whether the product will be successful or whether people will use it and love it and it will make money for our company, then you're probably the product if you're not aware of those risks and if you and your team don't actually know the real customer or the real customer and the real outcomes of your work. If you deliver a product and you don't know if people saw it, try it, use it and keep using it. If the outcome is invisible or you're gone by the time the outcome gets generated, you might be, you're the product. Let me point out one thing. This is a hard pattern to get out from underneath and if look, if you are the product and you work, let's say you work for an agency or big firm and you are hired by another customer, I want to tell you how to, there's at least one successful way to be the product but really keep your focus on outcomes. I'm going to draw this, I just drew this continuum here. On one side of the continuum, I'm going to put the word, sorry, waiter and on the other side of the continuum, I'm going to put the word doctor. I need you to bend more towards working like a doctor. What I mean by that is, well, we know how a restaurant works. You show up at a restaurant, you order food, the waiter should listen and be attentive, suggest things to you, bring you everything you ask for, the more food you order, the better and if you leave having a great dining experience, that's fabulous. But when you show up at the doctor's office, the first thing your doctor does is to check your KPIs or my doctor will check my body temperature, my heart rate, my blood pressure and make me step on a scale and check my weight. For years, my doctor's been saying I'm way too fat and I need to lose weight and my cholesterol is high. And doctors right away, she starts by telling me stuff I don't want to know, telling me stuff about that I don't like to hear. Try and give a doctor your list of requirements, tell them these are the prescriptions I'd like you to write for me or this is the operation I'd like you to schedule. The doctor says that's nice, tell me where it hurts. When you say the term outcome to a doctor, they know what it means. It means your health. It means how you're doing. It does not mean how many prescriptions they've written. Doctors and real professionals focus more on their customer's outcome and if you're going to, look, if you must work in this kind of process, be more like a doctor. Help your customer's focus on their outcome the same way my doctor helps me focus on my health. Now, I wanted to finish in time to answer a couple of questions. Let's see if I can get this last chunk of stuff through. I'd like to give you a few things you can do right now if you're stuck in this kind of work mode. I wonder how many pictures I can draw here. The first thing you do is to stop pulling backlog items off of a backlog and actually understand what your products are. Now, just identify your products or give them names if they don't already have one. I think I do want to draw a picture here because this gets hard in big companies. Look, if you were making Spotify or you worked for Atlassian when you were building Jira, you probably know what your products are, but I work with a lot of companies that are large banks and telcos and things like that. Sorry, I'm going to pull back. I have a right heading here. Understanding what your products are gets a little bit messy. Now, first thing you need to understand is that products are composed of other products. If you have a car or a scooter, it's a product and if you were to take a wrench or screwdriver to it and start to take it apart, all those parts are also products. In particular, if you pull off a tire and look at it, it's a product. You can buy it separately and the brand name on the outside of the tire isn't Toyota or Honda. It's whoever made the tire. It's a separate product. When we look at our products that we build for our customers, we have to unpack them. For instance, I'm going to call some types of products end-point products, the stuff we sell to our customers. Let me use a bank as an example. If you work for a bank, your end-point products are things like a checking account or a credit card or a loan. But look, for me to work with a credit card or get a checking account, there are a lot of other products that need to support that. Let's talk about customer supporting products. For instance, if I'm going to work with a credit card, look, I'd like to have a website that I can learn about the card or sign up for it. I want to have a mobile app that lets me do things with that card. Look, there are also employee supporting products. If I work for the bank and I work in a branch, there are branch applications that allow me to work directly with customers. If I work in a call center, there are call center apps. Look, all of these are products. Also, a mobile app is a product, a website is a product, a call center app is a product, but their constituents are part of this whole customer experience. Then one last type of product that ends up being deep inside your organization. I'm going to call this a product team supporting product. For instance, if I build apps for a bank, if I'm building a website for a bank, I'm going to need to have something that allows me to show customer information, show current balances, things like that. Same with a mobile app, same with branch apps, same with call center apps. I don't want every one of these product teams to rebuild their same stuff. We often externalize and we have things like common services or components. Those are products, but the primary customer for these common services or components, well, the primary customer is written in the name. It's other product teams. The other product teams see, try, use, and keep using and say good things about the components. If they don't, you suck as a product supplier team. You need to be aware of who your customers are. Every one of these kinds of product teams, your customers are clearly indicated. One other thing to point out here is product, these back end product team supplying products have a way of drifting outside of your company and they end up becoming, well, a partner supporting. People like Salesforce years ago had an internal framework they used to build their product, but Salesforce's app drifted outside and now people commonly build apps on that force framework. Some of you probably do that for a living today. Work with lots of organizations where what they built here when they treat it like a product, well, it migrates out here pretty effectively. Understand what your products are and then once you understand what those products are, now you've got a few things you can do. The first thing to do is to actually evaluate the success of your products today. What are people seeing and saying about the product you've already got? If you're responsible for the outcomes, take some time and understand what the outcomes you already have are if you ship that product. Is it getting used? What features get used the most which don't and you may not have data on these things, but trust your gut or talk to people, gather anecdotal information. Now I talk about building simple models that help the team understand your product. I build things like simple personas that let people understand who our customers are and what their concerns are and things like, well, they're like a story map, but a journey map that describes the product we have today and where its problems are. Once you understand your customers really get to know who those customers are, meet them, talk to them, or talk to other people at least that talk to them. Now, I keep using the term customers and users and we conflate these things all the time. Customers choose a product, users use a product. For consumer applications, they're the same people. The chooser and user are the same people, but look, if you're using Jira in your company, I can guarantee you didn't choose it, but you use it, you're a user. B2B products, users and choosers are separate. Make sure you understand that and well understand how your customers get value from it and how your users use it and do their jobs with it. All right, fourth thing here is once you understand your product, what your product is, how it's going now, what your who your customers are and what they want out of it, you're going to find opportunities for improving your product as it is. Contemporary products continuously improve, they don't improve with big fat releases, there's no cool next new version of Spotify coming, there's no next new version of what other application, no next, no cool new version of Jira or Trello coming, rather they continuously improve with lots of small changes and product teams are the ones responsible for the outcome, so they identify their own backlog items ideally. Before you build anything, talk about the expected outcome. What do we expect? Who will use this functionality? How often will they be more efficient and more effective and then for extra credit, how would we actually measure if they were? How do we measure who's using it and how often and how fast they can do things or how many errors they make when they're doing it? This sets us up to measure outcomes, not just, yeah, this sets us up to measure outcomes. Now that last bullet is you need to understand that the relationship between outcome and impact. Last thing, and I can give you this, see if I can do this in a minute, so we only have five minutes for questions. Look, if your organization ships and if you're using an agile process today, I can almost guarantee that at the end of every sprint or iteration, you stop and reflect on your velocity or your quality or how well you did. You might demonstrate their product and stakeholders might say they like it or that's good, but that's not the outcome. I want you to continuously reflect on the outcome and impact of everything you deliver. Let me draw just a very quick model, I think I can do this in one minute, I'm already too late as it is. If you've got a feature, and remember a feature isn't a story or isn't a backlog item, it sometimes takes lots of backlog items to build a feature you can release. After you release every feature, look at, stop and talk about the actual effort it took, meaning if it was small, it took days or if it took days or weeks, it's going to float to the left. If it took months, it's going to float into the middle. If it took quarters, it's going to float to the right. Where did things actually end up? Now, you might have predicted things were going to take a few weeks, but they took a few months, and if they were longer than predicted, I'll ask people to note what took longer than we predicted. Of course, they're going to be on the right hand side. You're going to quickly see that little things are more predictable than big things, just the way it is. But then I want you to look at the actual outcome. Now, everything you ship starts in the don't know category, meaning if I just barely shipped it or haven't shipped it yet, I don't know what the outcome is because I can't measure outcome until things come out. But when users start to see it and try it and use it, you've got a scale here that at the top is awesome, meaning people used it at the rate we thought they loved it. The bottom is awful. People used it, hated it, complained, and in the middle is this meh zone. And the problem is you can't talk about this at the end of every sprint. You have to talk about this over time. You may have to wait weeks or months to be able to start getting outcomes and things will start to bubble up or start to move around. The first thing you're going to see or realize is that how long something took has nothing to do with the outcome. You'll find that little things get awesome outcomes and big things can get awful outcomes. You'll also find that how late something was has nothing to do with the outcome. I can deliver something on time and it can still be awful. I can deliver something late and it can still be awesome. There's no correlation between this is the confounding thing. How well you do with this has very little to do with how well you do at that outcome thing. Being product centric shifts your focus to those outcomes and I'm hoping you can start to smell what I mean by this and start to feel it inside your organization. Product thinking moves your focus to outcomes, the success of the product you're creating and improving, not just the effort it took to do it. Don't mistake being a good service provider, being reliable and dependable and delivering what you said you would for being a good product developer. They're not the same thing. Your company succeeds when its product succeeds. If your product is a service like my friend Troy, he's going to be successful when he is reliable and does all those right things. If you work for a company that actually builds a product, it's going to succeed when your customers actually use your products and love those things. All right, I blew it. Only two, maybe time for one question if that, but that's all I've got here. Awesome, thanks Jeff. That was really great. You can see the likes. They're hitting about 10k mark. We'll see if we can cross that. I think people were so busy in listening that I don't see many questions. I talked so fast. I hope you got anything out of that. And again, I was hoping to end a little bit earlier, but there may be time for one if there was. Let's give it a shot. Do you want to look at it? I'm looking at it right now and I'm seeing lots of thank you for the thanks. I don't see any questions in there. Do you see the Q&A on the top? Oh, sorry. Yeah, I'm looking at the, there we go. Yeah, I'll just start from the top. Sometimes the product owner or product manager doesn't work closely with the development team and refers to be outside. What can we say to them? We'll convert them sooner rather than later. Now, I teach product ownership and the stuff I'm talking to you about, I make sure, one of the things I could have, I really emphasize your job as a product owner is to be a leader of a product team, to be a strong collaborator, and to not separate the team off as a service provider. So I want them to smell it. So it is bad behavior. But if you're a team member on that team, if you just go back to those questions I ended with, if you're asked to build a backlog item, look, one of the things that's supposed to be coming through in our user stories is who they're for and what benefit they'll get. And next time you're in a backlog refinement session, ask, we're building a story, who is it for? How are they going to benefit? And how would we measure success? By success, I mean, they're going to use it. How would we measure how frequently they're going to use it? What do we expect? Keep moving the discussion to outcomes. Now, this can be a little upsetting sometimes your product owner may not know the outcomes. If they are acting as a service provider for the business, and the business didn't tell them. So it can be a little uncomfortable. But all you can do is keep moving the discussion to what just ask what happens when things come out and how would we measure success? That's all I thought. And I'm worried about time. We need to We can take a couple of more. That's okay. And I'm such a slow reader, man. And the questions are starting to come in here. From this session becomes clear that product slash outcome approach is so beneficial. So I wonder why organizations don't follow it everywhere. Also at organization level, are there any challenges that come in built with the implementation that may be hindering or missing? That's a tough question. I've been the first part of the question I've been pondering for years. If this is so obvious, why doesn't everybody do it? My gut is that people are much more familiar with this pattern of business. Everybody's heard mantras like the customer is always right. Everybody's heard the notion that the other people inside of our company are customers. And when anybody asks you to do something, you're a customer. And your company really did hire you and pays you to do work. And so it does feel like we're a contractor. This is more of a common pattern. The way traditional management works, management jobs to tell people what to do and to measure how well they did what they said they were going to do. I believe the reason it's so prevalent is this is a much more common pattern. But I think people are losing the plot. Gosh, it's too big of a question. The way organizations are trying to move themselves away from this is to really start to make outcomes visible. Things like OKRs and metrics, things like that and do that. Those are the only way to move it. Nuresh, you're about to interrupt me. I didn't, I think I... Sorry, Jeff. I just wanted to add there that the question is really interesting. And one of my insights have been that being a product and outcome-centric organization is taking more risk than many organizations have appetite for. The services kind of a thing that you get paid for time is much less riskier business, if you will. Does that make sense? It does. And one of the... Oh gosh, I was hunting for a quote. It's riskier. If I can tell you what to build and check to see if you did what you said you were going to do, that's something as a leader, as a manager, as a business I can measure. That's something I can wrap governance around. I can say, did you do what you said you're going to do? But if you thought predicting how long it's going to take to do something is hard, try predicting how successful the thing you built is. These outcome things are a lot less predictable. They're hard. And the annoying thing about outcomes is they take a long time to measure. Once you ship something, you can... Once you finish building something, you can evaluate the quality of what you build. You can always evaluate time, cost, and scope. One of the reasons I'll ask people to visualize outcomes is one of the things I'll start to notice is it takes a while. If you work for Atlassian and you were building features for Jira, to know if people keep using your Jira feature is going to take two to six sprints in actual calendar time. That's going to be months. Minimum a month, but one to three months is common. Measuring outcomes sucks and measuring impact or return on investment even longer term. We end up drawing our focus to outputs because those are the things we can see and control a little bit better. But they're not how your business makes money. That's the hard part. I'm left with these conundrums of how we change that. But I think good, well-meaning people just fall into this trap. But I'm rambling. Do we have time for another question? Jeff, I don't know how to thank you, but this is such a wonderful talk and such an important talk. I wish a lot more people pay attention to this distinction that you draw. It's really great. Thank you so much, Jeff. I know it was really early for you. You were up at 4.30 in the morning. I appreciate that. Not a problem. I'm happy to do it. Thank you, everyone. Thanks for being there. Bye-bye.