Jobs-to-be-done for AI products
Use jobs-to-be-done to frame AI features around the progress users want to make, write job statements, and spot where AI changes the job.
On this page
Why this matters
Nobody wants “an AI feature.” People want to get something done: reply to a customer, understand a contract, catch up on a project. The AI is only valuable to the extent that it helps with that.
Jobs-to-be-done (JTBD) is a way of framing products around that progress. It’s especially useful for AI features, because it forces two questions that are easy to skip: what exactly is the user trying to achieve, and should the AI do it for them or help them do it themselves? The answers shape everything from the UX to the eval set.
What a job is (and isn’t)
A job is the progress someone is trying to make in a particular situation. It isn’t a feature, a task in your product, or a demographic.
- “Use the summary button” is a feature.
- “Managers aged 30 to 45” is a segment.
- “Catch up on a project after a week away, so I can make decisions in Monday’s meeting without looking uninformed” is a job.
Jobs have three dimensions, and AI features often fail by serving only the first:
- Functional: the practical outcome. Know what was decided.
- Emotional: how the person wants to feel. Confident, not anxious, walking into the meeting.
- Social: how they want to be seen. Informed and on top of things in front of their team.
A summary that’s accurate but that the manager can’t trust enough to repeat in the meeting serves the functional job and fails the emotional and social ones. That’s why features like citations matter: they serve the “I need to be confident this is right” part of the job.
Writing job statements
A common job statement format has three parts:
Show text descriptionHide text description
3 parts, in order:
- When: the situation that triggers the job Example: When I come back from a week away…
- I want to: the progress the person is trying to make Example: …I want to understand what changed on my projects…
- So I can: the outcome that makes it worth doing Example: …so I can make decisions on Monday without re-reading every thread.
Some guidance for writing good ones:
- Leave the solution out. “I want to get an AI summary” is a solution in disguise. “I want to understand what changed” leaves room for several solutions.
- Make the situation specific. “When I come back from a week away” is more useful than “when I need information,” because it tells you about urgency, volume and context.
- Use the user’s words. Take phrases from interviews and tickets. If users say “catch up,” don’t write “achieve situational awareness.”
- Write several, then pick. The same feature area usually holds a few different jobs. Write them all, then choose the one with the most evidence behind it.
Where AI changes the job
Once you have a clear job, you can ask how AI could help. There are three broad options, and they lead to very different products.
| Approach | What the AI does | Example | When it fits |
|---|---|---|---|
| Do the whole job | Produces the outcome directly | Automatically files and tags incoming receipts | Low stakes, easy to check, high volume |
| Do part of the job | Drafts, suggests or prepares; the user finishes | Drafts a reply the agent edits and sends | Quality matters and the user knows best |
| Remove the job | Changes the workflow so the job disappears | Status updates generated continuously, so nobody writes them | You control the wider workflow |
In my experience, the most successful first AI features sit in the middle row. Doing part of the job keeps the user in control, tolerates imperfect output, and turns every edit into useful feedback. Doing the whole job is tempting but demands far higher quality, because there’s nobody to catch mistakes.
Competing solutions
Every job already has solutions, even when nobody built a product for it. Users “hire” spreadsheets, templates, colleagues, copy-and-paste, or simply doing nothing and living with the cost.
Listing these competing solutions tells you three things:
- The bar to beat. If a colleague answers the question in 30 seconds, your feature has to be faster, or better in some other way users care about.
- What users value. People who keep a private notes document instead of using your product’s notes feature are telling you something about control or speed.
- The real cost of switching. A new AI feature competes not only on quality but on habit. “It’s slightly better” rarely beats “I already know how to do it.”
For AI features, “doing nothing” is a particularly important competitor. If the job is mildly annoying but rare, the effort of learning and trusting a new AI feature may be greater than the pain it removes.
Common mistakes
- Writing the solution into the job. “I want an AI assistant” isn’t a job. Describe the progress, then explore solutions.
- Ignoring the emotional and social dimensions. An accurate output the user doesn’t trust enough to rely on in front of others hasn’t done the job.
- Defaulting to “do the whole job.” Full automation needs much higher quality than assistance. Start with help unless errors are cheap and obvious.
- Forgetting the competing solutions. Your real competitor is often a spreadsheet, a colleague or doing nothing. Know what you have to beat.
- Writing jobs from imagination. Base job statements on interviews, tickets and observed behavior, in users’ own words.
Try it
Exercise
About 25 min
Write job statements for an AI feature you use
- Pick an AI feature you use regularly.
- Write two or three job statements it could be serving, using the “When… I want to… so I can…” format.
- For each, note the functional, emotional and social dimensions.
- Decide which row of the “where AI changes the job” table the feature sits in, and whether you think that’s the right choice.
Show a hint
Think about the moment just before you reached for the feature. What were you in the middle of, and what were you worried about? That’s usually the situation and the emotional dimension.
Show a worked solution
Example for an email client’s “suggested reply” feature:
- Job: When a customer asks a routine question at the end of my day, I want to send a correct, friendly answer quickly, so I can leave without a backlog.
- Functional: a correct answer sent. Emotional: relief, not worrying about tone. Social: seen as responsive and professional.
- Approach: do part of the job, since it drafts and I send. That’s the right choice: a wrong answer to a customer is costly, and I’m well placed to check it. Moving to fully automatic replies would need much higher, measured accuracy.
Check your understanding
Key takeaways
- A job is the progress someone wants to make in a situation, not a feature or a segment.
- Jobs have functional, emotional and social dimensions; AI features often serve only the first.
- Write jobs as “When… I want to… so I can…”, in users’ words, without the solution.
- Decide whether the AI should do the job or help with it, based on the cost and visibility of errors.
Progress is saved in this browser and lights up the roadmap.
Related articles
- Editable outputs and undo Make AI output editable and reversible with inline editing, accept and reject controls, version history and undo, so users stay in control of the result. Level: Intermediate
- Problem discovery for AI features Find AI feature ideas worth building by starting from frequent, painful user jobs instead of model capabilities, using data you already have. Level: Beginner
- Defining success metrics before you build Choose success metrics for an AI feature before you build it, from task success and adoption to guardrails and cost per success, with code to compute them. Level: Beginner