When the Customer Is an Agent: Jobs to Be Done
Nov 2026The framework, its two schools, and what I think happens to "hiring a product" when software starts hiring other software.
Why this is on my mind
Jobs to be done keeps getting rediscovered whenever the product landscape shifts. AI is the biggest shift in years, so I wanted to look at what the framework actually claims before I stretch it.
What's true right now
The core claim. JTBD says people don't buy products so much as hire them to make progress in a specific situation. A 2026 explainer frames that progress as functional, emotional, and social, and notes the framework now coexists with personas and ICP work rather than replacing them. Christensen first articulated the hiring idea in a 2005 paper on marketing malpractice, arguing jobs are stable while products are not.
The history is contested. A thorough guide points out that the framework was originated by Tony Ulwick in 1990, and that there are two schools: Christensen and Moesta's jobs-as-progress and Ulwick's jobs-as-activities. Even the famous milkshake story is argued over, with Ulwick contending the better question is what job people are trying to get done when they stop at a quick-service restaurant in the morning, not what job the milkshake does.
The method is interviews. The technique most associated with it is the switch interview or timeline interview, developed by Bob Moesta and Chris Spiek. The practice, as one guide puts it, is pressing people until they reach the real reason behind a purchase. Moesta has discussed common mistakes and when not to use JTBD in a long conversation on Lenny's Podcast.
AI is already entering the research side. A reference page notes AI is increasingly used to mine support tickets, reviews, and transcripts to surface candidate jobs and struggling moments at scale.
Reading a request as a job
Illustrative: my own sketch, not a sourced fact.
Take one request apart. Imagine a customer tells an agent, "Pull together everything I need for the Tuesday meeting." Read it the way a switch interview would. The situation is a meeting coming up. The functional progress is having the right material in one place. The emotional part is not walking in unprepared, and the social part is looking organised in front of other people. I am not claiming the agent will get all of that right. I am saying the lens gives me a checklist for what a good answer should cover beyond the literal words.
Why the lens still helps. The agent only sees the sentence, but the job underneath is bigger than the sentence. A product that understands the emotional and social layers can serve the request better than one that only matches the words. That is the part I would not want to lose when requests become inputs. That is the same habit the interview method trains: keep asking until you reach the reason behind the request, not only the request itself.
My hypothesis
This section is my opinion, not a sourced fact.
As people delegate more to agents, the customer's job statement becomes the literal input to the product, and the real competitor to your product is a well-written instruction.
JTBD has always been a research lens: interview people to find the job. In an agent world, the job is also written down by the customer, in plain language, as a request. "Reorder the thing I always run out of." "Pull together everything I need for the Tuesday meeting." That text is the job spec, and the agent decides which product, if any, to hire for each step.
Two consequences. First, products need to describe the jobs they're good at in language an agent can match, which is a new kind of positioning. Second, the alternative your product competes with is no longer only another product; it's the agent doing the job itself with no product at all.
Where the agent lens could mislead me
My opinion, based on the tradeoffs above.
Requests are not the whole job. People often cannot say what they want in a sentence, which is exactly why interviews exist. If I only cluster written requests, I may mistake the easy-to-type jobs for the important ones. The struggling moment that never turns into a request stays invisible. A good test is whether I can still describe the job without naming any product. If I cannot, I am probably describing a feature and not a job.
The two schools disagree here too. Jobs-as-progress and jobs-as-activities would read the same request differently. One hears a change in someone's life, the other hears a task to complete. I would not pretend an agent resolves that argument. I would pick a school on purpose and say which one I am using. Whichever school I pick, the point is consistency. Mixing the two quietly would make the clusters hard to compare and the conclusions harder to defend.
How I'd test it
Collect 50 real requests customers might give an agent in your category. Cluster them into jobs. See what share of them your product handles end-to-end, partially, or not at all. The "not at all" share is your exposure.
What would change my mind
If people keep preferring to pick products themselves for high-trust or taste-driven purchases, agents will stay at the edges of those categories, and the traditional hire-a-product lens will hold.
How I would explain it to a teammate
Illustrative: my own sketch, not a sourced fact.
Start with the sentence. I would say that customers do not want our product, they want progress, and from now on they may type that progress as an instruction. Then I would show one real request and ask the team to name the job, the situation and the alternative together, out loud, before anyone mentions a feature. I would keep it to one example and one sentence of theory. The framework sticks better when people see it work on something familiar than when they hear its history.
End with the uncomfortable question. If an agent did this job with no product at all, how would the customer notice the difference? If the honest answer is that they would not, that is useful. It tells us where our product is hired for a reason and where it is only hired out of habit. It is a question about value, asked honestly, and it works just as well in a research session as in a roadmap meeting.
References
- Launchrock, Jobs To Be Done
- Agile Brand Guide, Jobs to Be Done (JTBD)
- Koji, Jobs to Be Done Framework: The Complete Guide
- CustomerThink, Marketing, Milkshakes and Innovation
- Dovetail, Jobs to be done
- Lenny's Newsletter, The ultimate guide to JTBD with Bob Moesta