Let's talk about how you get great outcomes, working with your development team. Here again, we're going to look at the jobs to be done. What does it mean to code something? How does that relate to the rest of the pipeline and then how do we work with the engineering talent to get everybody in a position where they can succeed and be productive, be happy in their work and then also be doing more than we expected because we're allowing them to operate with autonomy, bring their own creativity and ideas to the product. Well, we have this area of application development in the pipeline and nobody in the business is stranger to this because there's a lot of focus on what we're calling f sub e. How much software we're creating. That term again is here. And essentially that's the denominator of how much does it cost to build a feature. We look at how much does the team cost here, and then we look at how much content we're able to release and this is really what we're trying to look at here, what we're talking about. And so how do we maximize f sub e, because again, it's not everything, but it is important. Well, I think the most important thing is that there's good work from continuous design going into the pipeline. And I really think that actually means two things. One is by going out and doing the homework, for example, using techniques from lean startup to test your propositions before you over invest in building something that nobody wants. By doing good investigation of what for instance really need to be there in the user interface, you're going to be able to lower the quantity of stuff getting jammed into the product pipeline. And that's going to help your engineering team, your development team do fewer things better, which is crucially important. So the best thing you can do for most engineering teams is just stop overloading the pipeline, give them the headroom to do things right. I think if you ask your engineering team, try yourself, see what they say. The second thing though, is to bring better quality inputs into the pipeline. And that doesn't necessarily mean, in fact, it almost certainly doesn't mean more prescriptive. The idea is to bring vivid points of view about what we're trying to do for the user and why. Because when people are new to engineering, digital engineering, software engineering, they will often tend to think of software development in terms of physical metaphors, like building a fence or a house or something, but that is only kind of how software works. It's probably better way to think about it, is that you're building a platform for future development. And that's certainly very much a part of the development practices in Agile that we'll learn about later, like XP, we're sort of designing code that's amenable to change because change itself is inevitable. And so how do we do that? Well, we're real simple level, we're giving certain inputs of development, there's this development process that they execute and then outcomes product. And so there again, what we're trying to do here is lower the quantity of stuff that we need to put into the pipeline to get to a good value for big F and improve the quality of that. How do we do that specifically? How do we get to good solutions on interacting with our development talent? Well, really it comes down to, in our continuous design framing this usability hypothesis. And here what we're going to do is learn how to use Agile user stories and you're maybe familiar with these if you've already been in the business for a little bit, there kind of micronarrative about what we want to happen for the user. The really great way to be extremely specific about what success means with the user without overprescribing the design or the implementation. And what's nice about these is they serve as an anchor for qualitative usability testing, prototyping, that maybe prototyping with a low fidelity tool, like Balsamiq, that might be just the working software. And then even what analytics we want to have on the product so that as we're doing our hypothesis testing we're bringing really good crisp, decisive evidence back into our product priorities. So we can make good, purposeful, intentional decisions. And so that's a lot of what we're going to learn about in the second week, how do we create those user stories? How do they relate to everything else? How do they relate, for example, to those jobs to be done? The thing that you probably will hear about, if you ask a developer, hey, what was your worst experience with product manager is, while they were just all these bugs, all these features and they just kept saying, do more, do more, do more and we really weren't sure that that stuff was doing any good. We couldn't see it doing good for the user, we couldn't see it doing good for the company. It was just wearing us out and making it really hard for us to do good development. You might hear the term technical debt with the code actually got harder and harder to modify and change as we went along. And likewise, if you don't want to have a big customer tell you, hey, go fix all these bugs add all this stuff and then you're just sort of relaying that as the product manager to the engineering team. It's part of your job and we'll work on this in the course, to be able to go to your stakeholders, go to your customers and say, hey, how can we work together and get you what you want? Because I'm not sure this way that you're telling us to do it may or may not be the right answer. But regardless, we're going to want to make sure we get you what you want, how can we do that together? That's part of your job. We'll learn about that. A way of thinking about the work of the development team is that, you start off with these big contours of what the company wants to have happened. Think about it as these big marbles here is maybe the the OKRS coming from kind of some kind of business model design that the company is running, then your job is to contextualize those with the work from continuous design. So for example, jobs to be done paired with user stories that are your usability hypotheses. And then your development team is going to be taking all that and making it into working product. It takes a lot of work, coding takes a long time. Every year I teach MBA students how to code and they do great, they get all the way to working applications. Their first observation is almost always, my gosh, this is so much harder than I thought it was. And what's funny about that is, I realized that same thing back when even when development tools weren't nearly as good as they are now. So getting something to actually work in software is a lot harder than probably looks like if you haven't been in that domain and it's important to make sure that they have discretion, they have the best possible advantage point on how to do that. So all this stuff blends together well and you're able to get to a good value of f sub e and you're able to continue to improve that value. And that's good.
