Hey Marina — you are not alone. I 100% agree, and haven't found any designer that didn't find the JTBD framework completely confusing. There are two problems with Jobs to be Done that are contributing to this confusion.

1) There are actually two completely different product mantras using the term "Jobs to be Done". The first, and most useful interpretation, comes from Clay Christensen's book "Competing Against Luck". In it he outlines how people hire products to make progress in their lives — often so they don't have to do the job in the first place. I highly recommend that book. It's a pretty great and useful read to help anyone designing and building products and services to focus on serving customer needs.

The second mantra is Tony Ulwick's version, which is essentially arguing for job stories instead of user stories in development (see confusing point #2 below).

Here's a much better explanation than I can give you: https://jtbd.info/know-the-two-very-different-interpretations-of-jobs-to-be-done-5a18b748bd89

2) The second problem is with Tony Ulwick's version of JTBD. To be blunt it's... really not that useful. It misses the point — users often don't want to DO JOBS. They want to solve a problem so they can move on with their life (this is why people hire landscapers and gardeners — they want a beautiful garden but don't necessarily want to learn about botany). Tony Ulwick's version of JTBD does not capture this well.

It reeks of "thought leadership" baloney. Essentially I think he repackaged the standard design language — user-centric design and user stories — in to a lateral system of job stories. Largely who benefits is Tony Ulwick as a thought leader — running workshops and selling programs explaining the system. The big problem is that it risks encouraging product people to miss the point when designing products because jobs are not often the point of good design in the first place.

IMO user stories popularized by Alan Cooper's user-centric design is just a simpler, more focused approach. It helps you advocate for the right things as you discover them through user outreach, testing, and research.

Jobs theory can be confusing for sure -- competing definitions (as Andrew points out), differing areas of application (innovation to marketing to product), and people pontificating about it over the years without really getting to grips with the core concepts.

That said, it's an extremely powerful theory because it gives you a meaningful unit of analysis that consultant/client or whole teams can align around.

One of the best books I've read on JTBD that really captures this point, cuts through the confusion, and makes Jobs theory very practical & tangible actually just came out a few months ago: https://www.amazon.com/Jobs-Be-Done-Playbook-Organization/dp/1933820683

The author is Jim Kalbach, and he's done a few podcast appearances that are worth checking out too: https://uibreakfast.com/181-jobs-to-be-done-with-jim-kalbach/

No connection, just a fan!

What do you think is confusing about it? "Jobs" is meant to encapsulate what a person is trying to accomplish in a given circumstance, in other words, give context to what they are trying to do and why. Whereas writing "user needs" can lead to specs full of things like "User should be able to click on this button to do X. User should be able to filter by Y. User should be able to search by keyword. Etc" that don't capture the why.

I'm not that well versed in JTBD, but in my limited exposure I've found it to be a useful way to think about describing new features compared to more classic user stories.