JTBD for AI agents: five dimensions every agent PM needs

Classic JTBD breaks for agent products because the framework was designed for tools that humans operate. The job is to hire something that helps you do the work. With agents, the user is not doing the work at all: the agent is. That one shift cascades into five product design dimensions that have no equivalent in standard JTBD. Candidates who apply three-dimensional JTBD (functional, emotional, social) to an agent question will land on “make the user faster,” which is the wrong answer when the product can take the job over entirely.

Why classic JTBD breaks

Christensen’s original insight was that customers hire products to make progress. The switch interview captures the moment a user moved from one solution to another. The “forces” model, push from the current situation, pull of the new solution, anxiety about switching, habit attachment to the old way, assumes the user remains in the loop throughout: evaluating, adjusting, deciding. Agents break that assumption entirely.

When an agent executes autonomously across a multi-step task, the user is not hiring a better tool. They are delegating a job category. The hire/fire decision is not about feature fit; it is about whether the agent earns enough trust to keep the delegation. 85% of enterprises were running AI agents in early 2026, but only 5% trusted them enough to ship (VentureBeat). That 80-point gap is not a technology gap. It is a product design gap, and it lives in the five dimensions below.

The five dimensions

1. Delegation scope

The first question is not “what does the user want to do?” but “what is the user willing to stop doing entirely?” These are not the same. A user might want faster contract review (tool thinking) or they might want contracts to never land on their desk again (delegation thinking). The viable product design is completely different depending on which job is real.

In practice: ask what the user would stop monitoring if the agent performed perfectly for 30 days. Whatever they name is the real delegation scope. Whatever they say they would still check is outside it. Developers in 2026 use AI in roughly 60% of their work but can fully delegate only 0 to 20% of tasks. Once a task becomes design-heavy or ambiguous, it gets pulled back. Mapping that line is a product decision, not an engineering default.

2. Trust trajectory

Agents do not earn trust on day one. They earn scope incrementally through demonstrated performance on lower-stakes tasks. Jason Lemkin described this directly: “The agent earns trust through insane value. The customer starts giving it harder tasks because it’s proven it can handle the easy ones.”

The product design implication: your MVP must prove a narrow proof point that opens the next delegation level. What is the simplest task where the agent can operate autonomously, succeed reliably, and be visible enough that the user registers the win? That is the trust ramp, and it is a product arc that must be designed intentionally. It is not a side effect of good engineering.

Three control modes frame how trust is structured as a product decision: Human-Led (agent drafts, human approves every action), Assist Mode (agent acts, but human reviews before any external effect), Autonomous Delegate (agent acts within a defined scope and escalates outside it). Choosing the mode for a given task is a PM call, and it changes everything downstream in the UX.

3. Acceptable error rate by consequence level

A scheduling conflict the agent creates is recoverable in minutes. A contract the agent signs incorrectly may not be recoverable at all. These require different product designs, different escalation logic, and different success metrics, yet both are just “errors.”

The PM’s job is to segment the task surface by consequence level before any design decision. Low consequence, high frequency: the agent can be wrong occasionally as long as the overall rate stays below the threshold at which users take the job back. High consequence, low frequency: the agent must escalate before acting, not after. Setting acceptable error rates by consequence class is a product decision that should appear explicitly in a PRD, not be discovered post-incident. Leaving it implicit is one of the most common ways agent products get pulled back from production.

4. Workflow compression

Workflow acceleration and workflow compression are different products with different strategies, different target users, and different competitive moats. Acceleration makes a job faster while keeping the user responsible for it. Compression eliminates the job category from the user’s responsibility entirely.

A legal agent that reviews NDAs 50% faster is an acceleration product: the paralegal still owns NDA review. A legal agent that handles all standard NDA review end-to-end removes that job from the paralegal’s plate. When compression is the actual job, designing for acceleration misses the market entirely. The discovery question is: “If this agent worked perfectly, would you still think about this problem?” Yes means acceleration. No means compression, and the product design question is which edge cases route back to a human and which ones the agent can own.

5. Operating boundaries

What systems can the agent touch, what data can it read, and what actions can it take without explicit approval? These are not engineering or security questions. They are product decisions the PM must define and own, because the answer determines both what the agent can accomplish and where it will fail in ways that erode user trust.

Scope boundary failures (agents touching unintended files, refactoring unrelated functions) and multi-session prompt injection attacks across production deployments were documented in early 2026, most of them caused by operating boundaries that defaulted to whatever engineering shipped rather than what the PM defined. The zero-trust principle for agent products: every agent should operate with time-limited, minimally scoped credentials tied to verifiable identity and runtime intent checks. The policy-first guardrail pattern separates the rules from the enforcement mechanism and must be defined before scope expands, not after the first incident.

How to use this in an interview

The strong answer to “how would you think about user needs for this agent?” extends JTBD across all five dimensions with a concrete example, not as a sequential list recitation.

The 2026 reframe

In 2026, feasibility is effectively free. The PM’s question is no longer “can we build this?” It is: what job is the user actually willing to fully delegate, at what error rate, and what does trust-earning look like as a product arc? Viable means the delegation scope is real and the market large enough to sustain it. Lovable means the agent meets users where they are: earns scope incrementally, escalates gracefully, and compresses workflow rather than just accelerating it.

Feature thinking collapses because agents do not add capabilities to a tool the user still operates. They take over a job. The five dimensions are the new unit of product design for agent products.

Do not recite the list

The five dimensions are a thinking scaffold, not a checklist. Use them to sharpen a specific product decision: “the reason I’m asking about error tolerance before we scope this feature is that the acceptable rate depends on whether the action is reversible.” That precision is what signals PM maturity. Listing all five in order without anchoring them to a real design choice signals that you learned a framework, not how to think with it.

For the underlying JTBD foundation these five dimensions extend, see Jobs to be done. For interview questions that test this directly, design agent guardrails and safeguards for agentic AI are the closest practice cases. For the cheat-sheet version of operating boundaries, see the agent guardrails cheat sheet.