Jobs to be done
State the progress a customer is hiring a feature to make, put a number on each of the four forces, and derive the error rate the feature must beat.
On this page
Nobody hires a drafting tool to use AI. A support lead with 14 agents hires it so the queue is empty at 6 pm, and a feature that does not move that number is a feature she stops paying for. Jobs to be done (Christensen, Hall, Dillon and Duncan, Competing Against Luck) is the discipline of writing down the progress the customer is trying to make, with the numbers that say whether it was made, before anyone names a solution.
The job, not the persona
A persona says who: "Priya, 38, support lead, comfortable with tools, values efficiency." It says nothing about what she would pay to change, so a team can build for Priya for a year and never touch the thing she measures. A job says what progress she is trying to make, in a situation, with an outcome she can count:
When the queue still holds 130 tickets at 4 pm, help me clear it before 6, so that nothing is carried overnight and tomorrow does not start behind.
Three parts: the situation (130 at 4 pm), the progress (clear it before 6), the outcome (nothing carried overnight). The test of a job statement is whether the outcome can be counted. "Feel more in control" cannot. "Tickets carried overnight: 130 today, under 20 by quarter end" can, and it becomes the root of the opportunity solution tree next lesson.
Two people with the same job buy the same thing; one person with two jobs buys two things. The same lead at 9 am has a different job — route the 130 overnight tickets to the right agents — and a drafting tool does nothing for it. The feature serves a job, not a person.
The worked job: 14 agents, 40 tickets, 6 pm
The team handles 14 × 40 = 560 tickets a day. A reply takes an agent about 3 minutes: read the ticket, find the macro among 200, edit it, send. At 4 pm the queue holds 130 tickets, and those are the ones carried overnight. Replies are not the whole shift: 40 replies at 3 minutes are two hours of an agent's day, and calls, escalations and admin fill the rest, so the reply time is spent by 4 pm and the 130 wait.
A tool that drafts the reply from the ticket and the nearest macro takes the reply from 3 minutes to 2. One minute on each of 560 replies returns 560 agent-minutes a day, about 9.3 hours. At 2 minutes a reply, 9.3 hours is roughly 280 extra replies of capacity, against a backlog of 130. If the minute is real, the freed capacity is more than twice the backlog, so the queue clears before 6 with margin to spare.
That chain is the whole argument for the feature, and every link is a number: the hire is "clear by 6", the mechanism is "one minute per reply", the test is "time 60 replies with the draft and without". A reader who writes the chain down can see which link is assumed, and that one is the minute.
Writing the job first also clears ideas off the product backlog. A chat assistant the agent asks questions adds a step to a 3-minute reply; it moves the number the wrong way. A reply-quality scorer moves none of the 130. Neither is wrong as software; both are wrong for this job.
The four forces, each with a number
A customer switches when the push of the present situation and the pull of the new solution together outweigh the anxiety about the new and the habit of the present. The frame comes from Bob Moesta's switch interviews, and its value is that each force takes a number.
Push. 130 tickets carried overnight, every working day. Each one is a customer who waits 16 more hours and a morning that starts behind. The push is what the lead already feels; the interview's job is to count it, and the count is on the queue page.
Pull. 9 agent-hours a day returned, which is the queue at zero at 6 pm. At an assumed loaded cost of $30 an agent-hour (USD throughout the course; convert at your own rate), that is about $270 a day, or about $5,900 a month across 22 working days — the number the lead takes to her budget owner.
Anxiety. A wrong reply that reaches the customer is not free: the agent re-reads it, apologises, and a second person reviews, about 20 minutes of escalation per wrong reply sent. 560 minutes saved ÷ 20 minutes per wrong reply = 28, so more than 27 wrong replies sent a day eats the whole saving. 27 of 560 is just under 5%: the rate of wrong replies sent has a threshold. A wrong draft the agent catches costs about 20 seconds, not 20 minutes, so the threshold applies to what slips past the agent, and the eval in evals as the feature's test suite has to show a drafted error rate that keeps it there before the pull is real.
Habit. The agents know 200 macros by shortcut. The switching cost is a new motion and a new reason to distrust the old one. A tool that replaces the macros fights the habit; a tool that drafts from the macro the agent already picked rides it. Same model, different force.
The decision rule is then arithmetic, not sentiment. Push and pull: 130 tickets a day and 9 hours a day. Anxiety and habit: a 5% ceiling on wrong replies sent and 200 learned shortcuts. The feature wins if the rate of wrong replies sent sits under the ceiling and the first version keeps the macros in the loop. It loses, at this tenant, the day that rate crosses 5%, whatever the demo looked like.
From the job to the spec
The job statement hands the spec three things. The outcome metric: tickets carried overnight, 130 to under 20. The input metrics the team can move this week: minutes per reply and the rate of wrong replies sent, with 5% as a guardrail rather than a target (how inputs multiply into an outcome is North Star, input and output metrics). And the interview question that finds the job in the first place: not "would you use a drafting tool" but "tell me about the last time the queue was still full at 6", the story-based form in continuous interviewing.
Before the fix, the backlog item read "Agents want an AI assistant". After it, the item reads "Clear the 4 pm queue by 6: one minute per reply, under 5% wrong sent, macros kept." The first can be built in a hundred ways and judged in none. The second can be tested in an afternoon with three agents and a stopwatch, which is the one-day prototype.
In an interview
What is being tested is whether you can state a job with a count, derive the number the solution has to hit, and name the force that kills it. Say it in that order: "The hire is clearing the queue by 6. The mechanism is one minute per reply, 560 minutes a day. The kill condition is more than 27 wrong replies sent a day, so what gets past the agents has to stay under 5% before the saving exists." An interviewer hearing a threshold they did not ask for knows you have done this before.
The mistake that loses points is describing the customer — a persona with a name and an attitude — instead of the progress they are paying for, and then claiming a saving without the per-reply minutes that produce it. "Agents will love it" is not a job, and "saves hours" is not a number.
Check yourself
1. The drafting tool saves the minute, but agents send 8% of drafts with an error they missed. Does the lead keep it?
8% of 560 is about 45 wrong replies sent a day, × 20 minutes = 900 agent-minutes lost against 560 saved: a net loss of 340 minutes a day. No. The threshold was 5%. A wrong draft the agent catches costs about 20 seconds, so 8% wrong drafted and caught is about 15 minutes a day; the 5% ceiling is on what gets past the agent. Either the eval brings the rate under it, or the tool drafts only the ticket types where the rate is already under it, and the saving is counted on those alone.
2. A second tenant has 40 agents at 15 tickets a day each and an empty queue at 6 pm. Same job?
600 tickets a day, more than the first tenant, but no push: nothing is carried overnight. The pull of 10 agent-hours exists on paper, and nobody is hiring to clear a queue that clears itself. The job there might be "answer in under 10 minutes", if that is what they measure — a different outcome, a different threshold, and possibly a different feature. Interview before assuming.
3. The lead asks for a dashboard of agent speed instead of the drafting tool. Which force is she reacting to?
Anxiety. She wants to see who is fast and who is wrong before she trusts a draft in front of a customer. Build the wrong-reply counter into the tool's first week rather than a separate dashboard: it costs less, it answers the force directly, and it is the number that decides whether the tool stays.