There’s an idea in product design that sounds academic until it quietly reshapes how you build anything. It’s called Jobs to Be Done, and its core claim is simple: people don’t buy products, they hire them to make progress. You don’t buy a drill because you want a drill. You hire it to make a hole, and you’ll fire it the moment something makes holes better.
For most companies that’s a useful metaphor. For us it’s not a metaphor at all. We build AI employees, and you hire one the way you’d hire a person: for a job. So the framework other businesses treat as a clever lens is, for us, the literal center of how we work. Before we build anything, we’re trying to answer one question. What job are you hiring this AI employee to do?
What “jobs to be done” actually means
The framework is usually pinned on Clayton Christensen, but he built it in the mid-1990s with Bob Moesta, who co-architected the theory and ran the study that made it famous. That study is about milkshakes. A restaurant chain wanted to sell more of them and had tried every obvious lever, more flavors and thicker textures, with nothing to show for it. The breakthrough came when Moesta and the team stopped asking who buys milkshakes and started asking what job a milkshake gets hired to do. A surprising share sold early in the morning, to commuters facing a long, boring drive with one free hand. The job wasn’t “dessert.” It was “make my commute less dull and keep me full until lunch.” Once you see that job, the whole design changes, and none of the changes are about flavor.
Christensen’s fuller framing, laid out in Harvard Business Review, is that a job is the progress a person is trying to make in a particular circumstance. Not their age, not their industry, not the features they say they want. The circumstance and the progress are the job. Everything else is noise you can safely ignore.
Why most AI gets sold against the wrong thing
Almost all AI is sold the opposite way. It leads with the technology. Look what the model can do, here are the features, here’s a demo. The buyer reasonably picks by capability, signs up for the impressive thing, and a month later has something generic that never changed their week. We wrote about that exact gap in what a managed AI employee actually is: the difference between software that hands you content and an employee that finishes the job.
The reason the generic thing disappoints isn’t that the AI is weak. It’s that nobody found the job. A capability is not a job. “Summarize documents” is a capability. “Stop losing the client whose call I missed while I was in a meeting” is a job. Sell the first and you get a polite shrug. Solve the second and you get a customer for years.
How we apply it
Here’s how that plays out in practice, using the shape of a conversation we have all the time.
An owner comes to us and says, “I want a chat widget on our website.” That’s a feature request, and if we just built it, we’d both lose. So we don’t start there.
- Start with the struggle, not the request. The feature someone asks for is a clue, not the job, so we ask about the moment things actually break down. Here it surfaces fast: leads come in at night and on weekends, nobody’s there to answer, and by morning they’ve already called a competitor. The chat widget was a guess at a fix. The real job is “capture every after-hours lead and book it before it walks.”
- Define the whole job, not just the mechanical part. A job has layers. The functional one is obvious: capture the lead, qualify it, book the appointment. But there’s an emotional layer too, the owner’s low-grade dread that money leaks out of the business every night and they can’t prove where. And a social one: they want to look responsive and sharp to a prospect who’s comparing three companies at once. Solve only the functional layer and you’ve done the task but missed the job.
- Design the AI employee to the job, not the feature. Only now do we decide what to build, and it’s rarely the widget they asked for. This job needs an AI employee that answers on every channel, day or night, qualifies the lead in the business’s own voice, books it straight onto the calendar, and logs it. It has to finish the work, not hand back a transcript for a tired human to act on later. That “finish it” bar is the entire difference between an employee and an assistant.
- Measure against the job done, not activity. The last step is the one most providers skip. We don’t measure whether the AI employee looked busy. We measure whether the progress happened, the way outcome-driven versions of this framework insist you should: are after-hours leads getting captured and booked, or still walking? If the job isn’t getting done, the build isn’t finished, however good the demo looked.
The framework and the product are the same idea
What makes Jobs to Be Done fit this work so cleanly is that we never had to translate it. The framework says customers hire a product to do a job. We build a product you literally hire, give a job, and manage. The metaphor and the mechanism are the same thing, which is rare, and it keeps us honest.
It’s also why our assessment leads with the question it does. Instead of a checklist of features, we ask one open question: what’s one process you’d hand off to an AI employee first? That’s a Jobs to Be Done question wearing plain clothes. It skips the technology and goes straight to the progress you’re trying to make. We cut our own form down to reach that question faster, because the job is what matters and the rest is friction.
So when someone asks what AI they should buy, we tend to answer with a question of our own. Forget the AI for a second. What’s the job? Get that right and everything after it, which employee, built how, measured against what, follows on its own. Get it wrong and the most advanced model on earth will still hand you a beautifully drilled hole in the wrong wall.