JTBD framework: how to apply it

Why JTBD exists at all

Classic scene: a team at Notion or Linear opens the analytics dashboard, sees that 62% of active users are women aged 25-34 in metro areas, ships a feature aimed at that demographic, and watches adoption flatline. The demographic was real, but it was never the cause of the behavior. The real cause is that one of those users opens the app at 7:12 a.m. on a Tuesday because she has a stand-up at 9, three open PRDs, and no idea which one her director will ask about first.

Jobs To Be Done (JTBD) swaps the question "who is the user?" for "what job is the user hiring our product to do?" Clayton Christensen popularized the idea with the milkshake story: McDonald's milkshakes weren't bought because men over 30 love dairy. They were bought because the shake was filling, fit a cup-holder, and lasted a long commute. The job was "make my morning drive less miserable and keep me full until lunch" — and the competitors were a banana, a bagel, and boredom, not Burger King. The practical payoff is that product decisions start from a situation and a desired outcome, not from a demographic or a feature wish-list.

Job-stories: the canonical format

The canonical job-story format was sharpened by the Intercom team:

When [situation],
I want to [motivation],
so I can [expected outcome].

Example:

Three checks every job-story should pass:

• Situation is a concrete trigger, not a wish. "When I want to learn" fails. "When my manager schedules a quarterly review for next Friday" passes.
• Motivation describes what the person does, not which product they open. "I want to drill 20 problems on a specific topic" passes.
• Outcome is the end state, not the feature. "So I can walk into the interview feeling I haven't forgotten the basics" passes.

This single test catches roughly 80% of JTBD documents written in the first three months of any rollout.

JTBD vs personas

Personas read like dating profiles: "Anna, 27, data analyst at a Series B fintech in Berlin, listens to indie podcasts, prefers dark mode." It is hard to make a roadmap decision from that. What do you ship if Anna is in a bad mood?

A job is operational: "When Anna has one week to prep for a senior analyst onsite, she wants a structured review plan so she can show up without panicking the morning of." From that sentence, three product surfaces fall out almost mechanically — a topic graph, a daily plan, and a readiness score.

The two models solve different problems. Use the table below as a quick router when a teammate asks which to reach for.

Mature teams keep both alive. Personas guide empathy, design, and copy. JTBD guides segmentation, metrics, and prioritization. Younger teams should usually start with JTBD because it produces sharper roadmap calls earlier.

How to actually source jobs

You do not write job-stories in a conference room. The default discovery method is the switch interview, formalized by Bob Moesta and the Re-Wired Group. You talk to people who recently switched to your product, or recently away from it, and reconstruct the timeline of that switch through four anchors:

1. First thought. When did you first realize the current setup wasn't going to work?
2. Passive looking. What did you try first? Why did it fall short?
3. Active looking. What was the trigger that made you open a new tab and search?
4. Decision. What changed after the switch? What surprised you?

Six to eight interviews almost always surface two or three repeated jobs. That convergence is the signal to stop interviewing. Support tickets, store reviews, and open-ended churn surveys are useful for confirmation, not first discovery. Likert-scale surveys collapse the situation into a number and rarely produce usable jobs.

Worked example: an interview prep app

Suppose the team is building an interview prep app for analysts and data engineers. After eight switch interviews, three jobs emerge:

1. Cram before a specific interview. When my onsite is in 72 hours and I last wrote SQL six weeks ago, I want to grind targeted problems by topic so I can rebuild reflexes for the questions I expect.
2. Stay sharp between job searches. When I'm employed but not actively looking, I want to spend 10 focused minutes a day so I can keep my skills from rusting and stay ready if a referral lands.
3. Build the skill from scratch. When I'm switching into analytics from another field, I want a two-month program from basics to advanced so I can pass a first screen.

These look similar on the surface. They demand different products underneath.

If the team ships one universal feature trying to serve all three jobs, it serves none of them well. The "cram" user does not want a curriculum; the "from scratch" user does not want random drills; the "stay sharp" user does not want a 90-minute placement test. This is the most common failure mode in early-stage products that pivoted from a single-job MVP into a multi-job platform without admitting it.

Using jobs in metrics and prioritization

Two artifacts should follow stable jobs. The first is a metric tree per job — input, output, and counter metric for each. Reporting overall retention as one blended line hides the fact that the cram cohort churns by design after the interview; that is success, not failure. The second is a prioritization filter: every backlog item gets tagged to one of the documented jobs, and items that map to none face a hard question: why are we doing this?

A practical RICE-style table for one quarter at the example app:

The dark-mode toggle has the biggest reach and cheapest effort, but it serves no job — and that is the entire point. Without JTBD discipline, the toggle ships before the sequenced track every quarter.

Common pitfalls

The most common pitfall is JTBD as a rename of user-stories. A team writes "As a user, I want dark mode so I can use the app at night" and re-labels it "When it's night, I want dark mode so I can use the app comfortably." Nothing changed except the wrapper. A real job is about an outcome that exists independently of your interface — reduce eye strain when working past 11 p.m. on a personal project after a full workday — and a feature is only one of many possible ways to deliver it. The fix is the deletion test from earlier: if the product disappears and the sentence still describes a real human moment, it's a job.

A second trap is jobs written at the wrong altitude. Too high: "I want to be successful." That is a life goal, not a job. Too low: "When I tap the filter button, I want results to update instantly." That is a UI requirement, not a job. The right altitude usually lives at the level where the user could plausibly describe the situation to a friend at dinner without sounding like a robot or a saint. "When my Q2 review is in two weeks and I don't have proof of impact, I want to assemble a one-pager so I can walk in confident" is exactly that altitude.

A third pitfall is insisting on a single job per product. Almost every real product serves between two and four primary jobs. If a team claims one, they usually mean one persona and are still confusing the two frames. If they claim eight, they are mixing jobs with scenarios or with use-cases. The fix is to force-rank by frequency in interview transcripts and keep the top three to four.

A fourth pitfall is doing JTBD without interviews. Some teams write jobs in a workshop from memory and analytics. Analytics show what users do, never why they hired the product in that moment. The "why" sits in the gap between trigger and first action, invisible in dashboards. The fix is non-negotiable: six to eight switch interviews per major hypothesis.

Related reading

• AARRR pirate metrics framework
• A/B testing for product managers
• Guardrail metrics in A/B testing
• Cohort analysis interview questions

If you want to drill PM, SQL, and analytics interview questions daily — across this kind of framework-plus-numbers thinking — NAILDD is launching with 500+ structured problems.

FAQ

How many jobs should one product have?

Two to four primary jobs is typical. One usually means the team has not interviewed enough users or is conflating a persona with a job. More than five usually means the team is confusing jobs with feature-level scenarios. The stress-test: look at the last six months of shipped work and ask whether each item maps cleanly to one of the top three jobs. If half map to "other," your job list is incomplete or prioritization is broken — sometimes both.

Does JTBD replace personas?

No. The two frames answer different questions. Personas are about emotional context, tone, and visual design. Jobs are about functional segmentation, metric trees, and roadmap calls. Mature teams maintain both — onboarding copy and empty-state illustrations live in persona territory; retention reporting and quarterly planning live in JTBD territory.

Can I extract jobs from analytics alone?

Partially. Analytics surfaces behavioral segments, drop-off points, and frequency patterns. What it cannot show is the situation that triggered the user to open your product. The trigger lives in memory and in language — you access it only by talking to people. Use analytics to size jobs; use interviews to discover them.

What is a switch interview, exactly?

A 45-to-60-minute conversation with someone who recently started using your product or recently left it. You walk them backward through the timeline of the switch — first thought, passive looking, active looking, decision, post-switch surprise. The format was popularized by Bob Moesta and produces noticeably sharper jobs than generic user interviews because it anchors every answer to a specific event in the user's life.

Does JTBD work for B2B products?

Yes, with one adjustment: in B2B the job often belongs to a role more than an individual. The job of a head of sales is to close the quarterly number; the job of a RevOps lead is to keep pipeline data trustworthy. Multi-stakeholder buying complicates things — the buyer's job is rarely identical to the end user's — and a clean B2B JTBD doc lists both.

How do I use jobs in quarterly prioritization?

Tag every backlog item with the job it serves. Drop or escalate items that map to no job. Filter your scoring table by job first so you are not comparing a "cram" feature against a "stay sharp" feature head-to-head when both need to ship. The biggest unlock from JTBD prioritization is the permission to deprioritize popular features that serve no documented job — including the dark-mode toggle every PM secretly wants to ship.