Summary: Frank Spillers discusses Jobs-to-be-Done (JTBD) theory vs traditional User Experience (UX) techniques and approaches and contrasts the two. Understanding how each method contributes to product success can guide stakeholders in making more user-centric decisions.
JTBD: a technique your team should adopt?
Jobs-to-be-Done (JTBD) theory and traditional User Experience (UX) techniques like task analysis and contextual inquiry represent distinct approaches to design and development. Understanding how each method contributes to product success can guide stakeholders in making more user-centric decisions.
JTBD focuses on the core principle that customers “hire” or “fire” products to perform specific jobs. This metaphor aims to shift the focus from product features to the underlying customer needs. However, the “hire or fire a product” jargon can sometimes obscure more than it clarifies. JTBD introduces a lot of new jargon. For example, users are “job performers.” Much of this is baggage that doesn’t help. Jargon and re-inventing terms is bad enough already in the UX field. 😉
What’s worth noticing in JTBD theory?
- Job Stories, an offshoot from user stories in Agile development, provide a practical application of JTBD in UX design. 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].” This format is rooted in specific situations, making it a powerful tool for understanding user needs beyond surface-level interactions.
- Integrating JTBD with traditional 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.
- For stakeholders, combining these approaches means a shift from feature-centric to goal-oriented product development. Instead of being swayed by feature requests or technological trends, teams can align their efforts with the actual jobs that users need to complete. This alignment enhances product relevance and user satisfaction.
Transcript
“Jobs to be Done (JTBD) keep or drop?
Now, the chief product officer of PayPal recently shared that she tried personas, and they didn’t work; instead, jobs to be done worked better for them. And in a tongue-in-cheek post, she shared how they had personas like life-size cutout figures, uh, that only worked for them as coat racks, and there were a bunch of coats on these cut cardboard cutouts.
Now PayPal’s ux team is very thin, and that may account for bad personas. And personas are notorious for mixed results if you use them wrong and I couldn’t help but noticing the cutouts were blank-faced– there was like nothing on them no data no actual customer data. Maybe???
The same day I talked to a colleague and I was like “How’s your job going?”…I hadn’t spoken to her in a while… and she’s like “Well jobs to be done is the new focus from a new VP”… and I was like “Well you better add jobs to be done to your list of JTBD”…
JTBD is just a way to get stakeholders to focus on user goals and purpose. But first all the corny language isn’t helpful— in any ux work– so drop that!
- “Job performer” is a user
- “Job” is a task
- “Social job” or “emotional job”: those are just influencing phenomena.
- A “big job” is a goal
- A “little job” is a task
- A “micro job” is a subtask
Like we have the language already.
“Users hire or fire a product?” for defection or switching… a lot of new jargon doesn’t help.
Why this matters
JTBD is catching on with stakeholders, and that’s fine. Use it- don’t fight it- but be clear about how similar it is to ux methodology, which grew out of usability engineering and human-centered design. JTBD grew out of Marketing Theory at Harvard in 2003.
As Jared Spool said: “JTBD is an occasionally useful UX gimmick”
He noted that it came out of task analysis. It’s like watered-down task analysis from ux many decades ago.
If you’re embracing jobs to be done and your organization is all excited, fine, just understand and adapt, and realize its value is task-centric and context of use two very powerful ideas for stakeholders to understand.
See 5 Task-Centered UX Design Patterns Competitors are Using to Get Ahead
The place to start is job stories. Now, job stories are better than user stories, which are an agile artifact, and they’re better than use cases, which user stories replaced, so use cases kind of describe what the system’s going to do. User stories describe, uh, what the user wants to do… You know “As a user, I want to…” and job stories add a little bit more.
So Paul Adams is Intercom’s Product Manager (Intercom is that Chat thing that pops up in the corner of your…) uh; he was also like a UX Director and Head of Brand Insights at Facebook and Google. He said we frame every problem in a job focus based on the triggering event or situation… the motivation, the goal, and the intended outcome.
That’s why job stories are important. “When I’m running around, I want to find something to eat so I can satiate my hunger,” or something like that. And that framework, a little bit like that Agile story, adds a little bit more through this job story and can be a very powerful way to bring that task focus and that context of use view.
Now, Bob Moesta, who’s a creator of JTBD, and Clayton Christensen, the Harvard Professor who kicked this all off, said, “If you can’t believe a user story, nine times out of 10 you don’t have the rest of the context that you need to understand it.” So context of use is hugely important.
Harvard Business Schools suggests that 25 to 30% of organizations use JTBD—if that’s you—merge jobs to be done with task—and goal-oriented design—the stuff that’s already in the UX field.
Job stories provide context of use insights which are one of the most important things in UX.
See Understanding Context of Use- possibly the most important thing you do in UX
Also, to get well-defined job stories and context to use, you’ll need user research, field studies, and some task analysis to dig deeper where jobs to be done tend to just skim the surface.
Thank you so much, and see you soon!”
