Jobs-to-be-done, in simple words

The number of books and articles on Jobs-to-be-done (JTBD) is growing.

For every article about the theory, there seems to be one about the practice. Getting the essence of JTBD can be challenging for those approaching it for the first time.

This framework, in fact, spans multiple domains. User Research, Product Management, and Marketing, for starters.

Someone might feel lost among all the articles and books. For them, it’s good to know that the idea behind JTBD itself is quite simple.

Jobs-to-be-done requires putting oneself in the shoes of a detective. We need to reconstruct the story of someone buying a product.

“When did you first realize you needed this product?”, “What were you trying to accomplish?”, “How did it go?”, “Why did you choose it?”, “What were you trying to achieve by making that choice?”.

Specific forces attract us towards a new solution, while others discourage change. At this point, we have discussed, in simple terms, the concepts of Timeline and Four Forces. These are key points of the Jobs-to-be-done theory.

Also, we must not forget that JTBD cannot exist without users. Let’s say a designer or product manager starts a new project. She is eager to practice JTBD and engage in a theoretical exercise by asking herself, “What is the user’s Job?” here and there.

If that is all, it is not JTBD.

Why? Because she is not talking to anyone. JTBD speaks of real stories. The design process can start with good hypotheses about the problems to solve. But Jobs-to-be-done is all about real-world experience.

This idea becomes very clear when after reflecting on the early success cases. I discovered JTBD several years ago through Intercom blog. Intercom applied the process to its existing customers. Basecamp did it as well.

JTBD involves interviewing real customers who choose your product. Or customers of competitors. Or, more generally, someone who has the problem we want to solve.

JTBD cannot exist “in theory.”

There is a third situation: let’s say we are creating something that meets our own needs.

In this case, Jobs-to-be-done can help guide research and development work.

That’s what we did with Hellotime, a tool we created to manage people’s time on projects. We focused on the problem to solve and the goal (the progress, in JTBD jargon). We time-travelled several years ago to a time when we lacked resource planning at Moze. During this exercise, we tried to explain with words the problem (before) and the goal (after).

1) Before – what is the starting situation? We have too many projects at once. We don’t know when we’ll finish them, and we don’t know when we can take on new ones and get paid.

2) After – what has changed now? Projects get done on time and on budget. Everyone is happy, and the cash flow is good.

This approach doesn’t mention the product or its features. If so, it becomes easier to conduct research and product development activities. That starts by verifying that our solution sits well between the problem and the goal we defined.

In this article, we have clarified the essence of JTBD. In a very simple way, of course. But it works, and anyone can give it a try.

A few notes:

• If you’re ready to know more about JTBD, read this: Practical guide to Jobs-to-be-done.

• Since JTBD has different interpretations, in this article I used the one popularized by Clayton Christensen, Bob Moesta, Intercom etc. See “Jobs-As-Progress”, Know the Two — Very — Different Interpretations of Jobs to be Done | by Alan Klement.
• We learned JTBD thanks to live training sessions from Jillian Wells (ex-Intercom, now Stripe).
• We have also written an e-book on JTBD, you can download it for free if you want to learn more.