What Is Jobs to Be Done? Definition and Examples
Jobs to be done (JTBD) is a lens that says customers "hire" a product to make progress in a specific circumstance. The "job" is the progress a person wants — not the product itself, and not its features. Understanding that job explains why people really buy, and what they would fire your product for.
Quick Answer: Jobs to be done means people don't buy products for their own sake; they hire a product to make progress in a situation they're stuck in. The job is that progress — stable and durable — while the products people hire to do it change over time. Find the job, and you understand demand better than any feature list can tell you.
Popularized by Clayton Christensen in Competing Against Luck, JTBD reframes the central question of product work. Instead of asking "what does our customer want us to build?" it asks "what is the customer trying to accomplish, and what did they hire to do it before us?" That shift sounds small, but it changes who you interview, what you measure, and which ideas you bother to build. This piece defines the framework, walks through the example that made it famous, distinguishes it from features and needs, and shows where it earns its keep when you're validating an idea.
How Jobs to Be Done Works: Progress in a Circumstance
Jobs to be done works by treating every purchase as a hire: a person in a particular circumstance has a goal they can't yet reach, so they pull a product into their life to get the job done. When it does the job, they keep hiring it. When something does it better, they fire it. The product is a means; the job is the end.
Two ideas hold the framework together.
- The job is stable; the solutions are not. People have wanted to communicate over distance for centuries — the letters, telegrams, phones, and messaging apps that did the job kept changing. Christensen's argument is that the durable unit of demand is the job, not any product category built to serve it.
- The circumstance is part of the job. The same person has different jobs at different moments. "I need something to eat" on a rushed commute is a different job from "I need something to eat" at a leisurely family dinner, and it hires different products. Strip out the circumstance and you lose what actually drives the choice.
A job is never purely practical. Alan Klement, building on Christensen and on Bob Moesta's interviewing work in When Coffee and Kale Compete, stresses that jobs carry functional, emotional, and social dimensions at once — what you're trying to do, how you want to feel, and how you want to be seen. Miss the emotional and social layers and you'll build something that works on paper but nobody chooses.
A Concrete Example: The Job Behind a Purchase
The clearest way to see JTBD is Christensen's milkshake study, recounted in Competing Against Luck. A fast-food chain wanted to sell more milkshakes and had tried the obvious levers — thicker, cheaper, more flavors — with little effect. The team studying it stopped asking about the product and started watching when milkshakes got bought.
A surprising share sold early in the morning, to solo commuters who took them to go. Interviews revealed the job: make a long, boring drive more interesting and stave off mid-morning hunger — while one hand stays on the wheel. Seen that way, the milkshake wasn't competing with other milkshakes. It was competing with bananas (gone too fast, no staying power), bagels (crumbly, need two hands), and doughnuts (messy). The thick, slow milkshake won because it did the commuter's job better than any of them.
The lesson generalizes into a line JTBD writers love, usually traced to Theodore Levitt: people don't want a quarter-inch drill, they want a quarter-inch hole. Nobody hires the drill for its own sake; they hire it to make progress. If you only study the drill, you'll never notice the day a better way to make holes arrives and fires you.
Jobs to Be Done vs. Features vs. Needs
Founders often collapse "job," "feature," and "need" into one blurry idea, and it costs them clarity about what they're actually validating. The three sit at different altitudes. A job is the progress a person wants in a circumstance; a need is a general requirement; a feature is one thing your product does. The table below draws the lines qualitatively.
| Concept | What it describes | Example | Trap it creates |
|---|---|---|---|
| Job to be done | The progress a person wants in a circumstance | "Keep a boring commute interesting without a mess" | Requires real research to uncover |
| Need | A broad, stable requirement | "Something convenient to eat" | Too vague to guide a decision |
| Feature | A specific thing the product does | "Thick, slow-to-drink texture" | Feels concrete but proves nothing about demand |
| Persona | A demographic profile of a buyer | "35-year-old suburban commuter" | Describes who, never why |
Takeaway: Features and personas describe your product and your buyer; the job describes what the buyer is trying to accomplish. Two people with the same demographics can hire wildly different products for the same moment, and one person can have opposite jobs at breakfast and at dinner — which is exactly why JTBD looks past who someone is to what they're trying to get done.
When Jobs to Be Done Matters for Validating an Idea
Jobs to be done matters most in validation because it aims your research at demand instead of at your own solution. When you interview around a job — "walk me through the last time you tried to do this" — you learn what people already hire, what frustrates them about it, and what would make them switch. That is far stronger evidence than "would you use my app?", a question that invites polite yeses and validates nothing.
Three moments where the lens pays off:
- Framing customer interviews. JTBD gives you a script that surfaces real behavior, not opinions about your idea. It pairs naturally with the interviewing discipline in a complete guide to customer research for founders, where the goal is to understand the struggle before you pitch a fix.
- Defining the real competition. Your competitors are whatever people hire for the job today — including spreadsheets, workarounds, and doing nothing. That set is usually wider and more revealing than the "category" you think you're in.
- Writing requirements you can test. A job expressed as a job story — situation, motivation, expected outcome — turns a fuzzy insight into something a team can build against and check.
Getting the job right is upstream of everything, including product-market fit: fit is really just evidence that enough people hire your product for a job it does better than the alternatives. Tools like Edmired can help you organize what you learn from job interviews, but the discipline comes first — find the job, then build for it.
Key Takeaways
- Jobs to be done means customers hire products to make progress in a circumstance; the job is the progress they want, not the product or its features.
- The job is stable while solutions change — the durable unit of demand is what people are trying to accomplish, not any product category.
- Circumstance is part of the job. The same person has different jobs at different moments, and each hires a different solution.
- Every job has functional, emotional, and social dimensions — what you're doing, how you want to feel, and how you want to be seen.
- Christensen's milkshake study shows the point: study the job (a mess-free, filling commute) and you discover competitors you'd otherwise never see.
- JTBD is not features or personas. Features describe your product; personas describe your buyer; the job explains why anyone buys at all.
- Use it to sharpen validation — it aims interviews at real struggle, redefines your true competition, and turns insight into testable requirements.
Frequently Asked Questions
Who created the jobs to be done framework?
Jobs to be done was popularized by Harvard professor Clayton Christensen, most fully in his book Competing Against Luck, and shaped alongside Bob Moesta's interviewing practice. Alan Klement extended the thinking in When Coffee and Kale Compete. The underlying spirit — that people buy outcomes, not products — is often traced further back to Theodore Levitt's "quarter-inch hole" observation.
What is an example of a job to be done?
The classic example is Christensen's milkshake study: morning commuters hired a milkshake to make a dull drive more interesting and hold off hunger, one-handed and mess-free. The job wasn't "buy a milkshake" — it was "get through this commute." Framed that way, the milkshake competed with bananas and bagels, not with other milkshakes.
How is a job to be done different from a feature?
A feature is something your product does; a job is the progress a customer is trying to make. "Thick texture" is a feature. "Keep my commute interesting without a mess" is the job that feature happens to serve. Features only matter insofar as they help someone get a job done better than the alternatives they could hire instead.
Why does jobs to be done matter for validating a startup idea?
Because it points your research at demand rather than at your own solution. Interviewing around a job reveals what people already hire, what frustrates them, and what would make them switch — real evidence of a struggle worth solving. That is far more reliable than asking whether someone likes your idea, which tends to produce agreeable but meaningless answers.