 Welcome everyone to the outcome-based product planning by Zeph. Without further delay, I'm passing over to Jeff. Excellent, thank you Trisha. Hey folks, good morning, good afternoon, good evening, wherever you are in the world. It's a pleasure to be here. Really nice to be part of Agilindia. Finally, as Naresh says in the chat, it's nice to be here. And nice to see some familiar names attending as well. So, Sava, I can't see your faces, but it is nice to see your names in the chat. I'm going to talk about outcome-based product planning. I'll share my slides here in just a second. We're going to talk about why it's important and how to do it and why it's something that actually drives the agility of an organization. So if we focus on agility rather than Agil, per se. So being Agil rather than doing Agil, one of the ways that we can get there is by planning our work towards outcomes. So let's talk about that. I'm going to share my screen. As was mentioned, if you have any questions or concerns, any comments, I'm sorry, put them in the chat. Any questions, you can put them in the Q&A module and I'll answer them as many as I can after the fact. So let's talk about outcome-based product planning. As always, we start with this question, which is always an interesting question. What do people love about the products that they love? Think about the products that always get high praise for success and a fantastic experience. Amazon, Netflix, Apple, whatever your favorite product is. If you were to ask a relative or a friend what they love about those products, I guarantee you that none of them would say, I love my iPhone because it was delivered on time. I like Amazon Prime because it was delivered on budget. That's not the reason. It's not how our customers measure success. It's not how our users measure success. Our users measure success in terms of whether or not their products solve a problem for them or if their products meet a need for them. People love their mobile phones because they make them happy. They keep them connected. They bring them closer, allow them to operate their business from wherever they are, among other many other things. This is the way consumers define success. If this is the way that they define success, this is the way that we should be defining the success of our products and services as well. Did we meet a need? Did we solve our problem? Instead of we delivered it on time and we delivered it on budget because our customers don't actually care about that. Did you actually solve a real need for me? If we're going to measure success in a different way, then we have to change actually how we plan and communicate our work. Now, the traditional way of planning and communicating our work has been in a linear fashion, in a roadmap or in a very... We're going to do this, then we're going to do this, and this, and that. There's a time and a place where linear product planning actually makes sense. When the thing that we're making is finite, we know exactly what it's going to look like when it's done. We know exactly what components need to go into it. We know how much work it's going to take to build it, and we have a very, very good sense of what people will do with it once we give it to them. In those situations where there is low risk and high certainty, linear product planning makes sense. Look, there was a time with software where it actually also made sense, and that was when software came in a box. If you think back, if you remember back, if you were alive back when software came in a box, you'll remember that there was... The software ended at some point. I worked at a company called America Online back in the 90s, and we would publish our software on CDs, and we would have to print 15 million of those CDs at a time, and so there was a clear end to the software, and there was a clear sense of what the software had to do when we reached that endpoint, and then we made a series of assumptions about what our customers would do with it, but at the very least, there was a linear plan there because there was a deadline, absolute deadline that we had to hit because we were physically producing media with the software on it, and so to communicate that, we use this metaphor, the roadmap, because the roadmap makes sense in a low risk, high certainty world. It's easier to communicate our plans in a linear fashion, and the map is a great metaphor for this kind of planning. We started point A, we've got a destination in point B, there's a distance between those, there's maybe some steps along the way, and we estimate how long it's going to take us to get from point A to point B. People can understand this, and they can communicate this, and this again makes sense in a world with static products, in a world where there's an absolute deadline and we can't move forward, right? But the reality of the software that we build today is that it doesn't conform to those qualities, right? Our world today is continuous, everything is continuous, right? The software that we build doesn't come in a box, it updates regularly, our apps update continuously, websites update continuously, systems, we send system updates all the time, and our businesses are being driven by software on top of that, and this idea that we can build a plan that says we're point A and we're going to point B, and these are the steps in between, starts to become very difficult to maintain in a world where everything is updating continuously and changing all the time, and frankly the pace of that is getting amazingly faster and faster and faster. I'll tell you that in 2015, when Josh Sidon and I started out to write our second book, Sense and Respond, we did some research and at that time Amazon was publishing code to production every 11.6 seconds, so five times a minute, Amazon was updating the system. Today it's every second, right? Amazon releases code to production somewhere in their systems every second, 60 times a minute, and in that world, right, of 60 times a minute, it's impossible to celebrate every software release, right? The deployment of software becomes a non-event. This idea that we can measure success simply by the fact that we've shipped something becomes moot when you can literally ship something every second. Now look, there at the extreme end of things, but it's worth noting that this is possible, right? And the idea that we can plan for this continuous deployment of updates and features becomes much more difficult to maintain if you're planning in a linear fashion. And that's just the technology side of things, right? It actually becomes increasingly more challenging when you bake in the humans, right? So there's the tech side of things. We can now deploy things very, very quickly. We can get ideas into the hands of our users very quickly, but we've got the human side of things and human behavior is complex and it's unpredictable. And so we don't have a guarantee of what our customers and our users are actually going to do with the software that we provide for them, right? We assume that they will do certain things. We hope that they will do certain things, but humans do strange things and we don't know exactly what they're going to do. And then of course, the other thing that happens is that their behavior emerges through the use of our products. So not only do they rarely do what we expect them to do, but ultimately they find ways to do things with our products that we never imagined, right? So a product that was designed just to connect people around the world like Facebook is now being used as a tool to sway elections and to do lots of other nasty things in the world. And these things just sort of emerge. We don't know what people are going to do. There's so much uncertainty. There's so much continuous change in the world that just because we plan something at one point doesn't mean it's still going to make sense when we get to that point in the plan, right? Because by the time we get there, things may have changed in the world. Things may have changed in the behavior of our customers. There might be some, you know, something has changed with the product that we're working on with the competition. So just because we made a plan initially, by the time we actually get to executing some of those steps, doesn't mean they actually make sense to build, right? And so if we're looking to increase the agility of our organization, we need to start to let go of these linear roadmaps because they're not agile. They're rigid, right? It's a strong word to say they are alive, but they are. We set expectations about a date in the future, what features we're going to deploy, the ROI that we're going to see from the roadmaps, and we're on the hook for it, right? But what if something new emerges, right? A competitive threat, a change in human behavior, something along those lines, it becomes really difficult to do. Let me, I mean, just to give you an example of this. In 2008, in October of 2008, I got a new job. I got a new job in New York City in a company called The Ladders. The Ladders at the time was a job search engine for people who were making more than $100,000 a year. So it's like an executive job search engine. And it's a two-sided marketplace. And the way that that website, that business stays healthy is we maintain a balanced ecosystem of jobs to job seekers. And we have that. Now, I got my job as the director of user experience in October of 2008. I don't know if you remember October of 2008, but that was a very, very bad month for the economy in the United States. Three weeks after I started my job, Lehman Brothers, the brokerage firm, melted down. And it started off, it kicked off the financial crisis of 2008 and the market crashed overnight, literally overnight. We went from a balanced ecosystem of jobs and job seekers to lots of job seekers, no jobs. We had a roadmap. We had a plan, features for the next nine months that we were going to build. What do we do? Do we follow the plan? Do we adjust course? We committed to those features, those dates, that ROI. How do we move that forward? And with those rigid product planning ideas, the question becomes, how can we respond effectively? And the answer is we can't. We can't be agile. We can't inspect and adapt. We can't sense and respond, build, measure, learn. If we're using these linear, rigid planning techniques, the world is going to throw obstacles at us, challenges, surprises. And it's going to break our plans. And it's going to challenge the organizational inertia behind the hours of work and negotiation that it took to get to this, right? So much time, so much effort is made to get to this approved roadmap. And then the world throws all these things at us. And it's going to be difficult for us to react if we continue to commit to this. So we're going to move away from rigid product planning. And we're going to redefine the way that we plan our work and communicate our work away from features, away from output and towards outcomes. That's going to be our goal, right? So let's talk about what an outcome based product plan looks like. The first thing we have to do is we actually have to change the questions that we're asking. If we're going to build a new way of product planning, excuse me, and a new way of communicating our work, we have to change the questions that we're asking to start the plan. The old question, and you know this question well, right? What will we build? We always ask this question, what are we going to make? What are we working on? What's the feature that we're going to ship this sprint? That's the old question. If we're going to shift to outcome based product planning, we need a new conversation. The new conversation is, the new question is, what will people be doing differently if we succeed? So it's not enough to say, hey, we're going to build this, right? The real question is, if we build the right feature and we design it well, we implement it successfully and people use it and it meets a need and it solves a problem, what will people be doing differently, right? Now the fundamental difference here is that what will we build is a question about output. It's about features, right? It's about planning features and dates and deadlines. What will people be doing differently is a conversation around outcomes. Outcomes are measurable changes in human behavior. And in a world where you can deploy software every second, right? The real measure of success is not did you ship the feature, it's did you impact the behavior of your users in a positive way? And how do you know, right? What are they doing differently now that we've built a system for them to use or a service or our product? So if we're going to start to shift to managing the outcomes, we have to change the question that we're asking. We're going to stop asking what are we building, focus on what will people be doing differently if we succeed? The next thing is we have to change how we view our work. Now we are often in a position, particularly if you work in a large successful company, where we take an inside out approach to product development, right? We build, we're big, we're successful, we know what customers want, we're going to push our ideas out into the market and people are going to love it and we're going to assume that they're going to love it and we're going to ship it and it's going to be fantastic. But the reality is that we are not geniuses delivering magic products to people who don't know they need them, right? The reality is if we're going to build an outcome based way of working, we have to become empathetic problem solvers for our users and then figure out to discover what solutions will make them successful. We have to take an outside in perspective, right? Head out of the building, understand our customers, learn what it is they're trying to achieve, what's getting in their way, what they're doing today, how well that's working for them, where there might be an opportunity for improvement and then develop solutions for them that will make them more successful. So instead of pushing these ideas out to them, we go out to them to learn and then bring that learning inside to change our perspective on the work that we're doing, right? The third question, the third step in changing our product planning to outcomes is to change the destination, right? Our goal isn't to target features, but our goal is to target specific changes in human behavior. Now a roadmap is a marketing tool with your plans for the coming quarter or year. I really like this definition because it doesn't say that you need to market a set of features. You can market a set of benefits or a set of outcomes. And when we start to think about it that way, this is what a high level outcome-based product plan could look like. Let's talk through this and let's work it through. So this is ultimately at a high level what can replace your feature-based roadmap, right? So we start at the top. We start with a longer-term strategic theme or an objective, right? What's the objective that we're trying to achieve for the next quarter or two quarters, maybe three quarters at most, right? And we can have multiple objectives with different teams assigned to each one. Then on a roughly quarterly basis, we set goals based on outcomes, based on key results. Key results in your OKRs are outcomes. They're measurable changes in human behavior. What are the behavior changes that we want to achieve this quarter? Maybe it's an acquisition goal, maybe it's a usage metric, maybe it's a retention metric, right? We're looking for those behaviors that are important to us this quarter, next quarter, et cetera. But we're going to commit to those as the goals for each quarter. We then have a conversation with our teams, with our colleagues to determine what we might actually build, right? But we couch these ideas in terms, in as hypotheses. Hypothesis reflect the fact that these are our best guesses about what we might build to hit these quarterly key results or these quarterly outcome goals. The nice thing about hypothesis statements is that they reflect the uncertainty of digital product development, right? They don't say we are building this. It says we believe we should build this, and if we do a great job, we expect to see this behavior change, which is the key result goal. Now, the interesting thing is about visibility, to think about visibility. In the short term, you might have decent visibility about what ideas you think you should work on, what ideas you think will work, what will actually deliver the key results and the outcomes that we're trying to achieve, and ultimately the strategic goal. So for the immediate first quarter, you've got a bunch of ideas. The second one, a few more ideas. The further out in time you look, the less accurately, you can predict what you're going to be working on. Remember, continuous change, pandemics, socio-political crises, changes in consumer consumption patterns, emergent behavior from the systems are all the things we talked about just a few minutes ago, and that's not even everything, right? All those things are going to impact what you might be working on in the future. And so to confidently say, well, here are 10 things we're going to work on three quarters from now, or four quarters from now is massively risky. And frankly, you're lying to yourself under your organization. And so as we look further into the future, we have fewer ideas about what we might be doing, right? And that's perfectly okay, because what we want to then do is check in periodically, right? Talk about what we shipped, what we learned, how we're trending towards our key results goals, towards our outcome-based goals, and then decide, okay, great, now what are we going to do in the next quarter, right? And so what we're doing is just in time planning on a quarterly basis, based on the evidence that we collected in the last quarter, right? Now, one way to consider the metaphor I like to use for this is imagine like this type of planning is like, it's like walking through a fog, right? If you've ever walked through a fog, you know, that you can see four or five steps ahead of you. But you can't see 10 steps or 20 steps ahead of you. So you're not going to go running full steam and just go, you know, in one direction and hope everything works out really well, right? Because you could hit a brick wall, you could fall off a cliff, right? There's a variety of reasons why you're not going to go running headfirst into a fog. But when you walk into a fog, if you take four or five small steps, let's call that a small batch, right? All of a sudden, you now reveal the next four or five steps, right? You can see into the fog four or five steps further, right? And if there's no obstacle in your way, terrific, we're going to keep moving forward in that direction. But if we start to discover that there are obstacles in our way ahead of us, once we've taken that small batch into the steps into the fog, right, we have to pivot, we have to change course. And that's what being agile is all about. It's about changing course based on evidence. And so when we start to plan with outcomes, right, the measure of success, again, isn't, right, did you build all the things on the roadmap, right? It's, are we hitting the behavior change goals that we set for ourselves? And if not, what do we need to change in our planning process in order to do that? And if we work in small batches, in this case, quarters, right, but whatever, whatever small batch makes sense for you, we collect evidence that then informs with greater certainty, right, the planning for the next quarter and the quarter after that. But three, four quarters in the future, still is generally a mystery to all of us, right? So let's talk about how to build this, right? Because I just showed it to you. Let's talk about how to build this kind of roadmap together. Okay, the first thing that we're going to do is we're going to start with a clear business problem. Okay, the question is what is the thing that's strategically important for us in the next six months, right? What are we trying to solve for? So here's an example of that hypothetical example, right, where we built, this is from an online learning service for lawyers, right? So we built our online learning service to help lawyers maintain their credentials, keep their skill sets current. And we've observed that customers sign up for an account, take one of our courses and then don't come back, right? This decreases the benefit of the product. It's expensive for us because that we have to continuously acquire new customers rather than selling additional courses to existing ones. That's the business problem that is important to us in the next three to six months. Okay, so we start with a clear business problem, right? What are you, what are you going to take on strategically in the next quarter or two? We then take that business problem and we turn it into a positive goal. If we solve the problem, what does that look like, right? So if I solve that problem where lawyers sign up for my service, take one course and then never come back and take another course, well, then I have built an effective and engaging continuing education learning product for the entirety of a lawyer's career to ensure their skills are current. That's my goal, right? I want to solve the problem. That's what it looks like if I solve the problem, right? What we've done here is we've written our first objective, right? The thing that goes at the top of the roadmap. This is our strategic goal for the next three to six months. We want to build an effective and engaging continuing education learning product for the entirety of a lawyer's career, which is great. Then we come back to our key question, right? If we solve the problem, if I achieve that objective, right? What will people be doing differently? Well, here's some things that would tell me that if I solve that objective, what people could potentially be doing differently, right? Each user will take at least three courses each year. 25% of new customers will come from word of mouth referrals and each law firm that signs up registers at least 50% of its staff. Now, what I've done here is I've defined my success criteria in terms of outcomes or in terms of key results, right? Every single one of these things on the screen is a measure of human behavior. It is an outcome. I've determined that if I see these behaviors, right, I will have achieved my objective. It means that I have chosen the right features. I've chosen the right business model, pricing model, value proposition, code, copy design to achieve these behavior changes, right? And the measure of success is not what I actually shipped. It's did I actually get these things to happen? And so what we've actually done here as we've written an OKR statement, right? Our objective is to build this effective online learning tool and our key results are at least these three behavior changes that can serve as the destination for our product planning efforts, right? As the quarterly key result goals, right? And so these things, they end up in that roadmap, right? The objective is at the top. The key results end up on a quarterly basis and that becomes what we're actually targeting. Now, the next step in the process is for us to work together as a team and to brainstorm solution hypotheses that may achieve those objectives and those key results and those outcomes, right? Because now we've got our strategic goal and now we've got our destination. We've got the behavior changes that we're targeting. Now we can talk about what might we build. And as I mentioned before, we want to talk about our work in terms of solution hypotheses because there is doubt, right? About whether or not these ideas are actually going to deliver the behavior change that we're looking for. Remember, all that uncertainty, all that continuous change that we talked about at the beginning, all those things threaten the success of your idea. So we write our feature ideas in terms of hypotheses because it reflects that uncertainty in the work, right? As much as we hate to say it, we all know it, right? Software development is difficult work. It's complex and it's unpredictable. And so let's reflect that in how we describe the work that we're going to do. This is the template that we use to write hypotheses. It starts with the words we believe, right? Because we don't know, right? We believe we will increase the number of classes taken by each customer by 300%, right? That's my behavior change, my outcome. If mid-career lawyers, that's my target audience, right? Feel like they're progressing ahead of average rates in their career. That's why they would care about this with a leaderboard of internal and external usage statistics, right? So I'm going to gamify the learning platform. That's my feature idea, right? Is it going to work? I don't know. Is this a compelling story? Yeah, I think it is. Is it a true story? I don't know yet, right? I believe it is. But we're going to have to figure out what their gamification is going to drive these mid-career lawyers to take at least three classes every time they come to the platform, right? And the hypotheses that we write become these quarterly activities as we showed before, right? I'm going to have a lot of those in the short term, fewer as we look further out over time. Once we've got the roadmap planned, we then need to start to assess the risks in our hypotheses, right? Because we're not sure. We're not confident. And so as we think about our hypotheses, we have to determine what's risky about them and then design experiments to test those ideas, right? What can we do to learn whether or not these are the right things to build? And as we identify these, the hypotheses that we want to work on, we have to ask two key questions, right? The first question is, what's the most important thing we need to learn first about this hypothesis, right? What's the biggest risk about it? And then once we've identified the biggest risk, what's the least amount of work we need to do to learn that, to understand whether that's a real risk or not and how we might mitigate it? And the answer to that second question is your experiment. Sometimes those are called MVPs, right? I just want to be clear that the goal here is to drive experimentation and learning. The example on your screen is from Rotterdam in the Netherlands, right? They're always trying to figure out where to put another bicycle rack for people to lock their bicycles. Now, what they could do is they could just build the bike rack, pour concrete, install these metal bike racks and hope that people use them, right? They ship the feature, which is what we do a lot at work every day, right? Instead, they run these experiments. They take this mobile bike rack, it's on wheels. They put it in a destination somewhere in the city where they think it will be helpful. They monitor the usage of this experiment, right? Do people lock their bikes here? How often, right? How many people do it? How many bikes are locked to it? And if the usage, the behavior change, the outcome, is sufficient enough, then they invest in making this permanent, right? But if it isn't, right? If people don't use it, if people don't lock their bikes here, they put them somewhere else, right? They will move this to another location in the city, right? They will pivot on this idea. They will kill this idea and they will try something else. And it's a perfect metaphor for the work that you're doing. Because again, the measure of success for the city of Rotterdam is not how many bike racks they've installed, right? It's how many people are using the bike racks. That's the goal, right? So they have to figure out the right configuration, the right location, and the same thing holds true for you. The measure for your success is not how many features did we ship, it's did we make our customers more successful, right? Are they doing things that benefit them and then ultimately us? Now, the interesting thing is that, look, this is just in time planning process. And so we need to put in check-ins that allow us to reflect, to decide, to plan further. I use quarterly as the delineation in time here, simply because a quarter is less than a year. And it works well for a lot of companies. Now, obviously, if a quarter doesn't make sense in your business, then use a timeframe that makes sense for you. But just whatever it is, make sure that it's shorter than what you're using today. And then we use those quarterly check-ins with our stakeholders to ask these questions, right? How are we trending towards those key results, those outcomes? Are we making progress towards them? What are we learning along the way? What's working? What's not working? What are experiments teaching us? The hypotheses that we've got planned for this quarter, are they proving true? Are they proving false? Which of those hypotheses should we keep funding? That's a big question. Which one should we stop funding because they're not working out? Is there a pivot that we should make? So maintain your strategy, but change the tactics. Are there hypotheses? They're just dead. They're not going to work. We're going to kill them and move away from them. Did we learn something new? And we should add that to our backlog now for the next quarter or this quarter or whatever it is. We want to have these conversations. But remember, these quarterly check-ins, they need to be forward-looking conversations. This is not a review or an assessment of what the team did in the last quarter. Ideally, all of that is already known. It's a conversation that says, what are we going to do in the next quarter? What have you learned along the way? And what are we doing moving forward? Very, very important to have these check-ins on a regular basis. I want to be super clear about this. I touched on it briefly with that example of the bike rack in Rotterdam in the Netherlands. But if you're going to plan your work this way and communicate this way, it explicitly requires your teams to do product discovery, to do research, to do experimentation. Because what you're committing to is behavior change, not features. And so it's up to you and your team to figure out the best combination of code and copy and design and business model and value proposition, et cetera, that's going to drive that behavior change. And you're going to be wrong some of the time. And so we need to learn how to do product discovery, how to do experimentation. We need to make the time for it in our backlogs. We need to make it a transparent activity and then build that into our planning, into our work, because inevitably it's going to affect the work in our backlogs. Now, this is going to face some obstacles inside your organizations. There's no doubt about it. Your colleagues are going to have a tough time with this. And certainly your stakeholders and your managers are going to have a tough time with this as well. And so the last thing I want to talk about is some of those challenges and what you can do to mitigate some of them. One of the interesting things is that there will be pushback and anxiety because there's a whole layer of middle managers who manage the teams that we work on that are used to telling us what to do. Go build this, make it blue, be done by Friday. That's my job. My job is to tell my team what to do. There's a lot of folks in those positions who believe that that is their job. When we manage the outcomes, the features emerge from the discovery work and the delivery work that we do on a quarterly basis. And so what happens is that this layer of middle management gets really anxious because what we've done is we've taken away a key management task from these middle managers. We've taken away the ability to tell people what to do. And they get scared. They get scared because if I don't tell people what to do, then what's my job? There's a lot of folks who believe that that's the defining quality of their management position is to tell people what to do. So for this to succeed, our middle managers need to realize that their job is changing as well. It's not telling people what to do. It's to help the teams define and clarify the strategy. What's the objective that we're working on to make sure everybody's clear and understand it? It's management's job to set guardrails and scope. We are focusing on the mobile channel. So we're going to focus on mobile only, not desktop mobile. We're going to set those guardrails and the scope to keep the team focused. If the evidence that comes back from the experimentation and the learning is unclear and it often is, management can help make key decisions. We're going to go in this direction instead of that direction. Management's job is to remove obstacles to allow this kind of work to take place. The discovery, the research, the pivoting, the learning, the agility, they need to figure out how to help the teams be successful to remove those obstacles and ultimately to facilitate their success to provide them with the tools and the access and the budgets that they need to do the work that they need to do. That is the job of middle management, certainly, and stakeholders on a team that is managing to outcomes rather than just telling the team what to build or what to do. Now, there's a flip side to this conversation, because those middle managers, well, they have bosses as well. And those bosses are going to ask them, well, what's your team doing? What are they up to? What are they working on? And it's terrifying for those middle managers to not have that answer, particularly if there's a lot of flux in the backlog. We're still doing a lot of learning. If my boss comes to me and says, hey, Jeff, what's your team working on? I don't know. It's not a good answer. We've got to provide a real answer. And so for this to be successful, we can't just make a demand on our managers to work differently. We, as the people on the teams, need to step up and work differently to make our bosses successful so they leave us alone and they can communicate clearly with their bosses. Our job as members of teams who want to manage to outcomes, want to work towards outcomes, is to build radical transparency into the way that we work. How do we make sure that everybody knows what we're working on, what we're trying, what we've experimented, what we've learned, what we've killed, what we've pivoted, what we've changed? How do we provide access to that on an ongoing basis? How do we make sure that that is visible and transparent to everyone? How do we over communicate? It's a good question. We want to over communicate to our leaders, to our managers, so that they have a clear sense at all times about what's happening on the team. I used to do this with a weekly email. You could do it with a check-in, you could do it with an email, and you can do it with a Slack channel, with a Wiki page, whatever. There's a million ways to do this, but the idea is that we are constantly communicating what we're working on, what we're learning, what decisions we're making, what's being shipped, how we're tracking towards our outcomes, etc. Every decision that we make as a team needs to be backed up with data. If we're going to ask for the ability to do product discovery, to collect data, we need to use that data to support our decisions. If we're going to communicate to our bosses, hey, we're not working on this hypothesis anymore, and we've added the second one, it's because the data that we've collected tells us that this is a better way to go. Every time that we have a conversation with our bosses, we want to reinforce that our key results, that our outcomes, are the goal. They'll say, well, I want you to build this. Okay, boss, that's terrific. How does this thing that you saw the competitors have, how does that help us achieve the outcomes that we're targeting? How do you think? Let's talk about that because the key goal is not to ship the feature, it's to change the behavior. And then, of course, be very, very consistent with your check-ins. Check-in with your leadership after every short cycle. And again, this is all about transparency and overcommunications. If you reduce that anxiety and that middle management layer, the odds of this succeeding increase exponentially because they're part of the process, they understand everything. The other pushback, you'll get regularly from sales. Sales will always say, look, how can I give you anything? If the features are in flux, what am I selling? How do I know what to sell? If you can't commit to a feature by a date for me, I can't do my job. Does that sound familiar from sales? And so we have to work with our sales team. Again, we want to be transparent with them. We want them to know what's happening, why it's happening. But the goal with sales is to convince them that they need to sell the benefit, not the feature. So it's not 48 megapixel camera, it's amazingly realistic video to see the new baby from across the country or across the world. Right? We want to speak in outcomes, help sales speak in outcomes. We're going to help you increase retention by 50%. We're going to make sure that your data integrity levels go up by 90%. Right? We're going to reduce the number of errors in your mortgage applications by 57%. Right? This is going to help you achieve this financial result because those outcomes inevitably translate into financial benefit for the buyers of our products and services. And so it's a shift for sales to move away from a series of features, right? To speaking to outcomes and the financial benefits of those outcomes. And so to do that, we have to include them in the conversation as well. Look, this way of working, right? Outcome-based product planning is the source of agility, right? It ensures that we're paying attention to how well our work is meeting the needs of our customers. Right? If we're not changing their behavior in a positive way, we have objective measures for that, and we can adjust our work to hopefully help them be more successful. The short cycles, the sprints that we use that come out of Agile, right, allow us to minimize investments and feature ideas that don't help us achieve our outcomes. Right? And in doing so, right, we're forcing our teams to go and figure out whether or not we're actually working on something that is worth investing in. And if it isn't, we can pivot and we can move quickly. And making course corrections based on evidence is agility, right? It is evidence-based decision-making rather than opinion or job title or salary-based decision-making, right? And most importantly, outcome-based product planning helps us stop lying to ourselves and our bosses and our clients and really focus on the features and the solutions that are going to make everybody ultimately much more successful. And so with that, I want to say thank you for listening. I hope you found that valuable. I hope you learned something. And I'm very much looking forward to your questions for the next few minutes as well. Thank you, Jeff. So we have so many questions today. So the first question is, are the quarterly goals or commitment or aspiration, particularly when there are many unknowns or moving paths to reach our objectives? No, no, it's a commitment. But it's a commitment that, you know, we want to set them as a stretch goal, right? So let's use retention as an example. Let's say we want to increase retention by 50%, right? If the team works for a quarter and comes back and says, hey, boss, we increase retention by 65%, right? What do you want to do next? That's great, right? But we kind of underestimated what our target should be. And so over time, you just kind of start to figure out sort of where that stretch goal is, right? If you're crushing your key results every single quarter, you're not trying hard enough, right? But they are your commitments. Your commitment is to get as close to that. You know, the expectation usually with key results is that you hit 75% to 80% of it, right? And so that's roughly the goal. You're committing to achieving 75% to 80% of the goal. But yeah, that's, you know, again, if you're crushing it every quarter, then we're not trying hard enough. But it is a commitment. It's not totally aspirational. Thank you, Chef. I think we have completed the time.