Why 'Jobs-to-be-Done' Doesn't Work and What You Should be Doing Instead

As a product practitioner, you probably nod your head when you hear the term Jobs-to-be-done. "Customer jobs" are cool to talk about. This is something we hear all the time. "Our customers "hire" our products to help them with something in their lives." Everyone is on the same page.

In this article, I'll explain why I believe nearly no one understands or applies the theory correctly in practice. I’ll show why it’s hard to apply practically, and that even if the business really wanted to do it, they'd have to do a lot of work. Finally, I’ll explain that it’s not perfect for new products unless you’re lucky or have a lot of skill and time.

What's Wrong With Jobs?

You’re Not Ready For It

The main problem with how we think about Jobs-to-Be-Done is that it's the exact opposite of how people usually end up making things.

Most people start with ideas and then look for problems that fit those ideas. And what do they do when the idea doesn't work? They either retrofit the idea to fit or look for additional confirmatory data for the idea.

Sure, they might change some parts of the idea and the way they present it and the new product they're making, but because the idea has caught on, they can't see past the evidence.

This part is not unique to jobs-to-be-done. Most methods of design thinking start with needs or problems and then move on to solutions.

But when it comes to jobs, the same job can be done in so many different ways that you can't prepare for what you'll find out. 9/10 your product won’t fit the jobs, so you’ll discard them or end up paying lip service to them.

Because of this, the word "jobs" has become nothing more than a way to make people sound smart in presentations in most cases.

Great Theory, Patchy Practice

The other problem with Jobs is that, much like strategy, it doesn’t have a complete set of practices to implement it.

The theory is strong, but the practice is shrouded in some level of mystery.

There are 2 main schools of JTBD thought:

• Tony Ulwick’s
• Bob Moesta's, et al.

While the theory was developed by Clayton Christensen, with Bob as one of his main collaborators, Tony Ulwick claims to have introduced it to Christensen originally.

Since then, the practical application paths have diverged.

Tony Ulwick’s Outcome-Driven Innovation is one path. Bob Moesta and his partners have developed their own path. Many more authors have put their own spin on the jobs-to-be-done practice. But the main point is that these people are consultants who want you to bring them into your organization so they can use their knowledge (and get paid a lot of money).

So they always leave out a few things. For example, it's only hinted at and rarely fully explained that Moesta's process during the analysis relies heavily on fairly complicated cluster analysis, for which there is no standard application. Of course, Ulwick doesn't tell all of his secrets either.

Others have come up with their own mixed methods, but the point is that if you don't hire those people, your research on jobs-to-be-done will probably run into some problems and probably die before you can use it in a practical way.

It’s a Lot of Work Even if You Decide to Do It

Intercom and Basecamp were two of the most well-known examples of how JTBD was used successfully in a semi-open environment, and they went on to tell the world about their success. But the details are what really matter. It wasn’t a 1-month engagement for them.

So it's likely that if you hired an agency that tried to copy the books as closely as possible or, even worse, if you let your busy product managers do this research on their own, your JTBD research won't be strong enough to get you anywhere.

Companies must be willing to spend the time and money needed to figure out what their customers want and why, as well as to question what they think they know about their products and markets. Rarely is that the case, though, because most companies are on fire and need solutions yesterday.

Existing Products vs. Existing Jobs

Lastly, jobs can reveal the existing process behind how their potential customers solve their jobs.

However, jobs work much better if you already have a product that people buy (so you can figure out what job they're hiring it for) or if people use similar alternatives to your product (so you can understand the job and redesign the solution to fit the job better and win the customer).

In the second case, where you're trying to figure out what products people hire, it can be expensive and time-consuming to trawl the solution space or even the problem space so you can design something that fits better.

Sure, it works for mattresses (the Casper mattress case is one of the examples used to show how to interview customers). For some jobs, you probably won't hire anything very different besides a mattress, so it works in that case.

However, if you're creating something radical, you must first understand the jobs or activities that people perform in order to latch onto something in your exploration. "Entertain me" is a job with a million answers and hundreds of nuances. So, unless you get lucky (or convince yourself that your rough idea fits the job you find), you should be ready for a long search.

Conclusion

Jobs-to-be-done is a powerful tool for product practitioners, but it is important to understand its limitations and the effort required to make it work. In most cases, it is not a one-month engagement, and it requires significant resources to trawl the solution and problem spaces in order to design something that fits the job better. Without the right resources and time commitment, JTBD research will not be strong enough to get the desired results.