1 00:00:00,600 --> 00:00:04,300 The first step in understanding, how to solve our business problems, is to 2 00:00:04,600 --> 00:00:08,900 declare our assumptions and to build hypotheses based 3 00:00:08,900 --> 00:00:12,700 on those assumptions. And the reason we write hypotheses 4 00:00:12,700 --> 00:00:16,900 is that we are essentially stating what we know, 5 00:00:16,900 --> 00:00:20,900 stating what we assume and how will determine success right. 6 00:00:20,900 --> 00:00:24,800 Again, moving from doubt to certainty. And a video that I 7 00:00:24,800 --> 00:00:28,900 want to share with you that embodies this is Richard, Fineman 8 00:00:28,900 --> 00:00:29,500 from 9 00:00:30,000 --> 00:00:34,900 1864 talking about how science comes up 10 00:00:34,900 --> 00:00:38,900 with a new law because essentially, this is applying the same thing as scientific 11 00:00:38,900 --> 00:00:42,900 method to solving business problems. So this is Richard. Fineman 12 00:00:43,100 --> 00:00:47,800 in 1964, explaining to a room of young 13 00:00:47,800 --> 00:00:51,900 people. How science comes up with a 14 00:00:51,900 --> 00:00:52,500 new law. 15 00:00:53,300 --> 00:00:57,900 How we would look for a new law. In general. We look for new 16 00:00:57,900 --> 00:01:00,300 law by the following process. First we death it. 17 00:01:02,200 --> 00:01:06,900 Then we can don't laugh. That's the only truth. Then we compute the consequences 18 00:01:07,000 --> 00:01:07,900 of the guests. 19 00:01:09,600 --> 00:01:13,300 To see what if this is right, if this law, that we guess is, right, we see what it would 20 00:01:13,300 --> 00:01:17,700 imply. And then we compare those computation results 21 00:01:18,200 --> 00:01:22,700 through nature always say compared to experiment or experience. 22 00:01:25,300 --> 00:01:28,600 Compare it directly with observation to see if it works. 23 00:01:32,200 --> 00:01:34,300 If it disagrees with experiment. 24 00:01:36,000 --> 00:01:37,000 It's wrong. 25 00:01:38,200 --> 00:01:42,800 In that simple statement is the key to science. It doesn't make a difference. How 26 00:01:42,800 --> 00:01:46,900 beautiful your guest is it doesn't make you believe how smart you are, who made the get or 27 00:01:46,900 --> 00:01:49,600 what his name is. If it disagrees with experiment 28 00:01:49,600 --> 00:01:52,500 wrong, that's all there is to it. 29 00:01:52,600 --> 00:01:56,200 So that's dr. Fineman talking about how 30 00:01:56,200 --> 00:01:59,800 science comes up with a new law and essentially, this translates directly 31 00:01:59,800 --> 00:02:03,300 into how we solve business problems. 32 00:02:03,300 --> 00:02:07,600 We take a guess we declare our 33 00:02:07,600 --> 00:02:08,000 assumptions. 34 00:02:08,200 --> 00:02:12,700 It could be a very well educated guess but it is a gues, nonetheless, until we 35 00:02:12,700 --> 00:02:16,500 get direct feedback from the market that says this was 36 00:02:16,500 --> 00:02:20,800 right or this was wrong or it was somewhere in between we don't know if it was the right 37 00:02:20,800 --> 00:02:24,900 thing to build and so the experiments that we run 38 00:02:25,000 --> 00:02:29,900 help us determine the validity of our assumptions and our hypotheses. 39 00:02:32,000 --> 00:02:36,800 And if our results disagree with our guests, then our guess was 40 00:02:36,800 --> 00:02:40,200 wrong. And so it's an objective way to have 41 00:02:40,200 --> 00:02:44,600 conversations with your peers, your colleagues and your managers to say, 42 00:02:44,800 --> 00:02:48,800 that's an interesting idea, let's test it and then, let's figure out 43 00:02:48,800 --> 00:02:52,800 whether it's right or wrong. Now, Fineman says a lot of interesting things he says it doesn't 44 00:02:52,800 --> 00:02:56,900 matter how smart you are, absolutely, right? You can make a guess and you could still be wrong. 45 00:02:57,000 --> 00:02:59,300 It doesn't matter how beautiful your guesses. 46 00:03:00,800 --> 00:03:03,900 So you could design the most beautiful solution to something, 47 00:03:03,900 --> 00:03:07,800 but it could absolutely not work. Now he also says it 48 00:03:07,800 --> 00:03:11,800 doesn't matter who made the guess now in science, that's true 49 00:03:11,800 --> 00:03:15,800 in corporate reality. That may not be so true. Sometimes it 50 00:03:15,800 --> 00:03:19,200 does matter who made the guess and you need to have 51 00:03:19,200 --> 00:03:22,800 a deeper conversation about it. But at least 52 00:03:22,800 --> 00:03:26,400 with this framework, you have an objective 53 00:03:26,400 --> 00:03:30,500 conversation and objective success. 54 00:03:30,800 --> 00:03:34,800 That you can say, okay, you've made this, guess you've made this this 55 00:03:34,800 --> 00:03:38,800 request, we've run some experiments and we don't believe that it will 56 00:03:38,800 --> 00:03:42,800 work as well as you think it will. And then at least you can have an objective conversation about that 57 00:03:43,400 --> 00:03:47,900 around ideas whether it's a good idea or a bad idea, but it does actually matter who made 58 00:03:47,900 --> 00:03:51,600 the guest in our reality. And so the way we structure our hypotheses is that we 59 00:03:51,600 --> 00:03:55,700 declare our assumptions. And so we sit down together as a team as a 60 00:03:55,700 --> 00:03:59,700 cross-functional team and we ask ourselves what assumptions. Do we 61 00:03:59,700 --> 00:04:00,600 have about? 62 00:04:00,700 --> 00:04:04,500 Our customers and their pain points, and our 63 00:04:04,500 --> 00:04:08,700 solutions that have proven false will 64 00:04:08,700 --> 00:04:09,900 cause us to fail. 65 00:04:11,100 --> 00:04:15,700 In other words, what do we need to know to move forward to take those 66 00:04:15,700 --> 00:04:19,800 incremental steps from doubt to certainty. For example, if you're building 67 00:04:19,800 --> 00:04:22,200 a solution that's going to live on a tablet, 68 00:04:22,200 --> 00:04:26,900 will people be able to use a 69 00:04:26,900 --> 00:04:30,900 tablet in the situation that your service Works in? 70 00:04:30,900 --> 00:04:34,800 That's a fundamental assumption that you need to make. For example, if 71 00:04:34,800 --> 00:04:38,600 you'd like to use a tablet in an early childhood education context, 72 00:04:40,400 --> 00:04:44,700 is there an opportunity for a teacher or a student to engage with a tablet 73 00:04:44,900 --> 00:04:48,800 during class if they're five years old? That's a fundamental assumption 74 00:04:49,100 --> 00:04:53,600 that, we need to ask ourselves because if not, we're going to fail right out of the gate building a 75 00:04:53,600 --> 00:04:54,800 tablet solution. 76 00:04:56,000 --> 00:05:00,600 Now what's interesting is that when you start to apply lean to business, you start to 77 00:05:00,600 --> 00:05:04,800 focus on the design of business in the design of your assumptions. 78 00:05:07,000 --> 00:05:11,900 And when you dig deeper, you realize that every decision that you make about your product offering 79 00:05:11,900 --> 00:05:15,400 about your service is a design decision is a customer 80 00:05:15,400 --> 00:05:18,500 experience, design decision, 81 00:05:20,000 --> 00:05:24,700 It's not just what the button says, or where, to put the button or how many form 82 00:05:24,700 --> 00:05:28,800 fields we have, it's does the service cost money. Where is the pay 83 00:05:28,800 --> 00:05:32,500 wall? How do people tell their friends about it? How do we get people to the 84 00:05:32,500 --> 00:05:36,800 service? What if they have a problem with the service? One of the examples of like 85 00:05:36,800 --> 00:05:40,200 to use very often is the New York Times iPhone app, 86 00:05:41,000 --> 00:05:45,400 the New York Times iPhone app has terrific design, terrific 87 00:05:45,400 --> 00:05:49,600 typography. And if you like the content that the New York Times publishes, 88 00:05:49,800 --> 00:05:51,400 It has great content. 89 00:05:52,500 --> 00:05:56,900 And yet, if you look up the New York Times app in the, in the app 90 00:05:56,900 --> 00:06:00,600 store on a regular basis, it has a 1 or a 2 star rating, 91 00:06:00,600 --> 00:06:02,700 Max usually hovers around one. 92 00:06:04,000 --> 00:06:08,600 And the reason the number one complaint. If you read through the comments, people give it one star. 93 00:06:10,100 --> 00:06:10,900 It costs money. 94 00:06:13,700 --> 00:06:17,900 That's a design decision. And so if you start to 95 00:06:17,900 --> 00:06:21,900 build that mentality into the into the decision-making process of deciding what you're going to build, 96 00:06:21,900 --> 00:06:25,600 and how you're going to build it, then every design decision becomes a 97 00:06:25,600 --> 00:06:29,900 hypothesis, it's a guess, it's an educated guess, 98 00:06:30,500 --> 00:06:34,600 but it's still a guess. And so what we have to do as a team collectively, as declare our 99 00:06:34,600 --> 00:06:38,700 assumptions and then test them and when we get those results, 100 00:06:39,500 --> 00:06:43,300 we have to evaluate those results ruthlessly we 101 00:06:43,500 --> 00:06:47,800 To be brutally honest, with ourselves and be prepared to change 102 00:06:47,800 --> 00:06:48,500 course. 103 00:06:50,700 --> 00:06:54,600 Because if it's wrong, we don't want to work on it. That's waste, we want to reduce our 104 00:06:54,600 --> 00:06:58,700 inventory, our inventory in in software product development 105 00:06:59,000 --> 00:07:03,900 is a backlog of untested ideas, and we need to reduce that inventory. And by doing, 106 00:07:03,900 --> 00:07:07,800 so we would be reduce risk and we reduce waste now. Look, I'm a 107 00:07:07,800 --> 00:07:11,700 designer by trade, and it doesn't matter. 108 00:07:11,900 --> 00:07:15,900 We're hopelessly optimistic people designers, and it doesn't matter if we 109 00:07:15,900 --> 00:07:19,800 spent five minutes or five months and idea, when we make a 110 00:07:19,800 --> 00:07:20,400 design decision, 111 00:07:20,600 --> 00:07:24,500 And we know it's going to be huge, it's going to be fantastic. 112 00:07:26,300 --> 00:07:30,700 And so we work on it and then we launched it. Ah crap. Nobody clicked, 113 00:07:30,700 --> 00:07:33,300 nobody liked it. Nobody used it. It didn't work. 114 00:07:35,000 --> 00:07:39,700 Right? And so our job in this, in this collaborative, cross functional role is to 115 00:07:39,700 --> 00:07:43,600 reduce the time between these two points from months to 116 00:07:43,600 --> 00:07:47,900 ours, how can we learn a? No one's going to click this thing as fast as 117 00:07:47,900 --> 00:07:48,200 we can. 118 00:07:50,900 --> 00:07:54,700 And that's this new way of thinking, what if the old way of thinking is that 119 00:07:55,400 --> 00:07:59,900 you're working overtime, and you're building up all this risk. And so you build and you build, 120 00:07:59,900 --> 00:08:03,800 and you build, and then you launch over here and you've got all this risk built up 121 00:08:03,800 --> 00:08:07,500 time, investment money, you know, effort, 122 00:08:07,600 --> 00:08:11,800 Etc, commitments, marketing, budgets and so forth and then you launch it, if it doesn't 123 00:08:11,800 --> 00:08:15,800 work, that's a huge risk. In a huge. Gamble is extremely expensive 124 00:08:16,000 --> 00:08:20,200 instead, you bite off these small chunks of risk and you test them. 125 00:08:20,600 --> 00:08:24,800 And you learn whether it works or it doesn't and you, adjust course, as you move forward, just like 126 00:08:24,800 --> 00:08:28,700 you saw in the Nordstrom video paper prototypes, and then slightly, 127 00:08:28,700 --> 00:08:32,700 higher, Fidelity, prototypes, and then maybe an app that does one thing 128 00:08:32,700 --> 00:08:36,600 and maybe not that those two things and so forth. And as you move forward, 129 00:08:36,600 --> 00:08:40,600 you're iterating towards a more accurate Direction. Essentially, that, the old 130 00:08:40,600 --> 00:08:44,900 cliche plays nicely into this, you're going to nail it first, and then you're going 131 00:08:44,900 --> 00:08:48,400 to scale it and you do that by prioritizing 132 00:08:48,400 --> 00:08:50,300 learning overgrowth. The 133 00:08:50,700 --> 00:08:54,900 thing that you do is you prioritize learning, what do we need to know to 134 00:08:54,900 --> 00:08:55,900 move forward? 135 00:08:58,500 --> 00:09:02,800 And once we've learned enough, once we have a clear sense that yes this 136 00:09:02,800 --> 00:09:06,700 problem exists and yes the solution will work for people and they will actually 137 00:09:06,700 --> 00:09:10,900 integrated into their life. That's when we focus on growth 138 00:09:11,100 --> 00:09:12,000 and scaling. 139 00:09:13,000 --> 00:09:17,000 And we get to learning by prioritizing making over analysis. 140 00:09:18,200 --> 00:09:22,800 So we generate a lot of ideas and then we converge quickly and we just pick a direction. 141 00:09:23,000 --> 00:09:27,700 Even if we don't have enough data to pick that direction, we pick something because 142 00:09:27,700 --> 00:09:31,700 that Insight will come. If you've ever found yourself in a 143 00:09:31,700 --> 00:09:35,900 meeting talking with your colleagues, about how to solve a problem, how 144 00:09:35,900 --> 00:09:39,300 to design a solution, how to write a specific bit of code, 145 00:09:39,500 --> 00:09:43,800 how to fix something for the customer. And you're going around in circles. And you can't come to 146 00:09:43,800 --> 00:09:47,900 consensus or any kind of conclusion in that meeting the reality. 147 00:09:48,100 --> 00:09:52,800 Is that you don't have enough information to make that decision in that meeting? 148 00:09:54,500 --> 00:09:58,400 And that information is not going to magically appear, if you 149 00:09:58,400 --> 00:10:02,900 continue to speak to each other, in that meeting. And so, at some point you just 150 00:10:02,900 --> 00:10:06,900 need to make a decision, pick a direction, and make something and 151 00:10:06,900 --> 00:10:08,900 start learning from that. 152 00:10:09,800 --> 00:10:13,800 Because that helps you frame your business as a set of hypotheses. Okay, we don't know but 153 00:10:13,800 --> 00:10:17,600 we think this might be the way and then you start to test things in 154 00:10:17,600 --> 00:10:21,500 reality. And when you start to embrace this way of thinking, it allows your 155 00:10:21,500 --> 00:10:23,400 teams to move faster. 156 00:10:23,900 --> 00:10:27,700 So let's talk about what some typical product assumptions are. These are some 157 00:10:27,700 --> 00:10:29,800 typical products assumptions. Who is the user. 158 00:10:31,500 --> 00:10:35,900 The next time you sit down with your product teams. Ask this question, you'll 159 00:10:35,900 --> 00:10:39,700 be amazed at the variety of answers, you'll get from your colleagues who the 160 00:10:39,700 --> 00:10:43,700 customer is who's the user, where does our product fit into their work or 161 00:10:43,700 --> 00:10:47,400 life? What problems are we actually solving for them? 162 00:10:48,800 --> 00:10:52,600 When and how is our product used, what features do we think are 163 00:10:52,600 --> 00:10:53,500 important? 164 00:10:54,400 --> 00:10:58,700 Should we have an invitation feature? Should we not how should our product 165 00:10:58,700 --> 00:11:02,100 look and behave? And if you're a designer these should be very familiar 166 00:11:02,100 --> 00:11:06,700 questions for you to ask. But we should ask these questions of our entire team 167 00:11:06,700 --> 00:11:10,600 so that we start to build that shared understanding and that alignment 168 00:11:10,600 --> 00:11:14,600 and then move on to business assumptions because none of us 169 00:11:14,600 --> 00:11:18,600 operates in a vacuum we're not designing something in a vacuum where not engineering 170 00:11:18,600 --> 00:11:22,900 something in a vacuum, we're building a product to be used and to 171 00:11:22,900 --> 00:11:24,200 further our goal as an 172 00:11:24,400 --> 00:11:27,700 Relation or business, how are we going to acquire customers? 173 00:11:28,300 --> 00:11:32,700 How will people find this new feature that we're building or this new product? How 174 00:11:32,700 --> 00:11:33,800 will this make us money? 175 00:11:36,400 --> 00:11:40,800 Who are our competitors and what makes us better than them. What's our 176 00:11:40,800 --> 00:11:42,000 biggest risk? 177 00:11:43,300 --> 00:11:46,400 And then how do we expect to solve for that big risk? 178 00:11:47,600 --> 00:11:51,700 Sit down with your teams and literally asked everyone to write down the answers to these questions. 179 00:11:51,800 --> 00:11:55,900 You'll be amazed and what comes up and when you've gathered 180 00:11:55,900 --> 00:11:59,300 these assumptions from people, you can start to write your 181 00:11:59,300 --> 00:12:03,600 hypotheses. You can start to put them together now with the highest level, a 182 00:12:03,600 --> 00:12:07,400 hypothesis looks like this, you declare something that you believe 183 00:12:08,000 --> 00:12:11,600 to be true and you declare some kind of success criteria. 184 00:12:13,100 --> 00:12:17,700 So, we believe that this customer exists that this customer has this pain 185 00:12:17,700 --> 00:12:21,800 point and that building a specific thing for that, customer will change 186 00:12:21,800 --> 00:12:25,500 their behavior somehow to their benefit and two hours as a 187 00:12:25,500 --> 00:12:28,100 business and will know this is true. 188 00:12:29,300 --> 00:12:33,000 when we see certain outcomes or certain measures, 189 00:12:34,500 --> 00:12:38,700 Change in the real world and so to break the statement down a little 190 00:12:38,700 --> 00:12:42,800 further. This is the hypothesis statement that we write when we're 191 00:12:42,800 --> 00:12:44,200 building software products. 192 00:12:45,300 --> 00:12:49,400 We Believe now, believe is the key word Here. We believe We don't know. We 193 00:12:49,400 --> 00:12:53,600 believe that doing this. Now, the doing this is building this 194 00:12:53,600 --> 00:12:57,900 feature, the service, this widget, this API designing. This 195 00:12:57,900 --> 00:13:01,800 thing, whatever it is, we believe that doing this for 196 00:13:01,800 --> 00:13:05,600 these people. Let's get explicit about which members of our target 197 00:13:05,600 --> 00:13:09,000 audience or actually building this product for or this feature for 198 00:13:09,900 --> 00:13:13,300 maybe it's not for everyone, maybe it's just for a certain segment of our audience. 199 00:13:14,800 --> 00:13:18,800 So we believe that building this doing this for these people will achieve 200 00:13:18,800 --> 00:13:22,700 this outcome outcome is the change that we want to see 201 00:13:22,900 --> 00:13:26,000 after we build that feature. How will this 202 00:13:26,000 --> 00:13:29,900 change the behavior of the target audience that we're going after? 203 00:13:31,200 --> 00:13:35,300 And we'll know this is true when we see some kind of Market feedback. 204 00:13:38,100 --> 00:13:42,900 What can we measure that? Says that this change in behavior is actually happening, people 205 00:13:42,900 --> 00:13:46,600 are buying more, they're telling their friends. They are coming back more than 206 00:13:46,600 --> 00:13:50,600 once. What can we measure? 207 00:13:50,800 --> 00:13:54,800 That says, that there is an actual change in behavior, and these are the hypothesis statements 208 00:13:55,200 --> 00:13:56,400 that will need to write.