Now that we've had some practice articulating our hypotheses or assumptions, let's have a look at how we can pair them with various test vehicles or MVPs. Now, a lot of the actual practice in application of lean startup and testing a demand or value hypothesis has to do with this. Ultimately, the idea here is to be scrappy, creative, pragmatic and so it's good to consider a lot of different ways that you might frame and test your value hypothesis. Let's return to our body trend. We've got this value hypothesis over here about automating parts ordering, and we're going to look at how a few different MVP vehicles might perform just against this kind of basic value hypothesis that we're looking at here. So I'm going to introduce a few MVP or minimum viable product archetypes. This isn't physics. You may see different terms used elsewhere, and that's fine. If you're reading about how to take a question paired with experiment vehicles to get to a good answer, then that's some useful work, and that's why we're using applying here, this body of work around Lean Startup in the course. There is a lot of secondary material community practice around it that's really helpful. That's it. These are three popular archetypes, Concierge, Wizard of Oz, and Smoke Tests. They do really different things for you. So it's important to look at the difference and often to consider how they might service a given hypothesis so you can think about what you might want to do. The idea with the concierge MVP is to hand create the user experience. So with HVAC in a Hurry, what we might do is just have somebody shadow HVAC technician, and whenever they need part sorted, order them. That may be some kind of stupid and silly and obviously, it's no way to scale an actual service. But that's not the point of these MVPs. They're not there to be efficient, they're not there to put into production. They're there as a learning vehicle. What we would learn from that is, a lot of depth about what situation is this trend encounter where he needs this? What is it like to go get that information? What does he do with the results? So for early on in this process, and we wanted to just hand create this experience, that might be worth investing in. I see this all the time in enterprise software. In general, teams will design a piece of software for a process that they either don't really understand or haven't thought through how they want to change it and whether it even really make sense. So rather than for instance using a spreadsheet or a Google forum or something, or a sequence of emails to help users use an alternative process and see how it works out from, they just blindly go build software and assume that it's going to work for the users which is almost always a bad idea. Concierge vehicle is a great early stage MVP if you have a new concept. It's depth, in other words, the amount of observation and learning you're going to get is really high. You're going to be there, hand creating the experience. You get a lot of observations which can be really useful. The definition, in other words, how clearly is it going to give you a positive or a negative conclusive result on your value hypothesis, is pretty low. Because you're really just kind of observing how this might happen. That can be valuable, but it's probably going to get you to a final answer. The Wizard of Oz is where you show or fake a customer interaction. An example of this, for HVAC in a Hurry, would be that we have a service that we set up for just a few technicians where they can text a number, with either a make and model of part that they need to replace or a part number or whatever, and we go look up the information and text it back to them and we see how they interact with it. The Wizard of Oz metaphor, is that it looks like a real experience to them, but on the backend, were faking it. This is really popular in robotics or voice interfaces where a given feature interaction is really hard to build and you want to see how a customer interacts with it. This can be very viable, but it's kind of a medium on depth, because generally you're just observing little slice of the process, and it's kind of also medium on definition of how valuable is that. You can see if they engage with it, how much they engaged with it, but really here you are kind of testing motivation and usability at the same time, which is okay, but it's not as conclusive about giving you positive or negative on your value hypothesis. The smoke test, is basically seeing if you can sell some. This is the one that is really good at giving you a definitive result about whether you can bring customers kind of into your conversion funnel to sell them or get them using your product. So the depth of observation is low, but the definition of the result that you're going to get is very high. So for example, if you run a Google Adverts, this is a classic MVP. So we assume we're thinking of opening a vegan dog wash in San Francisco. So when people search for dog wash, we post an ad about this vegan dog wash we're going to offer in San Francisco. Well, people click through, that shows us at least that there's early stage interests. We can get their attention, we can engage them in the proposition, and for that slice of our funnel, that's pretty good evidence. But, what if we get a zero conversion rate. We really don't know a lot about who or why interacted with our proposition or not. That's why I say this one has a relatively low depth of observation. Let's look at how these might play out for the value hypothesis we've been looking at and how we might unpack the assumptions and hypotheses even further to make sure we know exactly what we're trying to look for as we test. If we did the smoke test at HVAC in a Hurry, we might do something like just email the technicians about a webinar that we're going to hold on a new parts ordering tool and see if they sign up. Now, a smoke test isn't as compelling or irrelevant when you have a internal software captive audience, but that would be a smoke testing, the way that we might frame up our sort of child hypothesis to our main value hypothesis is something like, well, if we emailed the technicians about signing up to use the tool, at least 20 percent would sign up for this webinar. If we get that, it's a positive smoke test or add or over 20 percent is a positive, below that is a negative. It means maybe we shouldn't build this thing. Now, good idea, bad idea, I don't know, but that would be a smoke test take on testing this value hypothesis. Wizard of Oz, would be this SMS item. If we offer an SMS-based services job for them, they use it and it would improve their completion time on jobs, we can test for that. Concierge would be, if we shadowed the technicians and took other parts ordering process for them, it wouldn't prove their completion rate, and it would maybe improve customer satisfaction. Now that's a relatively vague kind of answer, we're going to supply against that. But that's just the nature of that type of MVP vehicle. One thing that you might want to consider doing is, as you declare a value hypothesis, just go to the hoop and think about, well, what would be a concierge, a Wizard of Oz, and a smoke test take on testing this thing? It's a really good way to think about what possibilities are open to and which ones you might want to pursue.
