In the last video we looked at personas.

Here, we're going to looked 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.

We talked about personas, we're going to look at a little more clinical

way to break down the specifics of how they operate in our particular

area using this framework of think, see, feel, do.

What does our persona think, and see, and feel, and

do in our particular area of interest.

Because, once we've humanized the persona,

we need to make them practical in our particular area.

Because they're ultimately, very much an operational asset for making

decisions that will help you drive to and test valuable outcomes for your user.

Now, let me give you a specific example of what I mean by that.

We have a woman, she works downtown,

she's really one persona to the company whose accounting software she uses and

another to the company whose hiking boots she buys.

The one company cares a lot more about what she does in her day job,

how she relates to her profession of being an accountant let's say.

And then the company with the hiking boots,

they care a lot more about what she does in her spare time and why and how.

Now, they both want to humanize her and understand what makes her tick, but

they do so in very different contexts.

That's how think, see, feel, do helps us.

The other thing that we do, is we texture out problem scenarios, and

you saw this in the venture design framework.

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 our 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 innovative new products like Facebook,

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 built 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're 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're really look at and circulate a lot.

And so it's not like we took the spreadsheet and then made our software

look like it but it taught us a lot about the problem scenarios 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 you were doing this, we would want to spend a lot of time talking

to parents in their kitchen and looking at the notes they put on the fridge

about giving their kids their allowances, doing their chores, whatever is relevant.

And that's how we learn about these alternatives.

And then, and only then, we would look at our value propositions.

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 project or this feature or

this enterprise software deployment is that this certain persona exists,

user, customer, 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's 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 the 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 these things in practice.

Designing User Stories: Problem Scenarios

Agile Development in Practice (Project-centered Course)

Meet the Instructors