DU022 – Jobs To Be Done – Liz Kessick Interview

What is a job to be done? How is it different to a user need? What size hole do you want?

Chris speaks to Liz Kessick, Senior Researcher about how you can use Jobs to be done as part of your UX toolkit.

Season 0 - Getting Untangled
Season 0 - Getting Untangled
DU022 - Jobs To Be Done - Liz Kessick Interview
/

What is a job to be done? How is it different to a user need? What size hole do you want?

Chris speaks to Liz Kessick, Senior Researcher about how you can use Jobs to be done as part of your UX toolkit.

Transcript

The Design Untangled Podcast

Episode: DU022 Jobs to be Done

Host: Chris Mears

Guest: Liz Kessick, Senior Researcher

(00:16) Chris: Hello and welcome to Design Untangled with me Chris Mears and today I am joined for a nice chat in the graveyards about jobs to be done with Liz Kessick, who is a Senior Researcher, Hello.

(00:28) Liz: Hello.
(00:30) Chris: I guess we can probably start with maybe discussing like where jobs to

be done came about. And so why it is sort of a popular thing now.

(00:44) Liz: So I think jobs to be done really came out of market research and sort of business analysis. So it is not something that comes natively from UX, which is why I think some UXers tend to be a little bit suspicious of it. And it was popularized by a bunch of business professors in Harvard business review, et cetera. So it really comes from that kind of like MBA type stream of doing that deep analysis, and trying to find out perhaps new market opportunities.

(01:19) Chris: Can you give an example of maybe what a job to be done might be written down as?

(01:25) Liz: The classic jobs to be done example, is the idea that maybe you want to put up some shelves, and perhaps in the past we would have thought, well, what you need is a drill to make a quarter inch hole, so you can put up the shelves. But you do not actually need the drill, what you are after is the hole. Getting to the hole, is the actual job to be done there.

(01:51) Chris: The hole is the goal, right?

(01:51) Liz: Yes, the hole is the goal, that is right. So it is kind of taking what we might think of as classic user needs, and abstracting that even further to, it is a sort of base level of what is it you are trying to accomplish. And the idea is, what do you hire, the job to accomplish that goal for you? Do you fire that method when you do not like it? And what are the trade offs?

(02:16) Chris: So the method in that example would be the drill, I guess, or that is 1

where you are hiring to get the job done?

(02:20) Liz: Yes, you are hiring the drill to get the job done. There is another good example, which is imagine you need to have a business meeting with some people that live on the other side of the world. And so, the job to be done there is to have that business meeting. Now the sort of things that you can hire to accomplish that job might be a economy class seat on a plane, a business class seat on a plane, or a much lower cost, with obvious tradeoffs. You might go for video conferencing instead. So it means that things like video conferencing is competing with airlines. Which makes it sort of interesting, because airlines would think that they compete with other airlines, but actually in this particular space, maybe they are not, maybe it is wider than that. Okay.

(03:08) Chris: That is interesting. Would you say, if you were to draw out a traditional user journey, like your end point in that user journey would be you have the meeting or whatever. And then you would sort of storyboard out the whole life cycle of that. So you might start off, the initial needs would be, you need to have a discussion with so and so, and they live over the world, and then you might map out a journey where they would go to the airport, and they do all that part of it, and get on the airline, and then eventually get to this meeting with the other person. Is that a different way of describing it or they just two kind of different ways of saying the same thing?

(03:56) Liz: With jobs to be done people like to use jobs statements. So for example, it would be the use of, when I want to, so I can. So perhaps in that particular scenario it is when I want to come up with a marketing strategy so I can increase sales to business, might be the job to be done there. And maybe, the contingency there is that you need people across the world to do it. So it is sort of, again, abstracting it down to that core piece of what it is you actually want to accomplish.

(04:33) Chris: Do you think they work better with established products or is it more, can it be used for when you are coming up with something completely different, or do you need to mix it with kind of more traditional discovery style methodologies?

(04:48) Liz: I think it is very useful for discovery and just again, getting to those core needs and I think sometimes it is quite good at getting to the an unexpressed user needs. Just in the way that you ask the questions, I think it is quite similar to the classic UX doctrine of the 5 Whys. I am just trying to get it down to that level, but perhaps it has a bit more structure than 5 Whys. I think where it is not as useful, would be for example, things that are more higher up, more finessed, for example, UI. You cannot really use jobs to be done too much to think about content or UI. It is more just about actually what the product is and what it does.

(05:34) Chris: Could the content potentially be one of the things you are hiring to get to an ends goal?

(05:40) Liz: Yes, sure. If you are thinking about it maybe in the context of maybe training or education, et cetera, maybe it relates to that. But as far as say maybe, marketing copy, or brand copy, perhaps jobs to be done is not quite what you would want to use for that, or you would not want to use just jobs to be done. One the important things to remember about jobs to be done is it as part of a UX toolkit. It is not necessarily something that always has to live on its own, it works quite well with different personas. Can have perhaps different jobs to be done, for example, it works quite well with user needs, with contextual analysis, et cetera. I think jobs to be done on its own, is quite a powerful piece of analysis, but it is something that maybe you do not want to use all the time or to just rely on.

(06:30) Chris: Yes, well I have heard it said that it is useful when you have got just a really diverse kind of user base, where if you were to create personas, you would probably be doing it for the next 20 years because there is just so many variations.

(06:45) Liz: Yeah, absolutely. That is what it is really good for, is just thinking about your customers maybe, and if you have like the diversity of customers, just breaking it down to like, okay, well these customers might be very different in person. Maybe we cannot create personas for all of them, but we can understand what the core job at the heart of their experiences are.

(07:05) Chris: I suppose there is a risk with that as well, because seen in plenty of organizations, they just say, a product is designed for anyone without really thinking that through. So yeah, I suppose just a word of caution that you should not take that at face value and just say, oh yeah, this product is for everyone. That is just a job to be done because we cannot do our proper kind of user segmentation but that is not always the case.

(07:32) Liz: Sure. I think that, with every methodology, abstracting from the user, from the customer is always the risk. And I think jobs to be done again, it works quite well when you perhaps do you have those customer voices from maybe CS, or whatever sort of backing up, that these are the things that need to be done and some examples of, quotes and examples and, as usual, the more you can get sort of verbatims and videos of what your customers are up to, the better.

(07:59) Chris: Yes. There is may be an argument that the language of jobs to be done works quite well with more senior stakeholders, who are may be a bit more business focused and less use of focus. Because you can elaborate as to what are the key things of this product needs to do, as opposed to having say to them these are the things the user needs to do, which may be does not land quite as well all the time.

(08:23) Liz: Absolutely. And I think because of how it is, the history that it has, and also the fact that with the jobs, you can actually start to think about what other methods compete for this particular job, and how can we drive value out of this job? And perhaps there is a job that is particularly unmet, by your customers or by potential customers. It gives you an idea of, where you can go as far as delivering a product and getting sales up. Yeah, for sure.

(08:55) Chris: Are there any sort of risks you see with it?

(09:02) Liz: Like I said, if it is part of a tool kit, I do not think it is necessarily risky. You know, there are some organizations like for example, Twitter completely changed their structure, around jobs to be done. And I think it was one of those scenarios that we just talked about, where they have such a diverse user base, there is no way that personas are going to help them. But, by abstracting down to the jobs, they can actually think about building the right products and services for this massive user base. And they have actually, completely restructured the team around jobs to be done. And I guess to me that is a risk, but also an opportunity. So I guess it just depends on how far you want to take it.

(09:47) Chris: Yes. I wonder how well it would work in something like government, where the stakes are a lot higher, I suppose for some of the interactions. For example, if you are trying to claim some sort of benefit, so that you can eat that night, or whatever, I wonder would jobs to be done work okay in that sense, in that, I suppose you are hiring whatever the service would be online to get yourself fed, or in that scenario is it better to stick to user needs where you really have to take into account a lot more of the sort of wellbeing of the person using that service and stuff like that? I do not know if I know the answer to that bit. An interesting one to ponder.

(10:34) Liz: Yes. I would certainly say the jobs to be done is not a replacement for empathy, especially from the UX research point of view. Which again is why, I think it pairs quite nicely with personas sometimes, or at least having some example customers, having some customer feedback, to back it up. And it is much stronger that way too because, you have that sort of business analysis side of the jobs to be done, but you also have the customer involved.

(10:56) Chris: Does it take a similar amount of time to break down your research into a jobs to be done, or is it quicker process, slow process? Was it just a different way of kind of analyzing the same data and getting a different output?

(11:15) Liz: So the process that I have been using is an interesting combination of qualitative and quantitative. Where we have been doing these big customer interviews, to sort of break down the jobs and essentially using something similar to the 5 Whys. And then surveying a wider customer base to see, these particular jobs, how important are they and how satisfied do you feel with those jobs? So that is another thing that I really like about it, if you are doing a big job to be done project, using qual and quant works well. I am not entirely sure I answering your question there with [inaudible 11:51].

(11:52) Chris: That is right. That is why this podcast is all about leaving more questions than answers. And I think that is kind of all I had from a sort of bare bones. What is jobs to be done? How do you use it there? Are there any other kind of takeaways you have got that you think might be useful for people?

(12:12) Liz: Again, I just think just to think about your products and services in terms of jobs to be done is really interesting. I think it would just be interesting to spend some time just doing a workshop, instead of thinking about what are the jobs that our customers want to accomplish. Let us take the customers’ perhaps needs, motivations, et cetera out of it. And just get down to those essential jobs. And it is, I think it is certainly worth just taking a look and playing around with it. And seeing whether or not you want to go further down that line, but I do think there is massive potential for unlocking a lot of value, where people perhaps have not realized that things are jobs and the entire sort of idea of hiring and firing is interesting as well. And or, sort of considering the trade-offs. For example, does your business want to spend all that money sending you on that first class flight, or can you accomplish 80% of it by doing the video conference? Well, in which case if you can, that does mean that the business class airlines have to watch out, and it does make you realize that perhaps for something like, I do not know, tiding you over for a snack or something, a banana, is competing with a milkshake, is competing with an energy bar. You know, things that are not necessarily always in the same category, through a marketing point of view, but they might still be being used for the same job.

(13:41) Chris: Something I was going to ask actually. Do, the user needs can change over time depending how your product develops, or you know, any other number of factors. Do the jobs that people want to do with your product, do they tend to change often, do you think? Are they always the same?

(13:56) Liz: So that is one of the interesting things about the jobs to be done, is the idea is that jobs do not change. There things you might hire or fire to do the jobs, might change, but the jobs themselves do not change. So you still need to talk to your colleagues and figure out the marketing strategy. You still need to fill yourself up before lunch time, et cetera.

(14:14) Chris: Okay. I think that was all I had to slash you have got anything else?

(14:19) Liz: No, but I would say if you are interested in jobs to be done, there is a fantastic article called, ‘Jobs to be done in your UX toolbox’ by Steph Troeth, who is from Clearleft. And I really recommend that one as a primer for getting started with jobs to be done.

(14:35) Chris: Okay. Cool. Well, thanks for joining us. As usual, if you have got any questions you can ask on the uxmentor.me Slack and we will see you next time. Cheers.

Search and subscribe to Design Untangled using your favorite podcast app and leave us a review. Follow us on the web at designuntangled.co.uk or on Twitter @designuntangled. Become a better designer with online mentoring at uxmentor.me.