Jobs-to-Be-Done for AI Products: Building What Users Actually Hire AI To Do

Why JTBD Matters More for AI Than for Traditional Features

Clayton Christensen's Jobs-to-Be-Done theory argues that customers hire products to do a job — to make progress in a specific circumstance. The milkshake example is the canonical illustration: McDonald's discovered that people hired morning milkshakes to make a long, boring commute feel shorter and to stave off hunger until lunch. Not for taste, not for nutrition. The job was "help me get through my commute." Once they understood the job, they could optimize for it.

JTBD applies to all products, but it is especially critical for AI products for three reasons.

AI features are capability demonstrations looking for a job

The typical AI product team starts with a model capability (we can summarize documents, we can generate code, we can classify support tickets) and then asks 'what can we build with this?' This is backwards. Without a job to anchor it, the feature ends up impressive in demos and ignored in production. The capability is not the product. The job it does is the product.

AI output is probabilistic, so the job definition determines acceptable failure modes

A traditional feature either works or it does not. An AI feature works well sometimes, less well other times, and fails in unpredictable ways occasionally. Knowing the job lets you define what 'works well enough' means and what failure modes are unacceptable. If the job is 'give me a starting point for my first draft,' a hallucination is annoying but fixable. If the job is 'confirm this drug interaction is safe,' a hallucination is catastrophic.

AI trust builds differently, and JTBD reveals the threshold

Users hire AI to do jobs at different autonomy levels: assist (show me options), augment (do it and let me edit), automate (do it without showing me). Which level users accept is determined by the job, the stakes, and how much they trust the AI so far. JTBD interviews reveal where users are on this trust spectrum and what would need to be true for them to move to a higher autonomy level.

The Four Forces Applied to AI Adoption

The Four Forces model (developed by Bob Moesta and Chris Spiek, who worked with Christensen) explains why people switch to a new product or feature. Two forces push toward adoption; two pull against it. For AI features, the forces play out in a specific pattern that most teams do not anticipate.

Push: The struggle with the current situation

Direction: toward adoption

This is what makes users open to an AI alternative in the first place. 'This takes me three hours every week and I hate it.' 'I always miss something when I do this manually.' 'The current tool is too slow.' If there is no push, adoption will be low regardless of how good the AI is.

Pull: The appeal of the new solution

Direction: toward adoption

What specifically draws users to the AI feature. 'It would give me a first draft in seconds.' 'It would catch errors I miss.' 'I could do this without being an expert.' The pull must match an actual job, not just be technically impressive. 'It uses GPT-4 under the hood' is not a pull for most users.

Anxiety: Fears about the new solution

Direction: against adoption

This is where AI products are uniquely challenged. 'What if it makes things up?' 'What if I trust it and it is wrong and I get in trouble?' 'What if my boss finds out I used AI?' 'What if it gives away confidential information?' These anxieties are not irrational. They reflect legitimate risks. Your product design must reduce them, not dismiss them.

Habit: Attachment to the current approach

Direction: against adoption

Users have existing workflows that feel safe and familiar. Even when those workflows are painful, they are known. Switching requires learning, behavior change, and accepting uncertainty about whether the new approach will work as promised. AI features that require high behavior change face strong habit resistance, especially in professional contexts where people are accountable for their outputs.

The practical implication: most AI feature launches put too much effort into demonstrating pull (showing off capabilities in demos) and too little into addressing anxiety and habit. The features that drive adoption systematically reduce anxiety (through transparency about what the AI did, confidence scores, easy editing, explicit data handling disclosures) and reduce habit resistance (by inserting the AI into the existing workflow rather than requiring users to adopt a new one).

Conducting JTBD Interviews for AI Products

JTBD interviews are structured differently from standard user research. The goal is not to ask users what features they want. It is to understand a specific decision moment: when did they decide to try the AI, what triggered that decision, what were they hoping for, and what happened next. The interview follows the timeline of that decision.

Phase 1: Find the moment of switch

Example questions

•Can you tell me about the first time you tried [the AI feature]?
•What was happening that day that made you decide to try it?
•Had something changed recently that made you open to trying a different approach?

The trigger for the first attempt reveals the push: what was painful enough about the current situation to make them consider a change. This is the job they were desperate to hire someone to do.

Phase 2: Understand the full context

Example questions

•Walk me through exactly what you were doing right before you used it.
•Who else was involved? What were they doing?
•What would have happened if you had done this the old way?

Context reveals the actual job. The same AI feature might be hired for completely different jobs by different users. A writing assistant might be hired by one user to overcome writer's block (the job is 'help me start') and by another to reduce review cycles with their manager (the job is 'give me something defensible').

Phase 3: Uncover the anxiety and the trust calibration

Example questions

•What were you worried about before you hit send?
•Did you check the output before using it? What were you looking for?
•Has there been a time when you tried it and decided not to use the result? What happened?

This reveals the anxiety forces and the trust threshold. Where users check carefully before using output tells you what acceptable failure modes look like and what verification workflow your product needs to support.

Phase 4: Probe the competing habit

Example questions

•How do you handle this when you don't use the AI?
•Are there situations where you prefer the old approach?
•Has anything made you go back to doing it the old way after trying the AI?

This maps the boundaries of the job. Understanding when users choose NOT to use the AI is as important as understanding when they do. It reveals the current-solution's strengths that you cannot let the AI fall short of.

Learn to Ship AI Features Users Actually Use

The AI PM Masterclass covers discovery frameworks, evaluation design, and product strategy taught live by a Salesforce Sr. Director PM who has shipped AI products at scale.

Writing Job Statements for AI Features

A job statement has a specific format: "When [situation], I want to [motivation/goal], so I can [expected outcome]." The situation grounds the job in context (not all users have this job at all times). The motivation describes the progress they are trying to make. The outcome describes what success looks like for them.

Feature-first framing

Users want an AI that summarizes documents

Job statement

When I receive a 40-page contract before a client call that starts in 20 minutes, I want to quickly understand the three most important terms and any unusual clauses, so I can walk into that call with enough context to represent my client's interests without having done a full review.

Why the job statement is better: The bad version describes a feature. The good version reveals a specific situation (time pressure before a high-stakes meeting), a specific goal (enough context to act, not complete understanding), and a clear success criterion (confident enough to represent my client). These constraints immediately tell you what the AI summary needs to emphasize and how long it should be.

Feature-first framing

Users want an AI writing assistant for emails

Job statement

When I need to deliver difficult feedback to a direct report and I keep second-guessing how to phrase it, I want a first draft that I can edit rather than a blank page that I avoid, so I can send the message today instead of putting it off another week.

Why the job statement is better: The bad version is a product category. The good version reveals the real job: overcoming the avoidance pattern when communication is emotionally charged. It immediately tells you that the AI should produce a complete draft (not suggestions or outlines), that the draft needs to sound editable (not polished), and that the core value is psychological momentum, not writing quality.

Feature-first framing

Users want AI to help with code review

Job statement

When a PR comes in from a junior engineer on my team and I am already behind on my own work, I want to quickly identify the 2-3 changes that will have the most impact on code quality, so I can give useful feedback without spending 45 minutes reading every line.

Why the job statement is better: The bad version is a task. The good version reveals the real constraint (time, competing priorities, the goal of being a good senior engineer despite being busy). This tells you that prioritization is the core job, not completeness of review, and that the AI needs to triage by impact, not enumerate every possible comment.

From Job Statement to AI Feature Spec

A well-formed job statement answers most of the hard questions in a feature spec before you write a single requirement.

What should the AI output look like?

The job statement describes the expected outcome ('so I can...') which defines the form and scope of the output. If the job is 'enough context to act in 20 minutes,' the output is a structured summary with the three most important terms, not an exhaustive analysis.

How accurate does the AI need to be?

The situation and motivation reveal the stakes. For the contract review job, a missed clause before a client call is a real problem. The accuracy requirement is not '95% overall' but 'never misses a clause that could expose my client to liability.' These are very different requirements.

What verification workflow does the feature need?

Anxiety about AI output is highest in high-stakes situations. For the contract review job, the feature should show which clauses it extracted and allow the user to quickly verify by jumping to the source text. For the email draft job, the user needs to be able to edit freely without the AI resisting or rewriting their changes.

Where does the AI feature live in the user's workflow?

The situation describes when the job arises. 'A 40-page contract before a client call' means the feature belongs in the document view, not in a separate AI tab the user has to navigate to. Inserting the AI into the moment the job arises is the single biggest driver of adoption.

What does successful adoption look like in your metrics?

The expected outcome defines success. For the contract review job, success is not 'user opened the AI panel' or even 'user read the summary.' Success is 'user went into the meeting without requesting a postponement.' That may be hard to measure directly, but it focuses you on proxies that actually matter (did the user act after seeing the summary? did they revise it heavily, suggesting it missed what they needed?).

Common JTBD Mistakes in AI Product Development

Mistake: Asking users what they want from AI

Fix: Users cannot design AI features. They can describe their struggles, their workflows, and what progress they are trying to make. 'What AI features would be useful?' gets you a wish list of capabilities, not jobs. 'Tell me about a time this task went badly' gets you a job.

Mistake: Treating all users of a feature as having the same job

Fix: Segmenting by persona (buyer, decision-maker, end user) or by company size misses the point. Segment by job. Two users with identical job titles may hire your AI for completely different jobs with very different quality thresholds and acceptable failure modes.

Mistake: Building for the first moment of use instead of the fifth

Fix: JTBD interviews reveal the first moment of switch. But the AI feature also needs to work for the user who has used it 50 times and has a calibrated sense of where it falls short. Onboarding and first-use design is not enough. Design for the ongoing job.

Mistake: Confusing functional and emotional job dimensions

Fix: Jobs have functional, emotional, and social dimensions. The functional job for the email draft feature is 'write a message.' The emotional job is 'feel like I handled this like a mature professional.' The social job is 'maintain my reputation with my team.' All three influence adoption and need to be addressed in design.

Mistake: Defining the job at the wrong altitude

Fix: Too broad ('help me be more productive') and the job provides no guidance. Too narrow ('summarize this specific document type in exactly this format') and you miss adjacent jobs the same capability could serve. The right altitude is specific enough to guide a design decision and broad enough to reveal multiple possible feature approaches.

Mistake: Skipping the JTBD work because the model is good

Fix: A powerful model with no job to do is a demo, not a product. Model quality is necessary but not sufficient. The teams shipping AI products that drive real engagement and retention are the ones who did the discovery work to find a real job before they wrote a single prompt.

Jobs-to-Be-Done for AI Products: Building What Users Actually Hire AI To Do

Why JTBD Matters More for AI Than for Traditional Features

The Four Forces Applied to AI Adoption

Conducting JTBD Interviews for AI Products

Learn to Ship AI Features Users Actually Use

Writing Job Statements for AI Features

From Job Statement to AI Feature Spec

Common JTBD Mistakes in AI Product Development

Build AI Products That Get Used

Related Articles