Needfinding with Problem Scenarios

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, I just want to make the software, get it done, I gotta write a 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, David Bland, calls the product death cycle. Where we go 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 a dead useless product a lot of the time when we go to this failed anti-pole.

Over here, 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 and 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, the 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. Our 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 with 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 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 at kind of the right level? What is your sort of 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, well, why is this problem scenario so important, that’s a good way to get yourself to that next parent. Well, then, maybe that’s probably something like hiring technical talent, and that’s way too big a problem for the company or the product to go out and deliver on. I mean, it tells us that we’re in an overall 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 with 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 does 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 because you sort of create your sort of world of problem scenarios. Then, I recommend, as you go forward with these, texturing them out into child problem scenarios where you kind of ask, all right, if this problem scenario’s the one we’re going to work on, how do we unbundle that and actually deliver value against it.

Well, we then break that down into smaller jobs, tasks, 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 user 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 is probably something like completing HVAC repairs. And the parent of that, well, why do we go out and do that as a company. Well, they’re executing these HVAC service contracts that they have with companies. And this is probably too broad, this is probably about right for our kind of anchor problem scenario that our product or their project, in their case, is organized around. And then if we unbundle that, we get individual sort of child problem scenarios, how are we going to do this?

Well, the technician has this job of needing a replacement part on the job, the technician wants a checklist for each job that they’re scheduled for so they’re prepared. And 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 will just happen in the hallway. You’ll get these comments, you probably already have if you’re in the business, of like, 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 the project or from wherever says, hey, wouldn’t it be cool if the HVAC technicians had all the documentation needed in an app? And the participant in this course then will help them think about what problem are we seeing 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 are we going to solve? How might we frame the problem? How do we know that this exists? And they’ll maybe know about that, maybe they won’t.

And then, probably we would close that with the idea of, well, if 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 the user.