VIDEO: JTBD- keep or drop?

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 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.
Job Stories template via gamethinking.io
  • 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 goals, tasks and context of use that good UX strategy needs.

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!”

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.

Search

Search

Tags

No Tags associated with this Post

Recent Posts

Scroll to top

Get a quote or discuss your project

Tell us about your project

Arrange a 30 min call

Project in mind?

logoblack

Fight for the rights of your users. We'll show you how.

Read more articles like this for exclusive insights into the best ways to approach UX and Service Design challenges. Find out when events occur first. Privacy protected, no exceptions.

Subscribing indicates your consent to our Privacy Policy

Should we add you to our email list?

Privacy protected-You can unsubscribe at any time.

Download the Better UX kit