Welcome to module two. We're going to start with the job of learning. Now, I mentioned in the introduction that we're going to organize the rest of the material around these four sub jobs within the job of software development. And learning is a pretty important one. Today's most successful products have a highly productive learning machine. And as we've discussed, you can't really learn without observing outcome. So what they have is the ability to carefully observe customers, translate that into actionable ideas for product that they execute as an experiment with observation, and then they loop back. So really, learning is about creating this virtuous cycle where you're releasing things with explicit ideas about why you think they're going to be valuable. You're observing and you're cycling that back through. So where does all the money that fills up this ATM machine come from? And how do we make sure that it stays full? That's really what we are going to cover here in this item on learning. Well, one of the things about the learning process is that it's highly cyclical. So we talked about, earlier, the jobs of proposition design and product design. And how we bring those through the entire development process in a cyclical way. You learned a lot about how to do that in a practical way in courses one and two. Now, that's a big part of the job in this venture design process that we used. Is how do we take things and move them through in a systematic, actionable way, where everybody can understand what's going on and bring them through to product and promotion. So you've got a nice solid grounding in how to do this. So as we move through here, we're going to talk about the sub jobs of learning, the various tasks that you need to do as an Agile team member, as a manager. And those are collaborating on product design. So, how do we take the inputs from the things that we've learned and the specific ideas we have about how we think software might be valuable. And make sure that our whole team understands those in a way where they can build a really good solution, a testable solution, an economical solution. And then how do we look at acceptance and usability testing? So these are the ways that, really, Agile refers to a lot of the kind of testing that you've already learned about. Acceptance testing is a general rubric for all the things that we would do to figure whether we're on the right track with this solution. And usability testing is about user experience and you've learned about that, as well. So how do we do these things? And how do we connect these things to actionable metrics on outcomes so that we're creating not just a really great product but a really great cycle? And I think success in this area looks like one, most of your features you put out are highly utilized by the user. And they're not used just in the first few days by a small group of enthusiasts, they're used by a lot of the user base. This won't happen all the time, but the more that you're hitting on this, the more successful you're being. And you want to make sure that at least you're improving on that ratio over time. Second, your outcomes are well-instrumented and visible. So this means that whatever explicit hypothesis you had about why something was going to be valuable to the user, you're able to observe that out in the field with them through collectible metrics that you can bring back to the team and discuss. And this is really input to perpetuating that virtuous cycle of learning. Everything is an experiment. Without that, you probably won't consistently improve. You may put a couple of good features out there that you hit on that people will like. But will you consistently execute a highly valuable product? It's less, less likely that you'll do that if you're not looking at every single feature with both the kind of humility and the earnestness that come with this experimentation mindset. Your mistakes are short lived. So it's very destructive to have the idea that well, our last release was just, we killed it, it was great, so we're perfect and our process must be infallible. That has never happened to any product team ever, the infallible process. Great releases, sure, all the time. But the infallible process, never. So you want to make sure that if you make mistakes, you're fixing them, and they're short lived. And finally, that you want to make sure that it isn't just a couple of superstars that are doing this on your team, it's everyone. Everyone's participating in the learning process and everyone's work is benefiting from it. Because remember, there's a couple of reasons for this beyond the really obvious ones, and one of them has to do with scaling. As you'll learn when we go down to the management job, Agile is not scalable in the traditional, well, we'll pour more fuel on the fire and it'll ignite. Agile scales with we have one successful team, we're going to peel off a couple coaches from it and create maybe one, possibly two more teams, and it grows more organically. So it is absolutely scalable. But in a way where you need to be able to peel off your best people, and have them coach other teams to help them get going. That is not the only way to scale Agile, but the point is that if you don't have broad participation and success on all of these processes, you'll have a really hard time achieving the kind of consistency that the industry's most productive players have. All right, so in the next few videos, we're going to look at how you become really successful at this job of learning.
