Jobs To Be Done: An Occasionally Useful UX Gimmick

It was puzzling. Jay (not the study participant’s real name) was sitting in front of a desktop computer with an open browser. Yet, it was his phone that he grabbed.

On his phone, Jay immediately opened his bank’s mobile app. Once he logged in, he glanced at his account balances, then proceeded to move a chunk of money from his checking account into his home equity account.

I was puzzled why he didn’t use the bank’s website instead. “The phone app is so much easier,” Jay responded. “I do this transfer every month and I find I can get it done faster using the phone.”

This fascinated me. Jay had used the bank’s website many times. He showed me how he paid bills using it. But when it came to transferring money, it was easier for him to use the mobile app.

Hiring and firing

Jay needed to make a money transfer. To resolve that need, he chose the mobile app over the bank’s website.

We can frame Jay’s choice as two actions: For the job of transferring the money, Jay fired his bank’s website and he hired his phone’s mobile app.

The choice users make to fire one thing and hire something different is important. Why are they making that choice? If they choose to fire our design and hire someone else’s design, are they trying to tell us that our design is deficient in some way?

Why did they make this choice? The question points to a problem of impedance. In Jay’s case, the website provided some impedance to the job of transferring money. The mobile app resolved that impedance.

If the bank’s design team understood the impedance and what caused it, they’d have several options. They could market the effectiveness of the mobile’s apps transfer capability, to get other customers to take advantage of it. Or they could update the website’s design to remove whatever was slowing Jay down, to make it a more desirable solution in the future.

That’s the power of Jobs To Be Done. JTBD (as the kids call it) is a new approach to talking about choice and impedance. The Job is the progress a user is trying to make. (In this case, Jay is trying to make progress paying down his home equity loan.) The user hires and fires products or services to make that progress efficiently.

Where jobs to be done came from

Jobs To Be Done was popularized in Clayton Christensen’s books on innovation and disruption, primarily his 2016 Competing Against Luck. (It’s most telling by the subtitle of the book: The Story of Innovation and Customer Choice.) Christensen’s is the best resource we’ve found at describing how JTBD leads to innovative products. It’s what you’d expect from Harvard Business School’s foremost authority on how companies can deliver innovative products.

Yet, Christensen’s book doesn’t describe how to get there. This has spawned a small army of consultants to fill in the gap. Each of them has written their own books, including Chris Spiek and Bob Moesta’s Jobs-to-be-Done The Handbook, Alan Klement’s When Coffee & Kale Compete, and Anthony W. Ulwick’s Jobs To Be Done Theory To Practice.

In each case, the various authors talk about uncovering how the users make choices. Ulwick tends to be more focused on what people do with the product or service. The others tend to be more focused on progress that people are trying to make.

(This difference has created a bifurcation in the JTBD community, which can get contentious at times. That contention makes it hard to understand what JTBD offers at times. Several UX professionals have told me they turned away from JTBD, because they were turned off by the turf wars and excessive salesmanship of the consulting practices.)

The framing of jobs to be done

The believers of JTBD tell us that when teams don’t know what their users hire a job for, they’re likely to make poor design and marketing decisions. In JTBD, marketing and design find common ground to ensure their product or service addresses the customer’s (or non-customer users’) unmet needs. This could be useful.

Not too long ago, in a study we did of insurance agents, we noticed several of them turned to spreadsheets for creating price quotes for their customers. They told us they’d chosen to build and use their own spreadsheets, instead of tools their insurance company’s IT department had built, because the IT’s tools were overly complicated.

We could frame the agents choice as firing the IT tools and hiring their spreadsheet. The customers’ Job to be Done is getting the customer an insurance quote quickly.

In other studies we’ve conducted over the years, we observed customers trying to resolve issues. Many of those customers chose to call a toll-free support center number and talk to a human customer service representative instead of using the available online knowledge center. Those customers told us they preferred the human interaction because it gave them confidence in the issue’s resolution.

We could frame these customers’ choice as hiring the call center representative and firing the knowledge base. The customers’ Job to be Done is resolving their issue with confidence. A Job to be Done is another way to frame an unmet need. It puts it in the simple context of a service.

Jobs to be done forces a user-focused approach

Christensen’s basic argument is you’ll create something innovative by focusing on the job the customer needs done, especially if it isn’t being done by a current product on the market. You’ll solve a customer’s unmet needs in a way that nobody else has. Christensen is using JTBD to promote a user-focused approach to innovation.

What’s great is we now have a Harvard Business School authority promoting talking to customers. Christensen spends an entire chapter scolding business leaders for being too inward focused. He tells them to listen primarily to what he calls passive data, instead of the normal data that the organization is swimming in.

Passive data is hard-to-get qualitative data that will go beyond the market data. Christensen doesn’t say it, but passive data is what we would call user research. He argues you need to get out of the building and talking with customers, to uncover the true jobs those customers need to do.

User research: JTBD’s mystery step

One of the best features of all these books on JTBD is the volume of case studies. Christensen’s book is full of them, as is Klement’s and Ulwick’s. Spiek and Moesta produced a podcast that’s filled with them.

We noticed pretty quickly that every case study followed a basic template.

Act 1: We meet the executive or senior stakeholder who is convinced they understand why customers are choosing their product.

Act 2: The executive/stakeholder discovers Jobs To Be Done.

Act 3: Because of the Jobs To Be Done work they did, the executive/stakeholder changed up the product or its market positioning.

Epilogue: Profit!

What intrigued us was the lack of specificity for whatever happened between Acts 2 and 3. Only Spiek and Moesta go into any depth of how they determined what the customer’s jobs are. Everyone else leaves it as a mystery step.

Spiek and Moesta use an interview process. In one podcast episode, they reveal their technique by sharing an interview they did with a course attendee about the experience that attendee had buying a mattress. (Christensen reprints the 8-page transcript of this interview in his book.)

In his book, Ulwick unironically outlines an 84-step process he calls Outcome-Driven Innovation. (Really. It’s 84 steps. No joke.) But he only describes the actual research in a single step:

Step 12: Conduct customer interviews to define the core functional Job-To-Be-Done. (The following 72 steps are a variety of activities to validate the team did step 12 correctly.)

This lack of discussion suggests that JTBD is user research agnostic. Any amount or quality of user research will produce the same results.

We know, from years of design practice, that the quality of user research matters. Inadequate or poor-quality research will not uncover strategically important unmet needs. Leaving the research details undefined opens a door for process issues down the road.

The problem with jobs to be done

It’s this lack of definition on how teams conduct user research that makes JTBD problematic. Not because we don’t know how to do it. We know a lot about researching unmet needs.

Suzanne Bödker’s Activity Theory first started talking about this in the mid-80s. Karen Holtzblatt and Hugh Beyer’s Contextual Design gave us techniques specific for products and services in the 90s. There are decades of work behind applying modern ethnographic techniques to everyday product and service design.

More recently, we’ve seen work in Indi Young’s Mental Models, Jeff Patton’s Story Mapping, Dan Brown’s work on discovery, Gerry McGovern’s Top Tasks, and tools like Jeff Gothelf’s Lean UX and Jake Knapp’s Design Sprints. All of these practices are about surfacing and focusing on unmet needs of customers.

The lack of definition is problematic because it sends the message that research isn’t a critical part of a JTBD approach. Reading Christensen, it would be easy to think that uncovering the job is simple and take virtually no time.

It’s disappointing that Christensen, in this well-written book that’s likely to catch the attention of many senior executives, never mentions of any of this work. He treats his Jobs Theory as if it was something wholly new and recently invented. (For him, it may seem that way. Maybe we haven’t done a good job of promoting our field of knowledge to those outside, like business school professors, who might benefit from that knowledge?)

None of the consultant’s books mention the expertise that many UX professionals have. Some, in trying to protect their consulting revenues, go so far as to try to position JTBD as a faster, better, and more effective alternative to UX, which makes it even more problematic.

(Jim Kallbach is working on a new JTBD book. We love Jim’s work and are confident he’ll do a great job of showing how JTBD can integrate into modern UX design practices in a way that the current books haven’t done.)

Jobs to be done is a sometimes useful gimmick

Professional magicians, dating back to Houdini’s time and before, have used the term gimmick to describe a device used to perform an illusion without requiring any skill in the art of performing illusions. With a gimmick, you just turn a nob, press a button, or engage the device in some form and, voilà, the audience sees the desired magical effect. The audience never knows the gimmick was engaged. That’s part of the magician’s secret.

If you’ve ever seen a children’s first magic set in a toy store, that’s a box of gimmicks. Professional magicians use them too. Anytime you’ve seen someone sliced into pieces and then reassembled in front of your eyes, well, the performers used a gimmick to make that happen. (Sorry if I spoiled that illusion for you.)

There are non-magical gimmicks too. For example, a magnifying glass is a device that lets its user focus in on the detail of a small part of the world. You don’t need special vision skills to see that detail. Just hold up the glass and new details are revealed. (Like magic!)

JTBD’s framing of hiring and firing is a gimmick. It’s a device for revealing and gaining a shared understanding of the behavior behind unmet needs. That has its uses. (And it seems like magic when it works!)

When a team is inwardly focused and creating features or imagining benefits without finding out what customers really need, JTBD can help. It can get the team members all thinking what those unmet needs really are. It’s a nice way to force a user-focused approach to design.

Two problems with gimmicks

A problem with gimmicks is, you can’t use them all the time. We can’t walk through the world with a magnifying glass on our face. Nor does the hiring/firing framing work for all types of needs.

What are the jobs a banking customer would hire or fire the bank’s website for? That will differ, based on the specific user and their needs. Remember, Jay hired his bank’s website for bill paying but fired it for money transfers. What would he do for checking balances, seeing if a deposit cleared, determining if he can afford a new monthly car payment, figuring out how much he can spend on his upcoming vacation, or any other of the multitudes of activities.

Jobs to be Done can’t help with most complex products and services in the world today. Sure, we could apply it to specific features or functions (and maybe we should more often than we do).

Another problem with gimmicks is, you can’t learn to achieve the same result without it. Gimmicks while useful, will become a crutch. All professional magicians will use a gimmick now and then. However, the best magicians can perform illusions with common objects. They can borrow a common object, like your phone or your ring, make it disappear, and then, magically, make it reappear in a place you didn’t expect.

To perform that level of magic, they need to learn and hone their crafts of manipulation and misdirection. Using a gimmick doesn’t help them learn or hone these crafts. It’s a completely different set of skills.

The same is true of design. The gimmick of Jobs To Be Done only works in certain situations. However, we have to build innovative products that deliver compellingly great user experiences even when JTBD isn’t the right approach.

To get those results, we have to learn a different set of skills than JTBD. At best, JTBD is just a distraction from the real skills we need. At worst, it takes our team in a completely wrong direction.

We need to be careful declaring, as Christensen and his disciples have, that Jobs To Be Done is the be-all-end-all innovation process. Christensen’s case studies make his book great, they also make it seem like JTBD is simple to do.

The lack of acknowledgment that design and research play a role in Christensen’s process of innovation makes it problematic. Design and research are not only seen as unnecessary, we don’t even have to acknowledge these practices exist.

Informing our jobs to be done practice

Jobs to be Done has its uses. We need to understand the contexts where it delivers value and identifies alternatives when the situation is too complex to use it.

Jobs to be Done can’t stand on its own. We need to support it with the expertise we’ve gained over the last few decades while creating our design research practices. Before learning how to apply JTBD to a project, we’re recommending teams learn and start practicing the techniques from these UX design leaders:

• Karen Holtzblatt and Hugh Beyer’s Contextual Design
• Kim Goodwin’s Designing for the Digital Age
• Steve Portigal’s Interviewing Users
• Chris Risdon and Patrick Quattlebaum’s Orchestrating Experiences
• Leah Buley’s The User Experience Team of One
• Dan Brown’s Practical Design Discovery
• Jim Kallbach’s Mapping Experiences
• Carolyn Snyder’s Paper Prototyping
• Jake Knapp and John Zeratsky’s Design Sprints
• Jeff Gothelf and Josh Seiden’s Lean UX and their Sense and Respond
• Indi Young’s Mental Models and Practical Empathy
• Gerry McGovern’s Top Tasks

There’s a trove of expertise there. It’s the background a UX professional should have when exploring the current Jobs To Be Done approach. With this expertise under their belt, they’ll see that JTBD is an occasionally useful gimmick and know exactly when they need to employ it.