In this video, I'm going to show you more about how to explain and introduce the importance of problem scenarios. And how to formulate them so they're actionable, useful for you and your team. Now, we talked about problem scenarios. We talked about how we don't make sure at this point that our problem that we're solving at the feature, the product, the company level really exists. Then even if we do, all the rest of this stuff perfectly, we're going to end up with software that nobody cares about. And that's not what we want. We also at the feature level, a lot of your work, week to week, month to month, is just grinding through individual ideas about how to create value for the user at the feature level. That kind of relates to this red button problem we talked about. Where we just say, you know, I just want to make the software, get it done, I got to write the user story, fine. It's this red button story. Well, don't do that. Let's not do that. Let's always make sure that we can tie our user stories back to a problem scenario that we've been able to validate really exists for the user, whether that's very kind of big picture or very tactical. This will help you avoid what I call the twin anti-poles of failed user engagement. So on the one hand, I see people say, well we're customer driven. because we go to the customer, we ask what they want and we go do it. And then you end up in these cases with what my friend and collaborator who you'll see later on in the specialization. David calls the product. That's like where we go to ask the users what they want, we go build it, we give it to them, they don't use it, and then we go back and ask them again. And we just end up with the dead useless product a lot of the time when we go to this field anti-pole. Over here, there's the, we think we're Steve Jobs, which isn't really the way he did things. But we just think we know what's best for the user when we just go out and we do it. It doesn't matter what we see or what we hear. The reality is those are both going to fail. And the alternative is being diligent, being observant about our users and what they really care about creating problem scenario, alternative pairs that are really well-observed and meaningful. So how do we actually formulate these things? What do they look like? Well we talked about this example company, Enable Quiz, that's making a solution for HR managers to screen candidates for engineering jobs. So how well do you understand programming in Ruby or whatever? And so for them, they kind of anchor problem scenario at the product level is probably something like screening technical talent. Now notice, there's no normative terms here. And I think that you'll find that that works a lot better. So this problem scenario is a fundamental habit. Job desire are formulation of the problem scenario should be able to apply equally well to their current alternatives that they're using now as well as whatever we're going to do for them, our proposition. So for example, this is the job right now. Helen will check resumes, call references just kind of take their word for it. Frank, the hiring manager, the engineering manager. He or she, obviously, it wouldn't be a she if it's Frank. But it could be Francine, they will ask a few probing questions, but they don't want to spend the whole interview grilling this person. So these are the alternatives. You can see that this problem scenario applies perfectly well to those. As you're formulating the problem scenarios, I recommend that you sort of think about what is the parent problem scenario. And are you kind of at the right level? What is your correct anchor problem scenario? If you go one level up in abstraction, maybe you'll find that that's actually the right one. Here, I think the Enable Quiz people are about right, because if we ask why is this problem scenario important? That's a good way to get yourself so that that next parent. Well then maybe that, that's probably something like hiring technical talent. And that's way to bigger problem for the company or the products to go out and deliver on. I mean, it tells us that we're in over-all area that's important, hiring technical talent is a big deal for software companies but we're going to bite off a little bit of a smaller piece of that. Our anchor problem scenario, Enable Quiz is this. So think about what is the parent problem scenario to whatever problem scenario you're considering and ask yourself, is that actually the right anchor problem scenario? And also ask yourself, what is that tell me about the area that I'm in? Is it important? What else do we know about it? Those are good questions to ask as you sort of create your sort of world of problem scenario. Then, I recommend as you go forward with these, texturing them out into child problem scenario where you kind of ask, all right. Well, if this problem scenario is the one that we're going to work on? How do we unbundle that and actually deliver value against it? Well, we break that down into smaller jobs, tasks and in the case of Enable Quiz, things like what you see here. And those are things that are kind of antecedents to our user stories, the things that lead us to specific interactions that the users wants to have with those small testable rewards. Let's look at another example for comparison with HVAC in a Hurry. This is a company that is developing an internal product to assist the dispatch people and the repair technicians that repair heating and air conditioning systems to better arrive at the right job at the right time with the right preparation and then execute that job. So the kind of anchor problem scenario for the team that we're looking at in the specialization is probably something like completing HVAC repairs. And the parent of that though, why do we go and do that as a company? Well they're executing these HVAC service contracts that they have with companies. This is probably too broad, this is probably about right for our anchor problem scenario that our product or their project in their case is organized around. And if we unbundle that, we get individual sort of child problem scenarios how we're going to do this. Well, the technician has this job of needing a replacement part in the job. The technician wants a checklist for each job that they're scheduled for so they're prepared. Then, we can move forward to how might we implement this with software? Now, you won't always use problem scenarios when you're sitting down and making time for yourself to do this. Sometimes, it'll just happen in the hallway. You'll get these comments. You probably already have if you're in the business. Hey, wouldn't it be great if, or why don't we just go do this, wouldn't it be cool if we did x? So let's take an example from HVAC in a hurry. Some person on a project or from wherever says, wouldn't it be cool if the HVAC technicians had all of the documentation needed in an app? And the participant in this course then will help them think about what problem we're saying exist then. And how do we know about that? So they might say something like this. We don't want to lecture these people. We just want to help them think through what they're really interested in. So what problem we're going to solve? How might we frame the problem? How do we know that this exist? And they'll maybe know about that, maybe they won't. And then probably we would close that with the idea, like, well, we're thinking of making the time and spending the money to develop software. Probably we should spend a little bit of time to go out, watch the technicians in this case, our persona see if this problem really exists for them. Talk to them about what they're doing. So you've learned why problem scenarios are important in general. How they'll help with your process. And you've seen how to frame and sort of texture out those problem scenarios. So they're actionable and they create the right context for development that's focused on what's valuable to user.
