This week, we're going to look at how you define a value hypothesis. How do you know when that's the thing you should be focused on, how you go test these and what you do with the results to make sure that it's moving you and your team towards a better, more valuable outcome for your user. If you have, I'll just say a traditional software development background, then probably this idea of functional testing is the software broken was most familiar to you. This idea of usability testing. You probably have some idea about what that is and as an individual, you probably experienced very good and very bad usability. This demand or value hypothesis a little bit weird and probably nothing was weirder or more ambiguous than the persona and job to be done hypotheses. If you come from a traditional background, this was probably new to you. So congratulations, you've made it through the most difficult, most ambiguous part of hypothesis driven development. I think it's going to get probably a little easier and a little more familiar to you from here. And here's the other good news as we go through this demand or value hypothesis, that will probably become a lot clearer why this persona and why this problem or job to be done. Hypothesis is so critically important as a foundation element in your practice of hypothesis driven development. So we're here, we're looking at this, we are not looking at this yet, but we are building from these persona and problem hypotheses to test our demand hypothesis. Let's take a specific look at what that might look like with this HVAC in her example, we create a screener. Our team went out and interviewed subjects when they were in the building talking amongst themselves, they had the idea that it would be really cool to organize all the HVAC documentation in a central system because that would be neat, and then it'd be easier for the technicians to find it. They found out that the current alternatives for finding documentation, just Googling the vendors' sites and whether it's Westinghouse or Honeywell, or whatever finding their documentation. There was just no problem, there was working fine. And so they eliminated that and they saved themselves potentially a gigantic amount of waste months and months of wasted effort. Now, they have found something that is on there A list which is dealing with getting replacement parts to a job site. They understand the alternatives. They've observed those, they've heard about them in their interviews with these folks. And now, they've paired that with the value proposition. They think they may have something that's better enough than this alternative at doing this job that it's worth investing in and building some software. And the value proposition is if we, they automate parts ordering in online, then these technicians are going to use it, number one and two, it'll improve their outcomes. What do we specifically mean by that, and how can we test this to see if we're really right about this value proposition or not before we go off and build software? Well, that is where the practice of Lean Startup and the use of MVPs is the right tool for the right job. We talked earlier about how you can't ask people plainly whether they want your hypothetical thing, you're thinking of building or not. The yellow Walkman problem. Well, this body of work exists so that you can answer that question. It's just that we tested a different way. Lean Startup is a domain specific extension of Agile where we're looking to test for value using MVPs, which are product proxies. And what it delivers is a reduction in waste, a reduction in the amount of times you go off and build something that nobody wants. Now, that probably doesn't sound very exciting. It's probably more exciting to think like using Lean Startup and you'll always get a win, but that's not true. It's not the way that it works, but it's actually pretty exciting. So think about, we all have limited resources whether we're a startup or a team inside a company, or we're running an IT project. We have timelines, budgets and what Lean Startup will allow us to do is to take five shots at getting a win in the space that it would normally only get one shot at getting a win. So if you assume that you always have certain chance of getting a win, let's just simplify a bit. Then this is like the amount of shots you have at getting a really great win, whether that's a great IT project, great feature, great product. And that, I think personally is pretty exciting. That's what we're going to learn about this week, how we go out, declare these hypotheses and test them.
