Jim Kalbach is the chief evangelist at MURAL, a leading provider of online visual collaboration software. He's the author of Designing Web Navigation (O'Reilly, 2007), Mapping Experiences (O'Reilly, 2016), and his latest, The Jobs to Be Done Playbook (Rosenfeld, 2020). In this conversation, we dive into Jobs to Be Done, how it relates to design, and how jobs can create an “out of body experience” for organizations.

Show notes

Disclosure: I received Jim’s book for free as a previous Rosenfeld Media/Two Waves author.

Show notes include Amazon affiliate links. We get a small commission for purchases made through these links.

If you're enjoying the show, please rate or review us in Apple's podcast directory:

This episode's transcript was produced by an AI. If you notice any errors, please get in touch.

Read the transcript

Jorge: Jim, welcome to the show.

Jim: Hey, great to be here. Thanks for having me, Jorge.

Jorge: Well, I'm very excited to have you. Not only have you and I been friends for a long time, but you also wrote a book last year that I liked a lot, and I actually wrote about it in my blog. I'm excited to talk with you about the book and about what you're up to. So, for folks who might not know you, can you please introduce yourself?

About Jim

Jim: Yeah, sure! Hey everybody, Jim Kalbach here. Calling in from Jersey City, New Jersey, where I'm originally from, on the east coast. I moved to Germany for a long time. I lived in Germany for about 14 years and then came back to the U. S. But I have a background in information science and worked as an information architect for a long time, getting into topics around usability and UX. I have a very strong classic kind of design — product design — background. But I was always interested in research and strategic aspects of design and innovation. And then I got exposed to Jobs to Be Done around 2003, and always tried to incorporate aspects of that in my work here and there. Just kind of testing the waters. So, I've been looking at Jobs to Be Done for a while now, actually, in my design roles, but then also beyond that as well too.

Jorge: You're currently at MURAL, right?

Jim: Correct. Yeah, I'm the Chief Evangelist at MURAL. I've been with that company for six and a half years now. I was employee number 12 and through the pandemic, our business has expanded greatly. It's just… things have just exploded in a good way. Of course, we believe we have a tool — a virtual whiteboard — we have a tool that can help people. You know, through the pandemic, it was great to see our mission that we had been building up for five years before the pandemic then suddenly become hyper-relevant, and people reaching out and grabbing us by the collar and saying, "thank you for saving my project!" So that was just really fulfilling to see our mission, become hyper relevant.

But again, at the same time, it was absolutely fantastic for our business. And now we're like 600 people in the company. It's crazy how much we've grown. I started and I built up the customer success team and the support team here at MURAL. So, it was a little bit of shift from my background in product design when I got to MURAL. But then as we scaled, I wasn't the right person to scale a global customer success team. So, I moved over into what we're calling "Chief Evangelist" and it's basically a lot of outreach, writing, speaking onstage, doing some research, building relationships with our biggest and best customers, but also just reaching out to the community in general. So, it's a really great role for me to be in here at MURAL.

Jorge: You alluded to Jobs to Be Done, which is the subject of your latest book, the one that we were talking about earlier. I'm wondering about Jobs to Be Done at MURAL. And I remember when I first used MURAL, it seemed to me to be a tool that was looking to replicate the whiteboard. And with the pandemic we've been unable to access physical whiteboards, and MURAL has filled in the gap, right? So how would you describe the job that MURAL does for teams?


Jim: It's a really good question, and I've been chewing on that for a very long time. Before I answer that, I just want to mention that Jobs to Be Done at MURAL… haven't been very overt about it. It's not like we have a Jobs to Be Done round table and every week we do research and things like that. But it's there, and it's been in the background lurking behind… even our support team. Did a session with our support team, how Jobs to Be Done could help them in their work. Our head of product, there's a nice blog post out there where he talks about Jobs to Be Done in guiding the roadmap, and things like that. So, it's been around, but it's kind of like where we've been soaking in it rather than having a Jobs to Be Done research effort or explicit team around it. And in doing that kind of ongoing work, I've been really thinking about what are the Jobs to Be Done of MURAL.

And it's a little tricky. Because it's a whiteboard, it's a blank canvas. It's… you know, Jorge, I think a MURAL almost as a platform. A lot of times you buy a piece of software and you expect the software to tell you what you can do, and what you can't do, right? There's a workflow involved. There are steps involved, and that kind of thing. But with MURAL, it's like you can do anything that your imagination can bring to a whiteboard with it. So, I really think it's almost like a platform that you can develop on. And what can you develop? And the answer is, "yes!" It's like, what can you visualize? Then you can do it on MURAL.

So, it makes the answer to the question, "what's the job-to-be-done?" really slippery. But it also then puts out, the way that I've been approaching it, is looking at a constellation of jobs. And by the way, that's one of the first things that you need to do when you work with Jobs to Be Done is map out what I call your jobs landscape. Because it's not uncommon that organizations and businesses are targeted at a constellation of jobs, particularly in software. Software gets multiple jobs done. And one of the first things you have to do is map out your jobs.

And that… it's not just one dimensional, it's actually hierarchical; that there are jobs and smaller jobs that roll up to higher jobs. So, you end up with this landscape of jobs. And in MURAL, it can just go on and on and on. Because we're basically an open-source development platform that is as limited as your own imagination. But I think where we started and the jobs that we're looking to target first are things around like running a collaboration session with your team at work, because we're all about collaboration and we want to be relevant in the workplace, although we have a lot of educational institutions as well, too. It's really about running a collaboration session with your team, is kind of a high-level job.

You can go up from there and even say, solve problems together visually. Could be even a higher level… that's really abstract though. And if you were to research that using the Jobs to Be Done lens, which you could, you would come up with something more abstract. So, I usually try to break that down into things like running a collaboration session.

But we also have people running projects. How do people run projects and where does MURAL fit into that job to be done? Teaching a course! People teach, as you know, MURAL is a platform to teach from as well, too. Teaching a course is another big use case that we tend to target as well too. So, I have about… right now, I have about four or five jobs at that level.

The main one though, is really around collaboration. It's collaborating as a team at work, right? And what is the beginning, middle, and end of that? And I've found that if you map that out, you can take a lot of the situations that people come to MURAL with and you can fit it into that beginning, middle and end of collaborating at work.

The jobs of JTBD

Jorge: We're talking about this kind of in the abstract and I'm assuming that folks listening in know what we mean when we say Jobs to Be Done. Before we started recording, you were mentioning that you've done dozens of podcast interviews about this, so I'm not going to ask you the "what is Jobs to Be Done?" question. I'll leave that up to listeners. If they haven't heard about it, it's worth your while.

But you just now mentioned that something that's been on my mind in using Jobs to Be Done in my own work. And it's a fact that some of the definitions of a job-to-be-done can get quite abstract. And at that point, their utility stops being evident to team members. So, I'm wondering the meta-question: what do you see the jobs of Jobs to Be Done? Like, what does Jobs to Be Done buy a team?

Jim: Yeah! I think it's focus in innovation efforts. I really see Jobs to Be Done as an innovation framework. And innovation occurring at any level. You want to innovate your product or your solution, you want to innovate your go to market motions as well, too? But it could be, we want to expand our company. So, it works at different levels, right? The first question that I always teach people to answer in defining the jobs that they're going to be targeting is, "where do you want to innovate?"

And once you're able to answer that question, what Jobs to Be Done brings is a lot of focus and clarity to that. Because then there's a structured language behind Jobs to Be Done. And that's what I try put out in the first couple of chapters in my book is, what's the language around Jobs to Be Done to describe our innovation target, but to describe it in human terms. In human terms, right?

And notice I didn't say "user" or "customer" or "prospect" or "target market. " It's human terms. It's understanding within that space, once you define your innovation target, what do human beings want? And trying to find that out. It's different than ethnography though, because we're not going out and doing this very grounded, bottoms-up… there is some bottoms-up work to it, but you're not just trying to understand everything about their lives because you've defined your frame of innovation. It’s very specific in the human-based information that you're extracting from it. So, it's very focused and it's very lean in getting out human insight that then becomes opportunity for innovation.

Jorge: When you say, "human terms", I hear that as human terms in distinction to the drivers of an impersonal system, such as the organization or the market or what have you, right?

Jim: Or the product or the solution. Right! And one of the great benefits of the language of Jobs to Be Done is that it expunges all of that from your vernacular. That when you're talking and working with Jobs to Be Done, you're not allowed to refer to any technology, solutions, brands, or even methods. So, Agile is a method. Design thinking is a method. You wouldn't write that down when you're notating Jobs to Be Done. You wouldn't refer to any of those things. You're trying to describe human needs… a very specific description of human needs.

Again, it's not this ethnographic type of thing. You just want to go in and get what you want and get out. It's very surgical in that sense. But you're describing it in a way that is independent of yourself, because organizations are really good at looking at human beings through the lens of their own brand and their solution. We looked down at the market and we say, "those are users. Those are customers. That's a buying behavior. That's a user behavior. We have a solution. Click the button! Optimize conversion rates!" That's about you.

Let's be serious here. A customer journey map and a lot of that stuff, that's about you and your organization. That's not about human beings. Jobs to Be Done explicitly puts that to the side and then you're asking yourself, "well, how do I describe that then? How do I describe what people want and what they're trying to get done?" And Jobs to Be Done gives you way to do that. Once you put all that other stuff to the side, you can still — in a very structured, targeted and focused way — you can describe human behavior. Very specific types of human behavior.

JTBD for the reluctant

Jorge: When you say innovation… when anyone says innovation, one of the things that I hear is change. So, we have a current state in which we're doing things a certain way, and we want to change that to a different state in which we're doing things differently. Or our product looks different in the market. And innovation has kind of a positive tinge to it, whereas change is more ambiguous, right? And a lot of folks are resistant to change internally in organizations. I'm wondering about how you might explain the value of Jobs to Be Done to reluctant stakeholders or to folks who may not be fully on board with driving some kind of change?

Jim: It's a really good point and in fact after we launched the book, I created an online resource called the Jobs to Be Done toolkit, jtbdtoolkit.com. And we were talking about exactly this. Like, who are we targeting? And we ultimately threw away roles and labels and ended up with changemakers. We're targeting changemakers in organizations because of the question that you just asked is that some stakeholders are resistant to change, you're right. But other people in organizations want change, right? They see their own brand or solution on the market. Or they see the way that they're working internally and they say, "we have to change. "

And I think a lot of that is driven by the world we live in. And I don't want to say, '"now it's different than in the past!" But there are specific you know, things that are unique about today's world. Hyper-connected containerization and productization around the world, global economies and talent pools and things like that. There is the different, more complex business world that businesses face these days. And I would argue that it puts a lot more power in consumer hands than even just two or three decades ago. We're all on a burning platform because any consumer can rate you, and any consumer can go to a competitor with one click of a button.

So, I think it changes the equation of business from the middle of the last century. I think that's the motivation for change, in general. And stakeholders that don't get it, well, you know what? They're going to be left behind, Jorge, first of all. Because there are lots of statistics like the list of customers of companies on the S&P 500 list is… their duration on that list is getting shorter and shorter and shorter. You know, IBM is IBM and it'll be IBM forever. It's like, "well, man, you know, maybe it won't right?" Because disruption is happening at a quicker rate as well too.

So, I think the imperative is there from the way that things work in general to make change, and yeah — some people will be resistant to that, I agree. I think the thing that's different about Jobs to Be Done, is it's very no-nonsense and the focus and the clarity that it brings… and it also speaks a business language to businesspeople on their own terms. I think it's more appealing than other change mechanisms. Like Design Thinking. People have used Design Thinking to affect change to their organizations as well too, but a lot of people react to that: "I'm not a designer. Design is aesthetics. Why would I want to think like a designer?" You know, and things like that. So, there might be a lot of overlap of Jobs to Be Done with other fields, like Design Thinking. And there is.

But it's the way that it does it that I think actually appeals to those stubborn people better than some of the other approaches. And I'm not saying throw away Design Thinking; I teach Design Thinking, you know? So, I'm not saying throw that away, but I think we need a new arsenal of conversation styles and languages because of the question that you asked that some people are stubborn, right? And I think Jobs to Be Done helps overcome that stubbornness. Exactly that. That's exactly my attraction to Jobs to Be Done, Jorge.

Creating an out-of-body experience

Jorge: One of the interesting things about what you're saying here is that it's all very self-consistent, in that at the root of the approach is reframing our offerings from the perspective of the people who are benefiting or who are getting value from our offerings, whether they be customers or end-users or what have you. And that requires that we as a team, as an organization, step outside of our own needs, right?

Jim: Correct.

Jorge: And what you're saying here is that this applies not only to the product or the initiative that we're undertaking, but to ourselves. Like, our own perception of who we are is up for questioning here.

Jim: That is absolutely correct. And one way that I like to describe the reason and the benefit of Jobs to Be Done is to intentionally create what I call an out-of-body experience for yourself, right? Because you're so wrapped up in yourself as an organization. Like I said, organizations are really good about talking about their own brand and their own solutions and their own customer base, that we forget about other perspectives. And the other perspective is, there's a human being over there just trying to get something done in their daily lives, and they may not care about your brand or your price point or your conversion rates. What would happen if just momentarily — and it's only momentary suspense of belief — that we flip perspectives and we see things from their perspective, and look back at ourselves.

And the answer is… or the benefit is, you can find opportunities that you don't see because you're your own blinders. So. It is a perspective shift and that's why I also describe Jobs to Be Done as a way of seeing. It's an alternative way of seeing because we see our organizations from a business standpoint, like I was saying. It's like, well, what would happen if we just shifted over and saw it from 180 degrees and looked back then pick out those opportunities, and — no question about it, Jorge — you always come back to those conversations about your own organization and your own product. Have no fear that you're not going to talk about your own brand. So, it's just a temporary shift outside, and then you come back in. And the idea is you can find opportunities that you wouldn't see from your own perspective.

JTBD and design

Jorge: And in that it shares a lot with the design process, right? Like you…

Jim: Absolutely!

Jorge: You mentioned Design Thinking here. In fact, when I read your book in preparation for reading that I read, Clay Christensen, et al's Competing Against Luck. And I revisited the notes that I took on that book before our interview this morning, and I wrote down that at the time, it struck me as user-centered design made palatable to stakeholders because it's being taught by Harvard Business professors, which is kind of what you're talking about here, about the language.

Jim: I agree. And you know, I don't think that's unimportant though, Jorge. Like I said, I've been looking at ethnography and Design Thinking and UX and all of these other disciplines and human-centered design, and I've been steeped in those things, right? And as you know, the design community pounds its fist on the table and says, " we want a seat at the table!" Right? And rightfully so, as well too. And I think Jobs to Be Done helps that because it comes from the business community. There's no territory or ownership there that anybody can own… there's no one discipline that runs or owns Jobs to Be Done. It's really a language across your organization.

And I'll tell you, since I wrote the book, I'm being contacted by marketing teams, by customer success people, obviously by people in product. Entrepreneurs are looking at Jobs to Be Done as well, too. So, I think there's a chance to have that same kind of human centeredness, whatever you want to call the center of gravity there, and to actually get further in our organizations because of its origins and because of how it's positioned as not any one discipline owning it. That said, I do think there are some important differences though. There are some really important differences between existing methods that are human centered design and Jobs to Be Done.

Jorge: I would love to hear what those are.

Jim: Well, the first one we kind of touched on already too, and that's the hyper, almost fanatical expunging of any reference to technology, solutions or products, right? I get a lot of people say, "tell me task analysis. This is just task analysis, right?" Jorge, I cannot find one example of task analysis that doesn't include a reference to the solution that the person who does task analysis has in front of them. In fact, some examples of task analysis are literally saying, "click the button on the second screen, then click the next button on the next screen. " That's product design. That's not how humans think about their own needs, right? I think that is… it's huge and it's important and it's not that easy, to be honest with you, Jorge.

I teach a lot of classes now on Jobs to Be Done. And I get a lot of designers because a lot of people that follow me are in the design field. And then, and I'll say, "you can't use any technology. " And then I do a little exercise with them, and they use technology! In the sense, I say, "no, you can't say Design Thinking, you can't say screen. You can't say document. You can't say all these things. " So, to actually do it… and once you actually do it, you're like, "oh, I can't use any of these terms. And if I don't… " Here's the thing, if I do that, step-by-step through Jobs to Be Done, I don't use any technology, solutions, brand, any reference to any of those things, and then you look back at what you just built up, you get that freedom, you get that out of body experience that you often don't in those other fields, to be honest with you.

Jorge: Circling back to the effectiveness of this language versus the language of design, in hearing you describe that, I was thinking that as information architects, our own job-to-be-done is to create effectual language structures, right? And we iterate on labels to find the ones that resonate the most with folks. So, if we are doing the work and we find language that makes it more understandable, more engaging to stakeholders, let's use that language, right?

Jim: I agree. Yeah. And it's interesting, you mentioned that because… well, first of all, I said, "you have a landscape of jobs that's your first thing to do?" Guess what? That's a little mini information architecture right there. What's my innovation target is, there's a little architecture in there. But then when you're working with Jobs to Be Done, it is very, very much about language. And one of the first things that I try to show people and demonstrate is that you need at thesaurus. So, it starts with qualitative research, and people don't speak in regular normal terms.

Jobs to Be Done is essentially a big categorization mechanism, that when you're listening to people talk, you say, "oh, that's a job performer. That's a job step. That's a job step. That's a job step. That's an outcome. That's an outcome. " And then you end up with piles of regular information that you gather from your qualitative research, which, you know, is very messy. And that normalization that you do to categorize things, often requires a thesaurus because you're saying like, " what's the best word to express that? What's the simplest, most compact word that I can use to express this?"

You know, somebody just talked in two paragraphs, and I want to rewrite that in one phrase in one, three-word phrase, right? What's the best word in there? And some things are obvious. Some things are super obvious. But sometimes you get on these cases where you're like, "what's the best word for that?" And it really is about language. It's really about how you're expressing that. And the models that come out of Jobs to Be Done research… it's really a model of, language. Of rewriting qualitative input that you get using the Jobs to Be Done rules. And it's really about modeling that. And there is a lot of architecture involved.

Making "jobs" more actionable

Jorge: I'm thinking about what I think is a job-to-be-done and it's one of my favorite ones because it's actually, stated up front when you visit this place. And it's the bronze plaques at the entrance of Disneyland. There's two tunnels under a train track when you enter Disneyland. And there's these plaques that say, "here you leave today and enter the world of yesterday, tomorrow and fantasy. " And it's almost like they're telling you what the intent is for that environment, right?

Like they designed this thing that aims to accomplish that. And there's this story that Walt Disney used to give his designers, the people were designing the parks, one overarching direction: whoever comes in contact with this thing that you're making should leave the experience with a smile on their face.

And those to me are descriptions of jobs, right? Of what the thing is supposed to do. But there's a very wide gap between, "here you leave today and enter the world of yesterday, tomorrow, and fantasy," and what it takes to actually design a theme park ride there's a lot of decisions in between. And I'm wondering about how you bridge that gap. There's this language, this three-word pithy phrase that you have defined that sets the vision. How do you make it actionable?

Jim: Yeah. Well, I think, there are two things at play there from the example that you mentioned. One is a hierarchy, and a hierarchy of needs or intents. You used the word intent, so we can talk about that. And I would actually… the examples that you gave, I would actually categorize those as… the first one as aspirations, right? And then you said, "leave with a smile on your face. " I would call that an outcome as well, too. This is all detailed in my book. But to actually put it into practice, maybe this is a good example to help folks think about that.

So, actually break things up into… well, there's multiple categories. But for this conversation right here with you, Jorge, I think there are three things going on. One is the aspiration. What's the ultimate aspiration? And Clayton Christensen, who you mentioned, and others, they tend to work at that level, which is fine.

And I think that's super important. But I think if you come down a level, you can also say, "yeah, but what's the functional job that people are trying to get done?" I call that the objective. And in your example, it might just be visiting a theme park. So I think you can anchor that aspiration at a high level, but then come down and say, "you know what? We got to build solutions that get people from point A to point B. " Visiting a theme park, right? There's a beginning, middle, and end to that, and we better fulfill that functional job or that objective they have. And then on the other side is what are the outcomes that we want people to have? And that would be, leave with a smile on your face.

So, the thing that you said on the plaque, I forget exactly what that was. I would categorize that as an aspiration, and then "leave with a smile" as an outcome. The thing that's missing though is what's the functional job? What's the getting from point A to point B, the plain vanilla… I just have an objective to get done because your solution better get that done, right? Independent of emotions and aspirations and all that kind of stuff.

So, Jobs to Be Done is really no nonsense and very structured around taking that example that you just gave and puts things into different categories. Let's think about the aspirations. Fine! Let's think about the outcomes. I can do analysis on that. But what's the functional job that people are trying to get done? That's another piece that you also have to work with.

I've done a lot of, let's say Design Thinking workshops where you walk into the room and you say, "we're going to solve world peace today," and that's your target for the group, right? And then you brainstorm on world peace, and you ended up in a room full of sticky notes. And you're like, this is a group of mid-level UX designers. What are they going to?

There's too much distance between what we do as a business and what we just came up with. You're trying to innovate at too high of a level. And I've been guilty of doing that, in blue skying everything. "Let's blue sky! No constraints, blue sky!" It's like, no. Why can't we say, "we want to figure out a better way to drill a hole in the wall. " Why can't we innovate at that level?

I think actually innovation has a better success when you don't just go in and write down pie in the sky. Let's brainstorm, but say, " how can we make a better hole in the wall? Let's innovate that, guys. " Because that's the level of our focus. And you can absolutely do that. In fact, I was drilling a hole in my wall a couple of weeks ago and I was like, "wow, there's a lot of problems here. There's dust all over the place. I got to set up my drill… " Like this, "oh, this is ripe for innovation, actually. Drilling a hole in a wall is absolutely a place where you can innovate!" But we overshoot. We tend to overshoot, I believe, a lot.

Jorge: Definitely. And it's part of why I find the concept of Jobs to Be Done so attractive. And especially as you express it in your book — it's very pragmatic. It's not academic in the way that so many of these ideas tend to be. So, I heartily endorse the book and your work, and I am very grateful that you've made the time to share shared with us here today.

Jim: Well, thanks for having me on and for your writeup as well, too. And again, I think I said it before too, but I think that's not unimportant: the pragmatism of Jobs to Be Done. And a lot of people criticize it. "But you're leaving out this," and "you're leaving out that!" Then it's like, yeah, you're leaving all that stuff out because sometimes that confuses those people or puts off those people who are reluctant to change.

And you can just go in and say, "we're just going to do these three things. " There's a lot that gets left on the editing floor in Jobs to Be Done. And I like to scoop those up and put them into a separate pile, but you can just go in and just do this really focused thing, with Jobs to Be Done.

And I think, again, you mentioned it at the beginning. It's the focus that Jobs to Be Done and the no nonsense focus and the practicality and the pragmatism of Jobs to Be Done that I find really attractive, but it doesn't exclude those other things. It doesn't exclude Design Thinking or ethnography or UX design as well too. And I think you can actually add those things together. So, one of the things that I'm working on, Jorge, is how does Jobs to Be Done fit in with those other pieces of the puzzle and even things like Agile and Lean.


Jorge: I think that a lot of folks listening in and I myself would be very interested in hearing what you have to say about this when you publish it. Where can folks follow up with you to keep up with what you're thinking about?

Jim: Sure. On LinkedIn. Connect with me on LinkedIn. I make announcements and post some information there also. Also, Twitter. It's @jimkalbach at Twitter. But I think also at the Jobs to Be Done toolkit, the website, it's an online resource. There's some free downloads there jtbdtoolkit.com - some free downloads. We also have an online course. It's a self-paced video course there. So, you can just sign up for that any time, but we also regularly… pretty much every other month. It's not a hundred percent regular yet, but we've been at a pace of about every other month we run a live course. And you can find out information about the next live course on Jobs to Be Done toolkit.

Jorge: Well, fantastic. Thank you for being on the show.

Jim: Thanks for having me, Jorge.