Jobs to be Done

The old way of explaining demand was to describe who buys. Late twenties, lives in a big city, comfortable paying ten dollars a month for software. Group people like that, the thinking went, and what they will buy falls out of the grouping. Look at a customer list after the fact and those traits really do cluster.

The problem is that the traits describe the people who bought, not the reason they bought. The same thirty-two-year-old designer pays on one day and closes the tab on another. Age, job and income are identical across both days. What changed was not the person but the situation she had to get through that morning.

So meetings kept stalling in the same place. A discussion that opens with "our users are designers in their late twenties" runs out of road the moment three feature candidates are on the table. Knowing the age bracket says nothing about whether folders, better search, or comment notifications should be built first. With no basis for the choice, the loudest person decides, or the team copies whatever a competitor already shipped.

A study from the late 1990s knocked that habit loose. A fast food chain with weak milkshake sales had tried changing the flavor, the thickness and the cup, and none of it moved the number. So the question changed: when do people actually buy these, and who are they? Nearly half the milkshakes sold before nine in the morning, to solo customers who bought nothing else and walked straight back to their cars. Asked why, they gave more or less the same answer. The drive ahead was over an hour, they were hungry, one hand had to stay on the wheel, and they needed something that lasted, didn't spill, and could be held in one hand. The milkshake's real rivals that morning were not other milkshakes but bananas, donuts and coffee. The banana lost because it was gone in two minutes; the donut lost because it left sugar on the fingers.

That reframing is the whole idea. Stop grouping people and start grouping the job they pull a product in to finish. The word "hire" is doing real work here. A product is less a possession than a contractor called in for a specific situation and let go when the work is over. Once the morning commute disappears, the milkshake is fired that same day and something else gets the job.

The view settled into product discovery, the work of checking whether something is worth building before it gets built. User research is the basic instrument — meeting users, asking questions, watching them work — and the raw material it produces can be organized in several ways. Sharpen scattered users into a single imagined individual and you get a persona. Lay out the path from first hearing about a product to leaving it and you get a customer journey map. Collect the complaints and requests that already arrived and you are working with voice of customer (VOC). Jobs to be Done takes the same material and groups it by situation instead of by person.

The terms underneath split three ways: what kinds of jobs a customer is trying to finish (types), how a team writes down what it found (expression), and where the finding comes from (method).

Types exist to show that any single decision has three layers stacked in it.

1. Functional job — the practical task that has to get done, like making meeting notes editable by the whole team on one screen. It is the only layer you can watch happen, and the only one a user can demonstrate on request, which is why most requirements documents stop here.
2. Emotional job — how the person wants to feel along the way. Sending a link and not reopening it twenty minutes later to check whether it was the current version belongs here. These are usually about removing worry rather than adding delight.
3. Social job — how the person wants to be seen. Handing a new hire one link and wanting it to say "this team has its act together" sits in this layer.

The three are not a checklist to work through separately; they are pressed together in one moment. Pull apart a decision to pay and you find a functional job (get the documents into one place), an emotional job (stop the low-grade panic about where a file went), and a social job (avoid being the person who talked the company into the wrong tool). When a product demos well and still doesn't close, one of the two invisible layers is usually the reason. The mix shifts by product. For a tool that moves files around, the functional job is nearly everything; for a tool someone has to sell internally, the social job holds the decision.

Expression is about freezing what you found into a sentence the team can share. Job story is the one term here. It is written in three pieces — situation, motivation, expected outcome. "Right after a meeting ends, I want to capture just the decisions, so that the next meeting doesn't relitigate them." It gets compared to the user story, which states what a user wants in one sentence, but a user story starts from a "who" and a job story starts from a "when." Pin "right after a meeting ends" into the sentence and the question of where the feature belongs on screen answers itself.

Method covers where the finding comes from. Switch interview is the one term here. You find someone who changed tools recently and walk them back through the switch. Ask why they use it and most people invent a tidy reason; ask what happened on the morning they paid and an actual scene comes out. Four forces show up in that scene: the push of what wasn't working, the pull of the new option, the habit holding them in place, and the anxiety about moving. Grow the first two and leave the last two untouched and nobody moves. Ten more features won't outweigh a three-day migration nobody wants to start, which is why the valuable stretch of an interview is the hesitation, not the praise. A team that hears the hesitation usually ends up building an import path or a trial period rather than another feature.

The three connect in order. Interviews surface the situation, the type split separates the layers inside it, and the written sentence turns it into something a team can act on next week. Take one piece without the others and it tends to float. A team that adopts only the job story format ends up in a conference room composing sentences, with the form filled in and the team's guesses still inside it.

"Let's figure out the actual job first. They don't want more folders, they want last week's meeting notes in three seconds."

A push to plan against the purpose behind a request rather than the solution someone asked for.

"Our competition isn't other collaboration tools. It's group chat and email. That's what people are switching from."

Redrawing the competitive set around whatever currently does the same job.

"The functional job is solved but the emotional one isn't. Everything saves fine and people still come back to check."

An observation that the task is finished but the worry isn't, so a re-checking habit forms.

At Pagedeck the phrase came up constantly during a quarter when free teams stopped converting. Mia contacted eight teams that had moved over from another tool in the previous two months and asked what happened on the morning they paid. Five of the eight told the same shape of story: someone new had joined, the material from an earlier project had to be handed over, the files were scattered across chat threads, email and personal drives, and half a day disappeared into finding them. They paid that evening, and in four of the five cases the person who pushed for it was the one who had lost the half day.

The job Mia brought back was not "keep folders tidy" but "hand a new person the full context in one link." Sofia added the records from three deals that had fallen through and the same scene appeared in those too. Theo had been scheduled to build folder color labels that quarter; the team pushed that back and built a way to hand over an entire project as one invite link instead. By request volume, folder colors ran three to one ahead. But requests come from people already using the product, and the situation that decided payment belonged to people who weren't.

The most common mistake is treating whatever a user asks for as the job. It sounds like taking customers seriously, so the confusion is easy to fall into. What users describe, though, is usually the solution they already know. "Give us more folders" doesn't mean folders are needed; it means last week's notes can't be found, and search or a recent-documents list would finish that job too. A team that transcribes requests becomes an intake desk, builds in order of request volume, and reaches the end of the quarter without touching the situation that was actually blocking payment. The fix is not to ignore what people say but to ask one more question after it: what were you doing when you needed this.

The second is assuming a bigger job is a better job. Once you learn that a job is a purpose rather than a feature, the instinct is to climb toward something more fundamental — from "organize documents" to "collaborate well" to "work efficiently." The trouble is that the sentence at the top rules nothing out. Under "work efficiently," folder colors qualify, search qualifies, and so does video calling. A useful job carries a when and a condition with it: "on a new hire's first day, when earlier context has to be handed over." That version separates what gets built this week from what waits, because the condition itself rules options out. A quick test of the altitude: read the sentence, and if it can't eliminate at least two of five candidate features, it is still too high.