A central concept in this course this is idea of using hypothesis-driven development to take our ideas and make sure that they're testable. For our purposes, a hypothesis is just basically a testable statement or idea. If you're joining me for the adult specialization, you've already learned a lot about this in the last course. We're going to do a quick review here, but if you are left with questions, there's a written reference you can use to dive into a few of the details if you want to do that. So let's have a look at this product pipeline and talk about how hypothesis-driven development relates to it. We've got these three big focal points. With hypothesis-driven development in this course, we're really going to focus on the relationship between continuous design, and providing really good strong inputs to our development and process, and a little bit to our delivery process. This idea of finding the right problem to solve and then finding the right solution, and decoupling problem and solution is a really key concept to innovating in general, and definitely innovating purposely with analytics. Because if we don't decouple those things and know what we're trying to analyze, we're probably going to apply the wrong tools and the wrong analytics to what might be the right question. So the basic idea with this framing is that we find the right problem. Words are faulty instruments. This might mean job, habit, desire in the circumstances that you're working in. We consider a lot of possibilities and then we went on them down through testing to something that's actually important to our user. Then we look at whether that thing it's important loans itself to us building something that's better than the alternatives that they have today, and we find ways to test that with tools like lean startup. Then we execute a good solution. That means prototyping, using user stories to iterate purposefully, and ultimately, building working product that we release to the user. If we unpack this into hypotheses, we have for the purposes of the course, a persona hypothesis about who our users are and what makes them tick. We have a problem or job to be done hypothesis about what is on their A list. Because if we solve a problem, we do a job, we deliver on a habit that doesn't actually exist for them, that they don't care about, we can do everything else perfectly, and then we're just going to be multiplying by zero and get nowhere. We have a demand or value hypothesis about whether what we're going to do is better enough than the current alternatives that our user has at doing this job, delivering on this habit, solving this problem, that it's worth investing in. We decouple the assumptions about that from the assumptions about usability and we find ways to specifically isolate and test demand, or value, or motivation for the subject, or user, customer to have our particular proposition. Then we have a usability hypothesis about given that user wants to do this certain thing and we've tested that, how do we make sure that that experience is highly usable? Now what I've done with this for you, I hope, is made these things relatively rigorous, so you can apply the right analytics to the right questions, and yet practical. I know that you're busy, you have a bunch of different things going on, and we don't want a big complicated thing because the most important thing about hypothesis-driven development and the practice of Agile analytics is that it's something you're able to make a habit of and do every day. So as we go through this, we're going to look a lot at this continuous design process, how it relates to our practice of Agile, and how we can use the right tools to ask the right questions and get actionable answers from them.
