We looked at a bunch of MVPs, a lot of the most effective ones were scrappy creative. They will ran in about a week, I think, a one week design sprint is a great fit for this. There is no exact right recipe that'll be good for every situation. There is an example though in the course resources, and I thought I'd call attention to a few things. First of all, what do you need to have ready to go into this design sprint? It's a matter of judgment. If you have a pretty good idea about generally what you want to do, you might want to do more advanced prep versus if you're really not sure and you really want to get the input of your team, you may leave this more open-ended. That's an assessment, though you should make explicitly, purposefully for yourself and decide which way you want to go. Because if you're going to invest your team's time and you already know what you want to do, I would strongly advise doing a bunch of that prep beforehand so that you're using their time well during that week. So let's just step through a few high points on each of the days for this one example. In day one, you probably want to have some experiment prep done, there's a sprint checklist you can look at sort of generic. What you're really doing is working with your team to think about, what are the assumptions? How we unpack them and dimension them in terms of, there are number of ways you might want to do that, you might want to look at which ones are the riskiest? Which ones have the most important consequences? Ultimately, you got to arrive at a ranked list of assumptions that you're thinking about how you're going to pair with MVPs. Then you need to sketch out those MVPs and think about their viability and overall, you need to make a pragmatic final decision about which one is the best fit that you want to go and execute. On days two to four, I think generally the inputs are the outputs from day one, and you're executing this MVP. Depending on what type it is, the outputs are going to be a little different. The outputs of a concierge MVP are a little more observational, the outputs of smoke tests MVPs are a little more quantitative. But you want to keep everybody focused on keeping the experiment nice and tight and looking at what results you're going to get. A great thing to do is design the report or the metrics that you want to look at it at the end of the experiment in advance, so you know exactly where you want to get to, to make a conclusion. Then finally, on the fifth day, what I recommend doing is just looking at the results, and stepping back, and taking a minute, and thinking about what you learned, what you didn't learn, and in classic Agile fashion, grooming the ideas for what you want to do the next week, whether it's build software or run another experiment. Those are a few high points. The main thing is that taking an MVP to real users is still a bunch of work. Now it is, way, way less work to building actual product, but it is important to be prepared. The other thing I want to mention is, they're messy. The first time you run one of these, they'll probably be lots of rough edges, but it's a really important skill set. Lean startup has really fundamentally changed the way we look at creating start-ups and just innovation in general. So good skillset to develop, even if it's a little challenging and it does take some practice. Good luck with your design sprint and testing your demand hypothesis.