Jobs to be done framework: how to use it in a PM interview

JTBD is the most reliable signal of PM maturity in a product-sense interview. When a candidate opens with “let me define the job before I suggest anything,” interviewers at Google, Meta, and Anthropic hear a fundamentally different instinct than candidates who open with a feature list. The framework holds that customers do not buy products; they hire them to make progress on a specific problem. Clayton Christensen formalized this at Harvard; the canonical example is McDonald’s milkshakes. Customers were not buying a milkshake out of hunger. They were hiring it for a boring commute: something to hold, sip slowly, and make forty minutes pass. That reframe led to a completely different product direction than a “better milkshake” brief would have.

The three job dimensions

Every complete job statement has three parts. All three matter.

Functional: the concrete task the user is trying to accomplish. “Find music that matches my mood at 6pm on a Friday without effort.”
Emotional: how the user wants to feel while or after using the product. “Feel like someone curated this specifically for me, not an algorithm.”
Social: how the user wants to be perceived by others. “Have something playing when friends arrive that signals my taste without explanation.”

Most candidates describe the functional job correctly and skip the other two. Interviewers notice. The emotional and social dimensions are where differentiation lives; they are also where AI products fail when built from a feature list rather than a job statement.

Job statement syntax

The standard template: “When [situation], I want to [motivation], so I can [outcome].”

A weak job statement: “Users want to discover new music.” This is a feature brief, not a job. It does not name the situation that triggers the need, does not describe the motivation, and cannot be falsified.

A strong job statement: “When I open Spotify on a Friday evening without a playlist in mind, I want the app to read my context and make one strong recommendation, so I can settle into the evening without spending mental energy choosing music.” Now you have an anchor. You can evaluate any proposed solution against it.

The switch interview

Bob Moesta and Chris Spiek developed the switch interview as the primary JTBD research technique. It focuses on the moment a user switched from one solution to another: what was the final trigger, what was the first thought that something was wrong, what did they search for, what almost made them stay? The insight is that stated preferences are unreliable; switching behavior is not.

Ten to fifteen switch interviews typically surface 80% or more of the actionable job landscape. You do not need a large sample because you are not looking for frequencies; you are looking for the causal structure of the decision.

A worked example: “How would you improve Spotify?”

weak

"There are a few things I'd improve about Spotify. First, the social features feel underdeveloped compared to competitors. I'd add a collaborative playlist tool so friends can add to the same queue. Second, the algorithm could be smarter. Third, offline downloads could be easier to manage." Three ideas, no causal logic between them, no success anchor. The candidate is solving from supply, not demand.

strong

"Before I suggest anything, I want to define the job. For the casual user opening Spotify at 6pm on a Friday, the functional job is: find music that matches my current mood without effort. The emotional job is: feel like this was chosen for me, not served by an algorithm. The social job: have something to play when friends arrive that signals my taste. That is a very different job than the gym user at 7am, whose job is: don't make me think, just energize me. I need to pick one cohort and one job before anything else.

For the Friday-evening user, the solution is probably not more features. It's a better entry state: one that reads context (time of day, recent history, location) and makes a single strong recommendation rather than presenting options. In 2026, I'd add a fourth dimension: the delegation job. What does this user want Spotify to own end-to-end so they never think about it again? For this cohort: Friday-evening mode, starting the right music the moment I open the app with no input required. That is where AI anchors. Success metric: does the user skip the first track within five seconds? If skip rate drops at the 6pm session, the job is getting done."

The 2026 reframe: the delegation job

In 2026, feasibility is no longer the constraint. LLMs and agents can implement almost anything a PM specifies. The Venn diagram collapsed. Three job dimensions are no longer enough for AI products.

AI products require a fourth: the delegation job. What does the user want to stop being responsible for entirely? Not “help me do X faster” but “take X off my plate.” The distinction determines scope, acceptable error rate, and trust model. Aisera resolved 86% of IT support requests autonomously at Dartmouth in 2026, saving over $1M per year. That succeeded not because the AI answered tickets faster but because the job was “remove IT tickets from my plate.” Jason Lemkin ran pipeline coverage with 1.2 humans plus 20 AI agents instead of 10 humans. The job was “run pipeline without headcount,” not “faster CRM updates.” Meanwhile, 95% of generative AI pilots failed to deliver measurable returns because teams shipped features against stated preferences rather than addressing the actual delegation job.

The five dimensions for AI product job statements:

Functional: the task
Emotional: how the user wants to feel
Social: how the user wants to be perceived
Delegation scope: what they want to stop being responsible for
Acceptable error rate: how often the AI can be wrong before the user loses trust or reclaims the job

Candidates who name the delegation dimension in an AI product interview at Anthropic, OpenAI, or Perplexity are evaluated measurably more favorably. It signals they understand the 2026 PM shift: the question is not what to build but which problem is real and worth solving at scale.

Where JTBD fits in an interview

JTBD is the right lens for product-sense questions (“improve X,” “design a product for Y”) and strategy questions (“should we enter this market”). It is not the right opening for execution questions (“our DAU dropped 10% last week”), metrics questions, or estimation questions. Opening every answer with job statements regardless of question type signals poor calibration, not PM maturity.

For product-sense questions, JTBD pairs naturally with CIRCLES: use JTBD to do the “Report needs” step precisely, then let CIRCLES carry the rest of the structure. Neither framework replaces the other.

Use it, do not recite it

The failure mode is naming JTBD and then listing features anyway. “Users want to discover new music, so I’d add a collaborative playlist tool” is not JTBD reasoning; it is a feature list with a JTBD label attached. Interviewers catch this. The discipline is to write the job statement first, evaluate every proposed solution against it, and reject solutions that do not address the job even if they sound appealing.

Cordis Corporation grew from 1% to 20% market share by reframing from “better balloon catheters” to “improve procedure success rates.” Microsoft Software Assurance achieved 100% year-over-year revenue growth by reframing from “software updates” to “optimize IT budgets and manage risk.” In both cases the product barely changed; the job framing changed how it was built, sold, and measured. That is the PM judgment JTBD teaches.

The signal to send in an interview: “I start with the job, not the feature list. Once I know what progress the user is trying to make, and what getting done with that job looks like, I can evaluate ideas instead of just generating them.”

For the AI-specific application of JTBD to agent products, see JTBD for agents. For the broader argument about why viable and lovable are now the primary constraints, that page is the companion read.