Let's talk about inputs. The primary input to the learning process is a narrative, and you learn a lot about how to go and acquire it, discuss it, use it, package it, in courses one and two. Now, I'm a big believer in writing things down and templates, and I think the main reason for that is we forget things. Things go by the wayside. However, just remember there's no perfect packaging where the input is perfect. It's only useful in it's ability to drive good discussions, to create strong narrative collaboration. Now, we're going to start this video off with the little antipattern. You've probably heard the term product lifecycle. This is a standard way to referring to kind of the holistic job of having a software product. And David Bland created this kind of parody which, in fact, describes a really serious problem. He calls it the Product Death Cycle. No one's using the product, we release features, everybody ignores them. So we go and we ask the customers rather what would make this product really great. So we do the yellow Walkman mistake that you learned about in course one, and then we go build that stuff. We spend a lot of time and money and then we release it and they still don't care and we're like god, what are we going to do. Because not only does our product suck, but we don't know why it sucks and we don't know what to do. And apparently we think that we can go out and ask customers what features are missing. Now, you already know probably what the problem is here because you have the right kind of training. And it's really that you can't ask people but you can absolutely learn from observing users but you have to ask the right questions in the right way. And there's certain things you can ask about and learn and there's certain things you must use product proxies and directly observe. Okay so you know how to do this and this I would say is where the process is breaking. If we get the right inputs, I think everything, and we drive good, narrative collaboration, we're going to switch this over to the kind of virtuous cycle that we talked about in the introduction. But how do you know if you're suffering from weak narrative and bad input? So here are a few of the systems that will manifest if that's the case. On the learning side of things, your user-driven learning is weak. You're kind of seeing a lot of the things that David Bland describes in his product death cycle. The collaboration, the discussions you all have are kind of weak and based on shaky inputs. Nobody's really sure. Things seem to contradict each other a lot. And there's a lot of uncertainly and hedging. On the deciding side, estimation is super hard. Now we're going to talk about the whole rubric of estimation, how should you do it, should you really do it at all, or look at things after the fact. But the point will be that when you talk about it how hard is it to build this thing. Nobody really knows that it's super difficult because the reality is nobody really knows what anybody is talking about. When they say let's build a feature that does X, the specifics are weak. The engineers and testers know that when they build something there's tons of changes and reinterpretation, and they feel like they're operating on a super shaky foundation of weak inputs. So decisions are really hard because they're built on quicksand, and nobody really knows anything. Managing becomes a constant problem, because one, the team doesn't feel like their output is mattering. It's not having an impact. So they feel very naturally like they're clocking in, they're doing their job, but they're not building something that really excites them, because the users don't care that much. And two, upper management, other stakeholders, customers are all super terrifying. Because every time you have contact with them, they're pissed because things aren't working well. And they're contradicting what you think because, again, you're operating on this shaky quicksand foundation of weak narrative, or no narrative at all, and very weak inputs. And then when you're building things you find that your on going discussions are weak. Developer has a question they ask somebody, they get three different answers. They're all kind of heggy and uncertain. And there's lots of last minute changes. When you remember how when we talked about the process of scrum for instance there's demos at the end. Those are more like an action movie with lots of surprises than just kind of a review of what was done and a confirmation of the ideas and the narrative that everyone had about what was going to create something valuable. Now, let's transition back to what do we want to have happen instead. We talked about Bill Wake's INVEST acronym. That good stories are independent of each other, they're negotiable, they're valuable. Above all I would say estimable and small, meaning that they're little bite-sized pieces. We have narrative backdrop to all of them. And by having small stories we're able to have narrative for everything that we're building. And finally that they're testable, and we know that how we would put the product in front of the user and observe whether or not they were able to ascertain whether the user is using the product in the way that we though that they would based on how we built it. And so this is a good way to look at your, specifically your inputs that you're going to use for your narrative collaboration, and think about whether they're in good shape or not. This is one of the most durable, and overall useful, frameworks that I've found for doing kind of a quick gut check about where our stories are at, and how well we're doing with them. Small note on this item of testable. One of the super tedious and boring, yet extremely important activities of gathering good inputs as the, say, product lead, product owner is to get really good, realistic sample data for every single parameter field variable that's going to go into a screen or whatever. And the reason why this is important is one, obvious things like field length and data type and is it a multiple, mutually exclusive thing or not. You don't want to have to guess about those things. And you want to have realistic inputs. And you don't want to oblige your engineers to have to synthesize those from scratch because they haven't spent presumably probably as much time on the details as somebody who's out in the field working with customers. So I will freely admit to you that I have skimped on this before, and I paid the price ten times over by generating more work and waste downstream. And I regretted it every single time. So my advice is, create good sample data. Even if it's not great, if you're the product lead, the product owner role, say, the customer lead proxy makes sure you're making it a priority to bring good sample data into your narratives as an item attached to the story, so that's available to your team as they develop. All right, so those are some ideas on good inputs. Now we're going to talk about how to bring them into good collaboration sessions, so that we drive to valuable product.
