Bringing Business Impact and User Needs together with Jobs to be Done (JTBD)

Welcome everybody to Web Directions 2022.

My name is Itamar Medeiros.

I'm Director of Design Strategy SAP.

I've been working on the UX industry for the last 25 years, but for the last 10 years or, I moved into design management and strategy.

What does that mean?

Is that I'm helping teams translate product vision and strategy into cohesive experience narratives, right?

So I'm constantly looking for a frameworks and tools that allows, uh, teams to, um, align on what are the problems they're trying to solve and battle in the same direction.

And one framework that has been very helpful and is getting a lot of traction with the teams that I'm working with is this 'jobs to be done'.

So today I'm gonna talk about why this framework is getting so much traction, but before, um, talking about why, like why jobs to be done, help us bring product, um, business impact and, and, and user needs together, I think we're gonna have to do a little bit of context around like what is a job to be done, right?

Um, , I'll, I'll try to make this quick.

If you heard this one before, please hang, hang with me there's.

So a, a job to be done is a goal an or an objective independent of the solution.

Right?

So the aim of the job performer is not to interact with your product or your service, but to, as the name suggests to get something done.

And so at best, the customer hires your product in the hopes that that your product or service is gonna help them get whatever they're trying to do done.

At worst, your product is on the way.

Right?

So then in this outcome driven mindset, the thinking shifts from like, what is the best product I can create to answering the question, what is the job performer trying to achieve?

Right?

That's kind of the starting point.

The other thing I think is a pretty good, um, disclaimer in terms of, of setting the direction of why jobs to be done is such a useful framework when it comes to discussing with product teams is, is this realization that customer outcomes are relatively stable over time.

What changes is the, the value, value migrates over time and, and what it means is the, the technologies themselves let's say, while technology might evolves, what people are trying to get done doesn't really change drastically.

Right?

What technology does it, it allows the, these customer outcomes to be satisfied or not.

Like, so that means we can use jobs to be done, and really help them frame product vision, right?

So if you've, if you've been working with product strategy, you've probably heard a complaint from, from, from the product teams like that: 'but how can we know what customers will want in 10 years from now?' It's like, well, technically we can know because if we know what they're trying to get done today, that is not gonna change drastically uh, over time.

What it does change is how well these jobs are satisfied by the technology, right?

So that means that we can now frame product vision with a very high level of confidence that we can push our product vision far out, knowing that we unders, like if we understand what the customers are trying to do, then our product vision is gonna be in line with that, right?

So, And the third thing that we're gonna talk real quickly, but we're gonna go into details towards the end of this presentation, is why I even wanted to talk to you, right?

Because in my experience, jobs to be done is been this great exchange currency between leadership-designers, product managers, developers to describe value.

And so, I've been like the, some of the things we've been using jobs to be done, um, in our product teams is to discuss problems instead of solutions.

Right?

Technology industry, we are very quick to jump into the solutions.

That usually is a recipe for us to solve the wrong problems, right?

So with jobs to be done, we can focus on understanding what are the customer's problems first.

Then we can think about the solutions later.

Also, jobs to be done, I'll, really help us provide clarity and the scope on the discovery activities.

Right?

So for example, if you're gonna dis, like if you're gonna conduct user research, who's a job performer?

What is a job that they're trying to get done?

And then try to frame like the research questions and the observations around those things, right?

So, and finally, probably the one that I think is closer to my work on a day-to-day, is jobs to be done is a great way to synthesize the research or the discovery findings, right?

Because you've probably been into this place that you interviewed a few customers, you observed them, you, you heard their problems, but then how do you bring it back in a way that the product team can consume?

Right?

And you, I mean, we're gonna talk more about it later, but you probably heard all these things like, uh, use cases, user stories.

They're very good to describe the problem in the context of a solution, right?

The product should do this and that, but the, they're not very good in this, explaining the why customers who need this, like what is the problem that they're trying to solve, right?

So jobs to be done is a great way to do that.

So let's go into the details like one by one, right?

So jobs to be done, as the name suggests, is a goal or an activity or an objective independent of the solution.

And if you are familiar with the method, you've probably been, you've seen this explanation before that people don't want the quarter inch drill, what they want is a quarter inch hole.

And the way that I've been framing this, when I explain the methodology to, to the product teams is, and this is something that is kind of a, is a kind of a, the first encounter is kind of jarring, but it is a, is a very strong statement that, that I usually make is this: technically people don't even care about the quarter inch hole.

What they want is to hang a picture on the wall.

Right.

So this is kind of the first big mindset shift that you have to make when you're working with your teams, right?

Your, your service or your product is a means to an end, right?

So, so that means people don't care about the drill, what they care is about hanging a picture on the wall.

So jobs to be done in that perspective, is very contextual, right?

So once you understand that what people want is to hang a picture on the wall, what else other than a drill could do that same job?

And here's a very strong statement I'm gonna make.

The tape, while my, someone might argue that is, has less features, quote unquote than a, than a drill is actually from the customer perspective, is actually a better solution from the perspective that it lets them get some jobs that they really care about better than the drill, right?

So for example, yes, the drill might, might be more, uh, robust.

It make holes that I can hang, things that are heavy.

But, um, the, the tape doesn't, I, I don't have to worry about making any noise.

The, the tape doesn't, I don't have to worry about cleaning up afterwards.

I don't have to plug holes in the wall before moving out, right?

So from that perspective, the tape is better because it helps me get these other jobs that the drill doesn't, right?

So this is kind of the big mind shift mindset shift that I try to help teams understand.

Is not, is not that the tape is better, it's just that in this one context, when there are these jobs at hand, the tape does a better job than the drill.

The other thing that I wanted to talk about is that customer outcomes are stable over time, right?

Um, and I, I think the best example, let me give an an example, right?

If you think of an, an example is like music, right?

If I were to ask you, like, why do you listen to music?

You might say things like, 'I want to get inspired' , 'I want to relax', 'I want to feel energized when I do exercises'.

Right?

Depending on what is that that you're trying to get done by listening to music, so for example, when I want to relax, maybe relax means sitting down in the couch in your living room.

Then maybe a particular listening device is more suitable for that experience or not, right?

So on the other hand, if I want to feel energized when I'm making exercise again, exercise, there's a particular context, so some jobs might be more critical than others, right?

And it goes back to a very strong principle jobs to be done: that value migrates over time.

So the, the users will not necessarily switch from one technology to the other just because of the technology itself.

It's like they will switch from one, like one technology is gonna replace the previous when it allow, once it allows customers to do things cheaper, faster, more conveniently.

Right.

So just give an example, like the when, when CDs did not replace vinyl, although vinyl's coming back again, but let's say CDs didn't replace vinyl because the audio quality of CDs were objectively better than vinyl.

If I, I guess there are some audiophiles in the, in the audience there, but one could argue that actually vinyl has a, a higher, uh, audio fidelity.

But CDs allowed for us these other jobs like portability and so on to come along, right.

Um, so again, the, the, the technology doesn't replace another until it allows customers to do things cheaper, faster, more conveniently.

And I'm gonna put, um, a caveat on faster here because not necessarily, not everything that is faster or cheaper, um, makes for a better product in a, in a, in the eyes of the customer.

It's all a matter of understanding what their context, right?

Sometimes slower is better, sometimes more expensive is better.

I say, what is it the customers are trying to get done?

I say going, going back to the example of the audiophile.

Right?

Um, they might not like the, the, the CDs might be more portable, but the quality audio fidelity is lower.

So that means that, for example, if people really want to sit in front of a couch in front of the music center, maybe CDs are not, uh, are, don't help them get their job done, so would not be streaming.

It's.

So again, uh, jobs to be done is very in line with a lot of other methodologies that tells the customers, like what customers are satisfied with today might not necessarily be what they're satisfied with tomorrow, right?

Let's say for example, the kind of method kind of stipulates that if you help customers get a job done today and they're happy with it, that satisfaction just migrate somewhere else, right?

So for example, think of your hotel industry.

Like, I don't know, 50 years ago, um, a hotel could brag about, let's say yeah, in, in, in room shower, right?

Let's say now, before, like I know 50 years ago, you have to go down to like a common shower in the hall.

Right.

Now, every hotel, any hotel that is basically of, let's say a decent reputation, you have like a, a shower in your room, but then, I don't know, at some point it's like, does it have uh, hot water?

Right.

I guess I'm saying nowadays nobody, no, no hotel can brag about, let's say, yes, I have, uh, warm water in the, in the, in the hot water in the shower.

Right?

That, that expectation that's, that that value migrates to something else.

Let's say now you kind of expect to, let's say, to have a shower in your room to have hot water in the shower, to have, um, wifi, to have fast wifi, to have free wifi, right?

So that's, um, that's one thing.

The other thing that jobs to be done allows is for really, uh, for, for us to be able to quantify these, these, um, these jobs, let's say how satisfied people are and, and how important these jobs are for them, which is also something that I find that that is very useful for conversations with product teams because like I've, I've seen these kind of prioritization methods where you have like, for example, stack ranked use cases, right?

Those are very good to kind of keep the, to, to kind of get the the loudest voice in the room, right?

But the jobs to be done because there's this nuance of how satisfied people are with a particular job gets these new ones that usually gets lost in the tradition of prioritization methods, right?

So once you ask these two questions, how important is any particular job is for, for you and how satisfied you are, you get a a lot more nuance on on, on the jobs, and we've been using surveys like this to with our customers very successfully.

So with the, with this kind of, uh, more quantitative, um, data on jobs, then we can do all kinds of comparisons and you can start identifying markets where, um, some jobs are underserved in a sense.

Let's say customers are buying particular sets of jobs, incredibly important, and they're extremely dissatisfied.

And one could argue that you, from an innovation perspective should focus on those in terms of disrupting the industry versus kind of focusing on these jobs that customers, yeah, they might find relatively important, but they're already satisfied with, right.

Say, which is the overserved.

So with this kind of, let's say, being able to quantify this allows us to have a lot more objective discussions, especially when you're thinking about prioritizing, uh, backlog and, and stuff like this.

Right?

So going back to the idea of using jobs to be done as a common currency to describe value, which is, which is a good segue for, for, for the last part of our presentation, which is like jobs to be done is a really great exchange currency to describe value because it has all the, all the, all the semantics and all the terminology to kind of really qualify what a user needs, right?

So for example, you can, you can think about what are the main job of, of an application, which is kind of like, what is that, like, what is the functionality that they are trying, let's say they expect from a software to have in order to help them get something done, but also help us describe these other aspects of the experience, which in my, in my experience is being missing in this, in the enterprise software, right?

So things like emotional jobs and social jobs.

It's like, how do, how do people want to feel?

How do people want to be perceived when they're using the product?

Which is, let's say if you, if you're, if, if you've been using storytelling as a way to kind of cast vision and, and, and sell your value proposition, then jobs will be done is yet another, like, there's another great, uh, great use of the tool, right?

Because once you understand what, like what is the social and emotional jobs that people are trying to get done, then you can frame the stories around your product, uh, around, around those right?

But you might be asking, it's like, wait, but enterprise software and, and function and, and functionality.

Like what?

Like how, like what is the emotional job that people are trying to get done when they're using Excel or when they open Photoshop?

Well, yeah, that could be an argument that, let's say there is, is really hard to create like a, like a exciting narrative around, let's say, using a productivity oriented software, but here's, here's where I think that that's where the next generation of, of productivity oriented software is gonna go, right?

Let's say what, take us, what took us here, right?

Let's say, so looking at my own, like my own employer, right, that's SAP, oh, like our value proposition for the last 50 years has been we are helping our customers save time or organize their, their backend, uh, reduce the cost of their operation and so on, which is fine.

And, and we are, we are doing a great job at that.

But what's gonna happen is that's not gonna be enough for the next generation of, or the evolution of, of software.

Right.

Um, we are observing a lot of trends in the, in the industry, especially in the, in the kind of software that, that, that I work with, which is like HR software that employees do not just want to come into to work and just, just, let's say, just go through that task as, as robots, right?

They really want to feel like a sense of belonging, they, they want to feel that their work matters.

So that means that the next generation of products, they really want to focus on the emotional and social impact, right?

So if you think about any company that's being able to kind of differentiate themselves for the industry usually is in this kind of higher level uh, aspects of their brand, right?

So for example, I guess I like the obvious name that comes to mind is like Apple, right?

A lot of the products help customers get really creative, but there's all these other, other aspects of their brands.

They are not necessarily the most functional, but are, they're really trying to connect with the users at the social and emotional level, right?

So, for example, luxury brands think about BMW or, or Porsche.

There.

Some of one could argue that some of their projects are not necessarily the most, um, useful.

Um, but they're definitely fulfilling these kind of self-actualization and, and, and, and let's say in, um, status, uh, jobs, right?

Let's say, which is like, for example, the differentiation between Philippe and Apple Watch, right?

I say, so there's a, there's a, there's a social job there in the luxury brands that the other, that a more functional product cannot really get them done, right?

So, so again, in terms of helping teams come together, jobs to be done is this very good translation layer that helps us focus on, let's say, coming up with a great market fit in terms of, let's say, what are the jobs if we were to focus on, in terms of, let's say, what are the functional, social, emotional jobs that people are trying to get done that will help our business create the ... create the impact that we are that we need, right?

Say revenue growth and satisfaction.

So if you can remember anything from this presentation, just remember this one picture there, right?

You bring business impact and user needs together by identifying like, what are the jobs to be done that we need to enable our customers to perform?

That generates the business impact that we are trying to create.

So yeah, that's very abstract and, and, and general.

But here's how it means in practical terms, right?

So we've been combining jobs to be done with other kind of alignment frameworks, like user story map to, to create, um, to facilitate the decisions, especially when it comes to alignment, right?

Between, on between product managers, designers, developers, on the question of why, like, why are we working on this?

Right?

If you are trying to frame like on let's say, why do customers need this feature, that's where jobs to be done comes in, right?

So if someone wants to, wants to know like, what is a desired outcome of any given user story, it is just a matter of going up or down the hierarchy there, let's say, to going up on the, on the user, if you, if you're familiar with the concept of user story mapping, where the horizontal axis is the, is the narrative and the vertical axis is the level of granularity of a requirement, well then, then with this kind of approach, it is just a matter of going up the hierarchy and you understand the teams can align and agree on why a particular feature needs to be there on the, on the roadmap.

Right.

So just to give, like zooming in here with this kind of the trifecta, functional, social, emotional job, we can have these much more thoughtful conversations about why users want to do this or that, right?

Or when teams are discussing the execution, let's say, so for example, when we are looking at a particular user story, and, and we are trying to come up with ideas how to address that.

Or if when the, the scoping discussions comes, then we're like, oh, we cannot do all this story here, then with, with this jobs to be done, we have a much more objective way of describing like 'what is the criteria of "done" here?' So in this example, we have like dashboard application, right?

Which is usually people tend to think they're not the most exciting kind of application.

It's like, what is the fun and looking at charts and, and graphs and stuff.

Well, we've been using these kind of jobs to be done to generate this alignment, right?

Say, well, people don't care about the charts themselves.

What they care is to be able to make a decision right when they're looking at a chart.

So let me, let me just look at an example here.

Like when the customers want to make a decision, they want insights on the health of their organization at their fingertips so that they don't have to leave the place that they're working.

Place here means like whatever in the application to go find information somewhere else, right?

So that's very, so from that perspective, that means that we could actually address that job even without a chart.

Right?

Say if we are able to extract insights and keep them, send them by, by, by notification and so on, so technically I don't even need the chart anymore.

It's, but if you think about, it's like why do they need insights about the health of the organization?

Well, because they, they don't want the stress of having to find information and the pressure.

Right.

So, or they want to be perceived as someone who really takes immediate care of problems.

Right.

So, so I guess by now you've, you've realized, I mean, I hope I made the case that jobs to be done is a great tool to align on why, like, what are the customer problems and, and why, then you might be asking us like, but what, where did these jobs come from?

Well, in order to capture them, the best place, the best place to start is to understand the context of like, of when and where the job happens, right?

So what is, what are the customers experiencing currently as pains?

And from their perspective, what did they perceive as gains?

Right?

And the easiest in a sense, I'll say we know how to do it, but the hardest because now we need to put the heart and minds into it, is good old user research.

Right?

So if you think about customer journeys, like observing customers, talking to them about their, their current experience, you should be able to derive a lot of insights around, like, what is the work, like, what are the breakdown of tasks that they're doing?

How the, like how painful or how the life of any particular task is.

And that should be the, the raw material of you, uh, understanding these jobs, right?

So then you can take this even one level further and, and really use frameworks like value proposition, uh, design to really convert specific gains or pains into jobs.

What I, what I noticed that value proposition design is being very useful is to solve this really old age problem in product development, which is like, how do you fit a, a round peg, in this case, let's say, what customers want in a square hole, which is like our, our strategy or roadmap, our existing solution, right?

And I've noticed like, and, and this is something I've noticed in my practice a lot, is like the moment that you're trying to discuss two things at the same time is like what the customers want and how to solve that.

Then I find it best that the teams kind of separate the concerns and, and, and value proposition design in this case here is a very helpful tool because in the right side of the picture here, when you're trying to build a customer profile, you are really trying to map the, the gains that, let's say, what do, what do customers perceive as gains based on, let's say, what, what will make their lives easier.

And also have a very good understanding their pains.

Let's say what's currently annoying, what do they dread doing, right?

Once you create a profile of that side of the picture, then you can, then you create these jobs.

Then on the second part of the exercise, you do the, the market fit, right?

Let's say what, what are the like products or features or services that we could create that would generate these gains or that would relieve these pains?

It can be hard.

I mean, but here's the caveat that I would do when it comes to talking about value proposition design.

It's like these jobs cannot come out of thin air, right?

It's very easy to get jobs to be done, and let's say, especially if you get like a job story kind of template and it just like user stories, it's very easy to kind of have a format that says 'as a user, I want this so that, blah, blah, blah'.

it is very dangerous to kind of write these things that is not really based on real customer needs and, and, and customer pain points, right?

So this is just another way to encourage you to, if you wanna use jobs or jobs to be done, or any other methodology, step number one starts with just doing good product discovery.

Go get out of the building and talk to customers.

Right.

With that said, I want to thank you for your time.

Um, I, I'm, I'm, it was a privilege to talk to all of you about jobs to be done as a methodology that I've been using very successfully here at SAP.

If you wanna learn more about the method, I wrote a in-depth article that kind of captures all the literature all in one place.

And if you want, if you have questions, you can always reach out to me.

Um, you have my email there, but I'm also very active in LinkedIn and in mastadon.

So you can, um, just look me up.

I'll be more than happy to connect.

So I'll talk to you later.