Designing User Stories: Problem Scenarios

In the last video, we looked at personas. Here, we’re going to look at problem scenarios. These are the fundamental needs, jobs to be done, desires that our user has that we’re going to deliver on with our software. You’ll learn how to take these and apply them in a practical way to thinking about if what you’re doing is valuable or not. These are a disposition of the jobs that the customer is going to do, the needs or desires if your product is more about personal things and habits and gratification. And, this is a way of making sure that we don’t build something for a habit or a job or desire that doesn’t exist.

Because we know, at that point, if we do that, we’re going to pretty much be dead in the water no matter how well we execute the software. We’re creating something for a job that doesn’t need to be done, or a habit that fundamentally doesn’t exist. Now, you may say, well, innovating new products like Facebook, well, they, people didn’t have that habit of going to social media and that’s true. Part of the thing we’re going to learn about with problem scenarios here is defining them at the right level of abstraction.

So for example, the problem scenario which is of course more of a need, or a habit, or a desire is the desire to a couple of different things probably, the desire to stay in touch with friends and family. The desire to take a break and unwind during your work day or your school day. So, we will be defining these things at a fundamental level. And it turns out that, this is a really great way to do things because problems, desires are very durable and yet solutions change all the time. As we do this, we look at alternatives.

If this problem scenario really exists, the customer, the user is doing something about it today and learning about what they’re doing is really important. So, at one of my last companies, we build enterprise software. And often, the software would be replacing some spreadsheet that they were using to get that job done. And, we need to make sure that, what we were doing was better enough than that spreadsheet that we were going to make the user better off and so, the alternative helped us kind of set a baseline for that. And additionally, it taught us a lot about what language the customer uses to talk about this job.

How they do it, what data they really look at and circulate a lot and so it’s not like we took this spreadsheet and made our software look like it. But it taught us a lot about the problem scenario so that we knew what we were doing for the user, what they cared about in their day-to-day work. Let’s take a more consumer example. Let’s say you’re making an app for parents to distribute allowances to their kids. Well, in that case, you want to go where the customer is, as much as possible, in your particular area.

So if we were doing this, we would want to spend a lot of time talking to parents in their kitchen and looking at the notes that they’ve put on the fridge about giving the kids their allowances, doing their chores, whatever is relevant and that’s how we learn about this alternatives. And then and only then, we will look at our value prepositions, what are we doing that does a better job of solving this problem? And, what we’re really looking at is, are we going to do something that’s better enough than the alternatives at solving this problem scenario where we’re going to create a win, where we’re going to create something valuable for the customer?

Central to agile is this idea of front loading value and staying focused on something that’s valuable to the user. We’ll close with this idea of a product hypothesis. So we’ve talked about a culture of experimentation and how testing is central to agile. So, if we learn about these things, we can stitch them together in a nice testable formulation which is that, okay, our idea for this product or for this feature or this enterprise software deployment is that there’s certain persona exists, user costumer. And they have these certain problems, these certain jobs, these certain habits whatever they are. Right now, they’re doing these certain things to solve them.

And, we have a proposition that better enough to cause them to want to use our site, use our enterprise software, read our site, use our site, whatever relationship we’re trying to have with the customer. And I think, if you spend a little bit of time and then make a habit out of keeping this material fresh, you’ll find that you’re doing a lot better job of driving the value for the user. Have you ever gone on a website and been like, good Lord, I’m just trying to read this news story, or schedule a social media post. What is all this crap that’s being put in front of me that I don’t care about?

It’s almost kind of like somebody that can’t stop talking about themselves. Well, that’s not the software you want to build. You want to build software that’s focused on user and what they want. And, if you do that and you’re mindful of those things, you will drive to valuable outcomes with agile. So in the downstream material here, we’re going to look at how to actually do this things in practice.