All articles Build the Right Thing

The Jobs-to-be-Done Framework: A Practical Introduction

By the FabricLoop Team  ·  May 2026  ·  6 min read

Clayton Christensen used to tell a story about a fast food company that wanted to sell more milkshakes. They interviewed customers about flavour preferences, sweetness levels, and cup size. Nothing they changed moved sales. Then a researcher tried a different approach: he stood in a car park and watched people buy milkshakes. He asked one question — "what were you trying to do when you decided to get a milkshake this morning?"

The answer: most morning milkshake buyers had a long, boring commute ahead of them. They wanted something that would keep them occupied and not leave them hungry before lunch. The milkshake did that better than a banana (too fast), a bagel (too messy), or a coffee (too small). The product they were competing with wasn't other milkshakes — it was boredom and hunger.

That story is the essence of Jobs-to-be-Done. People don't buy products. They hire them to do a job in their life.

What a "job" actually means

In JTBD terminology, a "job" is the progress a person is trying to make in a particular circumstance. It's not a task ("I need to send a file"). It's not a goal ("I want to be more productive"). It's the specific progress a specific person is trying to make in a specific situation — with all the context, constraints, and emotions that surround that moment.

The job has three components: a situation (the trigger that creates the need), a motivation (what the person is trying to achieve), and an outcome (the definition of success from their perspective). All three matter. A product that nails motivation but ignores situation will be used at the wrong moments. A product that nails situation but ignores outcome will get hired and quickly fired.

"People don't want a quarter-inch drill. They want a quarter-inch hole. But what they really want is a shelf on the wall — and what they truly want is for their partner to think they're competent."

The JTBD statement format

Writing formal JTBD statements forces clarity about what job your product is actually being hired to do — and reveals gaps between what you think the job is and what users actually experience.

JTBD statement template + examples
"When I situation, I want to motivation, so I can outcome."
Example 1 — Project management tool
"When I take over a project mid-way from a colleague who's left, I want to understand what's been decided and why, so I can get up to speed without scheduling six catch-up calls."
Example 2 — Communication tool
"When I need a quick answer from someone who's in meetings all day, I want to send a message that signals urgency without being rude, so I can unblock myself without damaging the relationship."
Example 3 — Analytics tool
"When I present to the board next week, I want to show retention trends in a way that tells a clear story, so I can demonstrate progress and maintain confidence in the team."

Notice how each statement reveals something a feature list never would: the emotional stakes, the context of competing forces, and the definition of success from the user's perspective. None of these would surface in a survey asking "what features do you want?"

Functional, social, and emotional dimensions

Every job has three dimensions, and products that only address the functional one leave real value on the table.

Slack didn't grow because it was better than email at sending messages (functional). It grew because it made teams feel more connected and alive (emotional) and made individuals feel like they were part of a real-time conversation rather than an inbox queue (social). Features that address only the functional job are easily commoditised. Products that address all three dimensions are much harder to replace.

Interview technique To uncover emotional and social dimensions, listen for language about other people. "I needed to show my manager that...", "I didn't want the client to think...", "I was worried the team would assume..." — these phrases signal that social and emotional jobs are in play.

How to discover the jobs your product is hired for

The best JTBD research focuses on the moment of hiring — the decision to start using a product — and the moment of firing — the decision to stop. Both moments are rich with signal.

For the hiring interview, ask: "Think back to the last time you decided to use [product]. What was going on? What were you trying to accomplish? What else did you try first?" For the firing interview: "When did you stop using [product]? What were you doing right before you decided to switch? What did the alternative do differently?"

The answers will almost always surprise you. Users will describe situations, frustrations, and motivations that your team never anticipated. That's the point. JTBD research is not validation research — it's discovery research. You're not testing your assumptions; you're replacing them with evidence.

The demographic trap JTBD deliberately moves away from demographic personas ("35-year-old marketing manager") toward situational ones. Two people with identical demographics can have completely different jobs. Two people with nothing in common demographically can be hiring your product for exactly the same job. Segment by job, not by age or role.

Using JTBD to make product decisions

Once you've identified the primary jobs your product is hired to do, use them as a filter for every significant product decision. For any proposed feature, ask: which specific job does this help users make progress on? If the answer is "none of our primary jobs," that's a strong signal to deprioritise — even if the feature sounds appealing.

JTBD also reveals where you're over-serving. If users have a job that's already being done well enough, adding more features to that area provides diminishing returns — and potentially adds complexity that makes the product harder to use for users with different jobs. The jobs lens shows you where to invest and where to stop.

How FabricLoop connects to JTBD FabricLoop is hired for a specific job: keeping teams coordinated without forcing everyone into the same communication style. That job has functional, social, and emotional dimensions — and understanding them shaped every product decision. We use JTBD statements internally when evaluating new features, and we make the underlying research visible to the whole team.

10 things to take away from this article

  1. People don't buy products — they hire them to make progress in a specific situation. The job is always bigger than the task.
  2. A job has three components: situation (the trigger), motivation (what they're trying to achieve), and outcome (their definition of success).
  3. The JTBD statement format — "When I [situation], I want to [motivation], so I can [outcome]" — forces clarity that feature lists never produce.
  4. Every job has functional, social, and emotional dimensions. Products that only address the functional dimension are easily commoditised.
  5. Listen for language about other people in interviews — it signals social and emotional jobs that are often more important than functional ones.
  6. The best JTBD research focuses on the moment of hiring (why did you start?) and the moment of firing (why did you stop?).
  7. JTBD research is discovery research, not validation. You're replacing assumptions with evidence, not confirming what you already think.
  8. Segment users by the job they're trying to do, not by demographics. Two people with nothing in common can have the same job.
  9. Use identified jobs as a filter for feature decisions: if a feature doesn't help users make progress on a primary job, deprioritise it.
  10. JTBD also reveals where you're over-serving — areas where adding more features provides diminishing returns or increases complexity.