UX/UI Design · Foundations
Jobs to Be Done
On this page 9 sections
In 30 seconds
Jobs to Be Done (JTBD) is a framework that focuses on the progress a person is trying to make in a situation, not on the product. The working definition, from Clayton Christensen and his coauthors: the job to be done The progress a person is trying to make in a given circumstance; the outcome they hire a product to help them reach. Full entry → is the progress a customer is trying to make in a given circumstance The situation in which a job arises; attaching it matters because the same person can hire for different jobs in different situations. Full entry →. People 'hire' products to do a job and 'fire' them when the job is done poorly. A drill gets hired for a hole, not for itself. Features are judged by whether they help the job.
Why this matters
Teams often improve what they already sell — a faster drill, a bigger screen — while the person's actual problem stays unsolved. JTBD redirects that energy: name the progress the person wants, then judge every feature by whether it moves that progress forward. The habit transfers beyond product teams. Anyone who decides what to build, offer, or change can ask the same question: what job is this being hired for? Because jobs outlive products, the framing also supports long-term thinking — the job stays stable even as the tools change.
The college version
The working definition, attributed
Jobs to Be Done (JTBD) is a framework for understanding why people reach for products. The working definition comes from Clayton Christensen, Taddy Hall, Karen Dillon, and David S. Duncan, writing in Harvard Business Review: what companies really need to focus on is the progress the customer is trying to make in a given circumstance — what the customer hopes to accomplish — and that progress is what they call the job to be done. Two moves hide inside that sentence. First, the unit of analysis The object a framework studies; JTBD makes the job, rather than the product or the customer, the unit of analysis. Full entry → is the progress, not the product: the framework asks what a person is trying to move from and toward, not what they are buying. Second, the circumstance matters: the same person can have different jobs in different situations, so a job is only fully described when the situation is attached. The idea is deliberately general — jobs can be small, like passing the time while waiting in line, or large, like finding a more fulfilling career — which is why it travels from product design into strategy and service design.
The hire/fire metaphor and the core question
JTBD's everyday vocabulary treats products like employees. When we buy a product, we essentially 'hire' it to help us do a job; if it does the job well, we hire it again, and if it does the job poorly, we 'fire' it and look for an alternative. The metaphor does real work: it makes the product's role conditional and the job's role permanent. Products come and go, while the jobs they were hired for persist. That is why the core question of the framework is short and sharp: what job is the person trying to get done? The classic illustration is the drill. Marketing scholar Theodore Levitt is credited with the line that people do not want a quarter-inch drill; they want a quarter-inch hole. The lesson for designers: improving the drill is not the same as making holes better, and a team that studies the job may end up inventing something that is not a drill at all.
The job versus the person
JTBD is often paired with personas, and the two answer different questions. A persona A researched, fictional character representing a group of users; the sibling personas topic covers it in depth, and this lesson uses it only to contrast the person with the job. Full entry → describes who the user is: a researched character with behaviors, attitudes, and goals. JTBD describes what the user is trying to accomplish in a situation: the progress they are hiring for. Nielsen Norman Group's comparison makes the distinction concrete. All purchasers of a drill share the job of putting holes in things, yet a professional contractor and a weekend homeowner weigh very different success criteria The conditions that tell a team a job was done well; JTBD distinguishes functional criteria, which are objective, from emotional criteria, which are subjective. Full entry → — durability versus price — so the job alone does not tell a team how to prioritize between those users. The reverse also holds: one person can hire the same product for different jobs in different circumstances, as when a traveler books a flight for work and for vacation, two distinct jobs with different considerations. Personas and JTBD are not rivals; NN/g treats them as compatible, with JTBD information often folded into persona artifacts. The personas topic in this series covers the person side in full; this lesson only needs the boundary: the job is not the person.
Functional and emotional jobs
A single job description typically carries two kinds of success criteria. The functional job The practical, measurable part of a job: the objective condition that must hold, such as a hole of the right size in the right place. Full entry → is the practical task: the objective, measurable condition that must hold for the job to be done — a hole of the right size in the right place, a meal delivered hot within the hour. The emotional job The feeling a person wants from a situation, such as confidence or calm; the subjective side of a job, including how the person expects to be seen by others. Full entry → is the feeling the person wants from the situation: the confidence of a host whose cake will not be wrong, the calm of a commuter who knows the train will not be missed. As the Harvard Business Review authors put it, jobs are never simply about function; they carry powerful social and emotional dimensions. NN/g describes the same split as functional success criteria and emotional success criteria, noting that the emotional side may include social considerations, such as how a person imagines being perceived by others. Design that serves only the functional job completes the task but misses the person; design that ignores the functional job pleases no one for long.
The design lens and its limits
Once the job is named, JTBD becomes a lens for judging design. Features are evaluated by whether they help the job get done, and the strategy shifts from making a better drill to finding better ways to make holes. Strategyn, the firm where Tony Ulwick pioneered JTBD theory, puts it directly: stop studying the product and study the job people are trying to get done. The lens also points at whole-job opportunities — people rarely want to assemble several products to reach one outcome The result that defines success for a job; JTBD focuses on outcomes rather than on the features of existing products. Full entry →, so helping customers get the entire job done is a source of value. The honest framing matters as much as the enthusiasm. JTBD is one lens, not the whole picture: NN/g notes that it does not by itself build empathy with users, that it generalizes emotional context across the whole user base, and that it does not prescribe a specific format or deliverable. It is a way of framing the problem, born out of qualitative research Research built on observation and open-ended conversation, such as field studies and interviews; JTBD is born out of this kind of research. Full entry → such as field studies and interviews — which is why this series treats user research, interviews, personas, and journeys as siblings that JTBD works alongside rather than replaces.

Eli explains
The same idea, in plain words
Explain it like I’m 10
Jobs to Be Done (JTBD) is a way of asking why someone really reaches for a product. The person does not want the object; they want the change it brings. The classic example is the drill: nobody buys a drill because they love drills — they hire it to make a hole, and if a laser could make the same hole faster, the drill would be fired. So instead of asking how to make our product better, JTBD asks what job the person is trying to get done and whether our product helps. Teams write the job in one plain sentence, usually with the situation attached, then judge every feature against it. A feature that does not help the job is decoration. Two kinds of success hide inside the job: the functional task, which is measurable, and the emotional feeling the person wants, which is not.
Picture it like this
Think of hiring a handyman. You are not hiring a person; you are hiring the result — the shelf that ends up on the wall. If the handyman shows up but the shelf never goes up, you stop calling and hire someone else. Products are hired hands: the handyman is the product, the shelf is the outcome, and the reason you called at all is the job. A good handyman asks what you want the shelf to hold before quoting a price — that is the designer asking about the job.
Where the picture stops working
The analogy breaks down because products cannot improvise the way people can. A handyman who finds brick behind the plaster switches tools and carries on; a drill cannot decide to become a hammer. Products only do what their designers built them to do, which is exactly why the design has to start from the job in the first place.
Worked example
Petra manages ordering for a small bakery that sells decorated celebration cakes. Customers complained that the website was slow and the photo gallery cluttered, so the team planned a redesign focused on speed and prettier pictures. Before approving, Petra asked the JTBD question: what job does a customer hire this page for? Interviews showed that most orders were for a birthday the next day — the real job was 'get a cake that will delight a guest, with no risk it is wrong or late.' Measured against that job, load speed and photos barely moved the needle. The team reprioritized: a two-step order form with delivery-date confirmation, a plain list of sizes, and a clear pickup-time note. Next-day orders rose, and the photo gallery became a secondary page. The features changed because the team judged them by the job.
Key takeaway
People hire products to make progress in a situation, not to own the product: name the job, judge every feature by whether it helps, and treat JTBD as one lens among several.
Quick check
3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.
In the hire/fire metaphor, a customer 'fires' a product when...
A team building a food-delivery app discovers that customers ordering at 11 p.m. mostly hire the app for 'a hot meal delivered without having to talk to anyone.' Which feature best serves that job?
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related
You’ll learn to
- Define jobs to be done using the working definition attributed to Christensen and his coauthors.
- Explain the hire/fire metaphor and why it moves attention from the product to the job.
- Distinguish jobs to be done from personas: the job versus the person.
- Apply the functional-versus-emotional distinction when describing a product's job.
- Analyze a design decision by judging whether a feature helps the job get done.
- Evaluate the limits of jobs to be done as one lens among several.
Common mistakes
Writing the job as a vague want, like 'customers want cakes', with no situation attached.
Name the circumstance and the progress: 'get a cake that delights a guest, with no risk it is wrong or late' beats 'cakes'. The job is incomplete without the situation.
Describing the job using the product itself, such as 'the job is to use our app to book a ride'.
Keep asking what the person hopes to accomplish until the product disappears from the sentence: 'get across town reliably and arrive without feeling overcharged.'
Assuming one job fits every customer of a product.
The same job can carry different success criteria for different people — a contractor and a weekend DIYer both hire a drill for holes but value different things — and one person can hire the same product for different jobs in different circumstances.
Replacing every other understanding of users with JTBD.
A job description does not say who the users are or how to prioritize among competing groups. Personas, journeys, and research earn their place alongside JTBD; the framework is one lens, not the whole picture.
Inventing a plausible job sentence from the conference table instead of researching it.
JTBD is born out of qualitative research such as field studies and interviews. Ground the job in what people actually say and do before designing against it.
Easily confused
Jobs to be done vs. personas
JTBD names the progress a person is hiring for; personas describe who the users are with behavioral and attitudinal detail. JTBD generalizes the job across users, while personas help a team prioritize among users with competing needs; the two are compatible and often combined.
The functional job vs. the emotional job
The functional job is the practical, measurable task; the emotional job is the feeling the person wants, including how they expect to be seen. Both belong in one job description, and jobs are never simply about function.
JTBD vs. task analysis
Task analysis studies the steps of the current activity and can end up biased by the existing solution; JTBD questions whether that activity is even the right way to reach the outcome the user really seeks, keeping the focus on the outcome.
Key vocabulary
- job to be done
- The progress a person is trying to make in a given circumstance; the outcome they hire a product to help them reach.
- hire/fire metaphor
- The idea that people choose products the way an employer chooses a worker: hire a product for a job, rehire it when the job goes well, and fire it when the job goes badly.
- functional job
- The practical, measurable part of a job: the objective condition that must hold, such as a hole of the right size in the right place.
- emotional job
- The feeling a person wants from a situation, such as confidence or calm; the subjective side of a job, including how the person expects to be seen by others.
- unit of analysis
- The object a framework studies; JTBD makes the job, rather than the product or the customer, the unit of analysis.
- outcome
- The result that defines success for a job; JTBD focuses on outcomes rather than on the features of existing products.
- circumstance
- The situation in which a job arises; attaching it matters because the same person can hire for different jobs in different situations.
- success criteria
- The conditions that tell a team a job was done well; JTBD distinguishes functional criteria, which are objective, from emotional criteria, which are subjective.
- persona
- A researched, fictional character representing a group of users; the sibling personas topic covers it in depth, and this lesson uses it only to contrast the person with the job.
- qualitative research
- Research built on observation and open-ended conversation, such as field studies and interviews; JTBD is born out of this kind of research.
Sources & references
- Personas vs. Jobs-To-Be-Done — Nielsen Norman Group (NN/g)
- Know Your Customers' 'Jobs to Be Done' — Harvard Business Review (Clayton M. Christensen, Taddy Hall, Karen Dillon, David S. Duncan)
- Jobs-to-be-Done: The Theory & Methodology — Strategyn (Tony Ulwick)
EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.
Researched 2026-08-21
Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.

