Summary: The JTBD theory comes from Marketing and applies Business lenses to customer needs and goals. Its focus is on ensuring that design and development are driven by users’ goals, tasks, and context of use. As a result, JTBD can be relevant to UX since Product teams find it easier to embrace.
JTBD: adopt or drop Jobs to be Done?
In our new Reading Circle (Book Club), we read and discussed Jim Kalbach’s The JTBD Playbook. Briefly, the book introduces all the jargon, concepts, and techniques in JTBD theory (user= “job performer,” task= “job,” etc.) and tries to fit it in and around UX methods. The book ends by explaining that the author tried to use the method, even hiring one of its inventors– and failed. The rest of the book is an excited sales pitch for JTBD and tries to replace existing UX techniques and processes with JTBD substitutes. Kalbach failed to map UX methods like Task-oriented Design and Goal-Directed Design to the JTBD framework, which came from Clayton Christenson (Harvard Business professor).
Jared Spool, who called JTBD “an occasionally useful UX gimmick,” mentions the 72 steps required to do JTBD properly.
What’s valuable to notice in JTBD theory?
First of all, if your organization is embracing it as a way to understand how UX thinks about goals, tasks, and sub-tasks- great! UX teams are usually informed from Product Directors that JTBD is the new framework. Thus, it is important to understand from a strengths and limits perspective. Blend JTBD with established UX methods and mindsets if your organization is embracing JTBD.
1. Job Stories are one of the more valuable assets from JTBD, capturing the value of JTBD to organizational stakeholders: context of use, task-centric ways of approaching feature-driven development. Likewise, instead of stating merely what users do, Job Stories frame the context and rationale behind user behaviors:
“When [situation], I want to [motivation], so I can [outcome].” Subsequently the job story format is rooted in specific contexts of use, making it a powerful tool for understanding user needs beyond surface-level interactions.
Furthermore, Job Stories become more valuable than Agile User Stories, often cooked up internally without user research (context research).
2. Integrating JTBD with existing UX techniques provides a comprehensive approach. While JTBD offers a high-level view focusing on the purpose behind product use, task analysis and contextual inquiry give the details and subtleties of user interaction. Together, they enable a holistic understanding of the ‘what’ and the ‘why’ behind product usage.
Our next Reading Circle book is a nice segway into the deeper dive JTBD fails to take. We will read Larry Marine’s Disruptive Research, followed by a visit from the author for a live Q&A. These events are currently free for anyone to join.
Send us a message to be added…(members, pls contact John).
3. For stakeholders, combining these approaches means a shift from feature-centric to goal-oriented product development. Avoid being technology or feature-led and align your efforts around jobs: goals, tasks, and context of use that good UX strategy needs.
Biggest concerns from UXIC members:
- Does JTBD scale to enterprise UX, to B2B, or to situations that are not retail, transactional, or straightforward? (watch the Milkshake case study)
- Does it apply to complex, multi-channel, multi-touchpoint Service Design problems? (it’s incredibly product-centric, yet product-service interactions are default and require a more expansive view)
- Is the JTBD framework a sign of a low UX maturity organization uncomfortable with existing UX methods and mindsets? (for example, if UX isn’t driving JTBD, why is that?)
