The Problem: Feature-First Agent Design
Most agent projects start with the technology. A team picks a framework, chooses a model, wires up tools, and builds capabilities — then goes looking for users who might want them. This is the same pattern that has produced a 95% failure rate for new products across industries for decades. [1]
The pattern repeats in agentic AI. McKinsey's 2025 report on agentic AI found that nearly eight in ten companies have deployed generative AI in some form, but roughly the same percentage report no material impact on earnings. About 90% of transformative use cases remain stuck in pilot mode. [2]
The problem is not the technology. It is the starting point. Teams build agents around what models can do rather than around what users need done.
What Jobs To Be Done Actually Means
Jobs To Be Done (JTBD) is a framework developed by Clayton Christensen at Harvard Business School. The core idea: people don't buy products — they hire them to get a job done. [3]
The canonical example is Christensen's milkshake study for McDonald's. The company wanted to sell more milkshakes. They surveyed customers, improved the recipe, and changed nothing about sales. Christensen's team took a different approach — they stood in the parking lot at 7am and watched. Half the milkshakes sold before 8am, almost always to solo drivers on their way to work. [4]
Those customers weren't buying a milkshake. They were hiring something to make a boring commute less tedious, keep them occupied for twenty minutes, and not leave crumbs on their suit. The real competitors weren't other milkshakes — they were bananas, bagels, and boredom.
The insight changed the product direction entirely. Make the shake thicker so it lasts longer. Add fruit chunks for variety. Move the dispenser in front of the counter for faster purchase. This is what JTBD does: it shifts the question from "how do we improve this product?" to "what job is the customer hiring this product to do?"
The Three Dimensions of Every Job
JTBD identifies three dimensions to every job people need done:
Functional: What task needs to be completed? This is the practical outcome — deploy infrastructure, review a pull request, generate a report. It's the dimension that engineers default to, and the one that is necessary but rarely sufficient.
Emotional: What feelings drive or result from this job? Trust, confidence, relief, control. A developer who uses a coding agent needs to trust that it won't introduce security vulnerabilities. A manager who deploys an autonomous workflow needs confidence that it will handle edge cases. These emotional needs often determine whether a technically capable agent actually gets adopted.
Social: How does this job affect collaboration, status, or relationships? An agent that generates code the team can review and understand builds the developer's credibility. An agent that produces opaque outputs that nobody can explain undermines it.
Tony Ulwick, who formalized JTBD into the Outcome-Driven Innovation methodology, puts it directly: if you want to predict whether an innovation will succeed, measure how well it satisfies the outcomes customers are trying to achieve — not how many features it has. [5]
Applying JTBD to Agent Design
The framework translates directly to agentic application planning. Instead of starting with "what can this model do?" start with "what job does the user need done?"
Map the job, not the feature set. Talk to users. Find the painful, recurring jobs where current solutions fail. Look for tasks that are repetitive, time-consuming, or error-prone. Ask: "What's a real job users struggle to get done that an agent could fully own?"
Define success as outcomes, not outputs. Completion rate. Time-to-completion versus human baseline. Error rate reduction. User satisfaction. Cost savings. These are measurable outcomes that tell you whether the agent is doing the job, not just running.
Design modular agent roles around the job. Break jobs into agent roles: a Planner that understands context and creates strategy, an Executor that performs the core task, a Reviewer that validates results, a Connector that integrates with external systems. Each role maps to a part of the job, not a technical capability.
This connects directly to how tool definitions work in practice. When you define a tool for an agent, you are describing a capability the agent can hire to get part of a job done — the same JTBD logic, applied at the system level. Our article on how tools work with AI models covers the mechanics of that interface.
Start simple, layer progressively. Begin with structured interaction — form-based or button-triggered agents focused on a single, well-defined job. Validate core functionality before adding conversational layers or multi-agent coordination. This mirrors the advice in our guide to getting started with agentic coding: start small and reversible, graduate to complexity.
The Forces of Progress
Bob Moesta, who co-developed JTBD with Christensen, identified four forces that determine whether someone will switch from their current solution to a new one: [6]
Push: Frustration with the current situation. Manual deployments breaking. Code reviews taking three days. Reports requiring four spreadsheets and a prayer.
Pull: Attraction to the new solution. An agent that deploys in minutes. Review turnaround in hours. Reports generated on demand.
Anxiety of the new: Concerns about switching. Will the agent introduce bugs? Can I trust its outputs? Will I lose control over my workflow?
Habit of the present: Behaviors that are hard to stop. The team already has a deployment script. The review process "works." The spreadsheet is familiar.
For an agent to get hired, push and pull must outweigh anxiety and habit. This is why technically capable agents still fail to get adopted — they generate enough pull but do nothing about anxiety. Building trust, transparency, and user control is not a nice-to-have. It is a requirement for the switch to happen.
From Task Automation to Strategic Partner
JTBD also provides a maturity model for agent systems, based on how much of the job the agent can own:
Level 1 — Task Automation. Single, well-defined job. Structured input and output. Human triggers execution and validates results. This is where most agents should start and where many should stay.
Level 2 — Semi-Autonomous. Handles variations in input. Self-validates with confidence scoring. Conversational refinement. Human oversight for edge cases.
Level 3 — Fully Autonomous. Proactive job initiation. Multi-step workflows. Self-correction. Human exception handling only.
Level 4 — Strategic Partner. Multi-agent coordination. Context-aware decision making. Continuous improvement loops. Predictive and preventive actions.
The mistake is jumping to Level 3 or 4 without proving the job at Level 1. Each level adds complexity — and each level requires that the previous level's job is well-defined, measurable, and reliably done.
Where This Leads
The Jobs To Be Done framework is not a product management trend. It is a discipline for asking the right question before building the wrong thing. Clayton Christensen spent decades demonstrating that companies fail not because they lack capability, but because they build capability for jobs that don't exist. [3]
Agentic AI amplifies this risk. Models are capable enough to build almost anything. The constraint is no longer "can we build it?" — it is "should we build it, and for what job?"
Start with the job. Map the three dimensions. Define success as outcomes. Design agents around roles, not features. Build trust to overcome anxiety. Layer complexity only after the core job is proven. The agents will get more capable. The framework for deciding what they should do is the part that requires human judgment.