Dr. Wallace's Favorite Mental Models
People don't buy products. They hire them to make progress on something in their life. Find the job, and you find what you're really competing with.
Jobs to Be Done (JTBD) says that people don't purchase products or services for their own sake. They "hire" them to make progress on a specific job — a goal or struggle they're trying to resolve in a particular circumstance. A job has three sides at once: a functional task to complete, a social impression to manage, and an emotional feeling to achieve or avoid.
Once you know the real job, your competition changes. A fast-food chain once assumed milkshakes competed with other milkshakes. Customers who bought one for a long, boring commute were actually competing it against bagels and bananas — portable, one-handed, not-too-messy ways to make the drive less boring. Same product, completely different competitive set, because the job was different.
Stop asking "who buys this?" Start asking "what job is this hired for, and what else could get that job done?"
Explaining surprising buying behavior, finding your real competitors, segmenting by circumstance instead of demographics, designing new offers.
Writing a "job statement" in a conference room instead of digging it out of real customer interviews. A guessed job is just a demographic guess with better branding.
Tony Ulwick formalized the method around 1990; Clayton Christensen's 2003 book The Innovator's Solution brought it into the mainstream.
Open each layer in order. Each one builds on the last.
Picture a product as a job candidate. Every time someone reaches for a purchase, they're interviewing a handful of candidates for an opening in their life: "get my kid to eat breakfast without a fight," "feel like a capable adult at my new job," "stop dreading Sunday nights." The product that gets "hired" isn't necessarily the one with the best spec sheet — it's the one that does the job, in that moment, better than the alternatives the person is actually weighing.
This reframes competition. You're not just up against companies that look like you. You're up against anything else a person might reach for to get the same job done — including doing nothing at all.
A "job" is never purely practical. Click each dimension to see what it looks like for the same situation: choosing a project-management tool for a small team.
This is the example that made JTBD famous. A fast-food chain wanted to sell more milkshakes, so they asked: who buys them, and how could we make the product better for that person? Sales barely moved. Then researchers just sat in the restaurant and watched. Try both moments below.
Tony Ulwick began developing the approach around 1990 after a product he'd worked on at IBM failed despite "doing everything right" by conventional product-management standards. Borrowing the rigor of quality-engineering methods like Six Sigma, he built a structured way to study the "job" a customer was trying to get done rather than the product itself, calling his version Outcome-Driven Innovation. His first documented case study was with Cordis Corporation in 1992, followed by work with companies including Microsoft and Bosch.
Clayton Christensen encountered the approach roughly a decade later and gave it the label most people know today, popularizing it through his 2003 book The Innovator's Solution and later research with Bob Moesta and the Christensen Institute. That's the lineage behind two names you'll see used almost interchangeably: Ulwick's rigorous, metrics-driven version, and Christensen's more narrative, story-driven version.
The honest caveat: JTBD became so popular that it's now often used as decoration rather than discipline. Teams write a tidy "job statement" in a single workshop and treat it as research. The framework's own strongest advocates warn that a job statement invented at a whiteboard mostly reflects the team's assumptions, while one pulled from real interviews with people who recently switched products reflects what customers actually experienced. The model is only as good as the listening that produced it.
| Situation | What it looks like | The real job (not the product) |
|---|---|---|
| Buying a drill | Someone walks into a hardware store for a power drill | Not "own a drill" — "put this shelf on the wall by Sunday" |
| Hiring a career coach | A mid-career professional books sessions | Not "get career advice" — "feel in control of a decision I've been avoiding for a year" |
| Choosing a charity to give to | A donor picks one nonprofit over another | Not "reduce suffering efficiently" — often "feel connected to a cause my community already supports" |
| Hiring a contractor | A homeowner gets quotes for a renovation | Not "renovate the kitchen" — "stop feeling embarrassed when people visit" |
| Signing up for a meal-kit service | A subscriber starts a weekly delivery | Not "eat healthier" — "feel like a competent adult without the grocery-store decision fatigue" |
| Switching accounting software | A small business changes tools mid-year | Not "better bookkeeping features" — "stop dreading the morning my accountant emails me" |
Scenario: a freelance graphic designer keeps losing long-term clients to a cheaper, less skilled competitor, and can't figure out why.
Writing the job statement in a meeting room. A job statement invented at a whiteboard mostly reflects your team's assumptions, not your customer's actual experience.
Treating it as a buzzword, not a research method. Saying "our customers hire us to grow their business" and stopping there is decoration, not analysis.
Filling in a template without the legwork. "When [situation], I want to [motivation], so I can [outcome]" is only useful after real interviews — used alone, it's a guessing game with a tidy shape.
Assuming one job applies to everyone. The morning milkshake buyer and the afternoon milkshake buyer are both "milkshake customers," but they have almost nothing else in common.
Ignoring the social and emotional dimensions. Teams default to the functional job because it's easiest to measure, then wonder why a functionally superior product keeps losing.
Skip JTBD when the decision is already well understood and mostly a matter of execution speed — a known feature request with no real ambiguity about why it's wanted doesn't need a deep jobs investigation. It's also the wrong tool for fast, low-stakes tactical calls, since rigorous JTBD research (real switching interviews, pattern-matching across customers) takes real time. And it's not a substitute for quantitative market sizing: JTBD explains the "why" behind a choice, not how many people will make it.
Describe a product, decision, or offer. We'll turn it into a starting prompt you can take to a real conversation — or to an AI assistant — to dig for the actual job.
This turns the model into a reusable instruction you can hand to an AI assistant any time you want it to think in Jobs-to-Be-Done terms.