7

Why is Jobs to Be Done such a confusing framework?

1 month ago from , Designer

What do you think about this framework in general? Would you translate the confusing term "jobs to be done" to "user needs" or to another term?

Have you tried using it in client workshops? How do clients react to this exercise?

I'm dying to find out is this worth implementing in the process.

7 comments

  • Andrew C, 26 days ago

    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.

    8 points
  • Luke Stevens, 26 days ago

    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!

    3 points
  • Seymour Butz, 26 days ago

    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.

    0 points
    • Marina Jukić, 26 days ago

      Maybe I'm thinking about user needs on a higher level than what you've described - these seem more like engineering oriented user stories.

      I found the jobs to be done confusing because of the template I used (or tried to adjust to our needs). This is what I focused on https://i.pinimg.com/originals/a6/b6/75/a6b675a97e7a9a7c59d27d226c2dbb64.jpg

      Do you perhaps have something that works better for you?

      0 points
      • Seymour Butz, 26 days ago

        Nah I only have a cursory understanding. Sounds like Andrew knows more what he's talking about, I'd listen to him :)

        1 point
      • Perttu Talasniemi, 13 days ago

        Yet another canvas.

        0 points
      • Nelson TarucNelson Taruc, 11 days ago

        JTBD doesn't fit neatly into a template or canvas, and is more a framework than a specific workshop activity. If you really want to apply the framework into your design practice, I'd look into the articles/books that Bob Moesta and Ryan Singer have written on the subject. Moesta has shared a number of JTBD interviews online and hearing those may help.

        1 point