We've talked about the importance of narrative collaboration and learning the right things at the right time as you move forward. One thing that we are going to use throughout the course and the specialization to help us with that, is the venture design framework. And the idea is that we kind of go through loops with our product executions, where we want to make sure that we're starting with personas, that we'll cover a lot in the second module. These are humanized views of who our customer is. Then, we move on to problem scenarios and alternatives. These are jobs to be done, habits, desires, that we can observe and verify on the part of our user. And this helps us make sure. We know that we won't deliver something valuable, if we solve a problem that doesn't exist, and we, likewise, know that we will not deliver something valuable, if we build for a user that either doesn't exist, or we don't know who they are. Then, we move forward to value propositions, and assumptions, and what we're really asking here is, why do we think that what we're going to do is better enough than the things that our user is using right now to solve this problem? And what do we have to assume for that to be true, and how do we test those things? And then, we execute discovery and experimentation. Things that we can do without investing in a lot of software, if at all possible. Through prototypes, through experiments about motivation. Where we can verify that what we're going to do is compelling to the user. And we'll learn a lot about how to actually run that process in course two, Designs Prints. Then we move forward to the user stories, and the prototypes that we've talked about as being the centerpiece of driving to a high quality, valuable solution. And these are anchored in the items that proceed them, and yet we're able to use them as a very facile, very narrative day to day focal point for our activities. So we keep our eye on the ball, we know what's valuable to the user. And we look at whether those deliver or not and then that's how we know this is working, we can drive to good product, and if we see it's not working, then we loop back through and we make sure that we understand the sources of value to the user and that we're not building this software that is so ubiquitous that nobody wants. Another nice thing about doing things this way is that this works in reverse. And a lot of the work that I do in practice is about kind of debugging products or features that users don't like. So here, we move backwards from product and promotion. We look at, how do we implement what we implement, and did we instrument observation into that were we doing something compelling to the user? What problem were we solving with that, and then do we know who this person is? So that we can figure that stuff out. So, that is a framework that we'll be referencing so that we have a little bit of a structure to think about. What to do when and how to make sure that we're not wasting time on the wrong thing and building something that nobody wants.