The Word Everyone Used and Nobody Could Define
A few years ago I noticed a strange thing: everyone in product said "we solve customer needs," but the moment I asked "what exactly is a Need?" the room split. For one person, a Need meant a problem. For another, a desire. For another, pleasure. For another, a task. One serious word was carrying four different operating objects.
At the same time, I was developing my own interpretation of Jobs To Be Done, and a second doubt kept bothering me: was a Job real? Did anything like this structure exist in the human mind, or had product people invented a neat construction to make messy motivation look manageable? If Need was too loose in product language, Job had the opposite problem: it sounded precise, but I still needed to know whether the precision pointed at something real.
If you use the term Need without knowing what it means, the problem is larger than your own imprecision. Your teammates, colleagues, and stakeholders are probably hearing different objects under the same word. One person hears problem. Another hears desire. Another hears emotional payoff. Another hears task. The team keeps saying customer need, but it is building for an abstract something. Strategy has no floor.
The foundation problem hits Job from the other side. When someone looks at a Job-based strategy from outside the work, without conducting the interviews, shaping the strategy, or seeing AJTBD operate in practice, the natural question is: can I trust this? If Job is only a clever product-research construction, it may be useful shorthand. It cannot carry a strategy. The term needs a foundation too.
The way out appeared when the two conflicts turned out to be connected. A precise definition of Need gives Job its foundation. A precise formulation of Job makes the Need usable in product work.
Need Has a Real Definition
The word became concrete for me because two things happened at the same time: I went through my own therapy, and I was building a service for matching people with psychotherapists. That forced me into a body of knowledge product people usually avoid. I read dozens of books on psychotherapy, studied motivation theory, and spoke with many experts who used the word need with much more discipline than product teams did.
The definition that finally became useful came from the psychotherapy side. Grosse Holtforth and Castonguay summarize the starting point plainly: people strive to satisfy their psychological needs (Grosse Holtforth & Castonguay, 2005). A Need is one of a few deep, durable forces the brain keeps trying to satisfy: safety, belonging, autonomy, competence, status, and a handful of others.
That definition was much more usable than the product use of the word. A product team may hear "I need a dashboard" and treat the sentence as a Need. In this frame, the dashboard sits above the Need layer. It may be a route toward control, competence, status, safety, or coherence. The Need is the deeper condition the person is trying to protect.
I went through the rest of the motivation literature — Maslow, Self-Determination Theory, Grawe's Consistency Theory, Dweck, Baumeister and Leary on belonging, Max-Neef's Human Scale Development, the SCARF model, social-motive research across cultures, well-being studies — to see which needs keep reappearing strongly enough that product work should treat them as real. Five clusters carry the strongest cross-theory consensus.
Physiological / homeostatic integrity means the body has to stay regulated: food, water, sleep, rest, pain avoidance, bodily stability. Most software products do not touch this layer directly, but health, food, fitness, sleep, medical, insurance, caregiving, and safety products often do.
Safety / security / predictability means threat reduction and a reliable environment. The customer wants the world to stop feeling dangerous, volatile, expensive, opaque, or out of control. TurboTax, insurance, password managers, SOC 2 vendors, home-security systems, and therapy-intake flows all borrow motivational weight from this cluster.
Relatedness / belonging / attachment means social contact, acceptance, love for partners and family, caring bonds, membership. This is the layer behind "someone gets me," "people like me do this," "I don't want to be alone in this," and "I want my team to trust me." Social products live here, but so do many B2B products that look purely functional from the outside.
Competence / mastery / effectance means being able to act effectively, learn, solve, improve, and master the environment. Cursor, Replit, Duolingo, Figma, Linear, coaching products, and many analytics tools borrow weight from this cluster: the person wants to feel capable enough to move.
Autonomy / agency / control means volition, self-direction, choice, and influence over one's actions and environment. Self-serve SaaS, no-code tools, personal finance products, creator tools, and many developer products sell partly by restoring agency: "I can do this myself now."
Three more come up across some theories without the same consensus, but they explain too much real product behavior to leave out.
Status / respect / self-enhancement appears across social-rank research, SCARF, Dweck, fundamental social motives, and classic need frameworks. Product people feel this constantly and often under-name it. A Rolex, a Stanford certificate, a verified badge, an enterprise logo strip, a Gartner placement, and a "Top Voice" badge all carry status weight.
Growth / meaning / self-coherence appears in intrinsic-goal research, identity-based motivation, meaning work, Dweck, and Maslow-like traditions. This is the layer behind products that help a person become the kind of person they want to be: education, therapy, coaching, fitness, creator tools, serious communities, and many founder products.
Consistency / coherence / cognitive balance appears in Grawe, Dweck, cognitive dissonance, and predictive-processing accounts. This is the pressure to make the world, the self, and the story fit together. A product can reduce confusion, reconcile contradictions, make a messy situation legible, or help a person stop living with an unresolved mental tab.
That is the set. When we say Need in this chapter, we mean one of these eight: bodily regulation, safety, belonging, competence, autonomy, status, meaning, or coherence.
Needs Give Weight; Jobs Give Shape
When I was working through Grawe's Consistency Theory, I got lucky. I stumbled on a single line in Neuropsychotherapy that explained what foundation Jobs actually have, and turned Job from something that might be a clever product-research construction into something concrete:
Stein and colleagues (2013) had stated the operational version: individual goals are formed to foster fulfillment or protection of basic human needs.
That was the missing middle.
Humans have Needs. The brain formulates goals to serve those Needs. A Job is AJTBD's product-research name for that need-serving goal at the point it becomes specific enough to observe, interview, design, price, and build against. The chain runs: Need → Job → prediction + action → outcome + emotion + prediction error signal.
This is what gives the term Job its legitimacy. The brain was already doing this work. The genius of the original JTBD authors — Christensen, Moesta, Ulwick — was to notice that this central unit of human motivation existed and to give it a working name. My job in AJTBD was different: to put a scientific foundation underneath the construct, study it in concrete detail, and make it operational enough to drive real business decisions.
The therapist case makes the two layers visible. At the Need layer, the customer is probably trying to protect safety, restore control, repair belonging, recover coherence, or feel competent again. Those words are true. They are also almost useless to the matching flow. "Restore coherence" does not tell a designer what a therapist card has to show, what the opening message should say, or how to price the first session.
At the Job layer the fog condenses into a sentence the product can act on: "I want to choose a therapist I can trust for a first session." Trust has criteria. The profile must show experience with the issue the person is carrying. The first available slot must be soon enough that the customer does not feel abandoned. The opening message must feel human.
The Need did not disappear from this picture. It became designable.
The same separation runs across categories. TurboTax reaches the Need for safety through the Job "I want to file my federal return correctly before the IRS deadline." Wealthfront reaches future security through "I want to put retirement investing on autopilot." Cursor reaches competence through "I want to ship a working prototype before the weekend ends." In each case the Need supplies motivational weight and the Job supplies the target the product can be built against.
People Cannot Tell You Their Needs
The Need layer is unconscious, and unconscious means the customer cannot accurately report it back to you. The evidence is decades deep. Nisbett and Wilson (1977) showed people confidently explaining their own behavior with causes that had nothing to do with what actually drove it. Gazzaniga's split-brain work found the left-hemisphere interpreter — a process that invents coherent stories for behavior whose real cause is inaccessible. Köllner and Schultheiss (2014) settled the need-specific case: what people say about their needs barely matches what implicit measures show.
The brain confabulates a cause that sounds reasonable and feels true to the person saying it, while the actual driver sits below conscious access. Ask a customer "what is your underlying need here?" and you get the conscious narrator producing a clean story that often does not match what the behavior shows.
What the customer can name is the concrete past: what they tried, what they paid, what counted as good enough, what made them abandon a path. That is the Job. The Need is what the team has to infer from the stack of Jobs underneath, and validate through behavior — through what people actually do and pay for, not through what they say in surveys.
Wes Asks If This Is Just Vocabulary Laundering
Jobs Are What We Operate On; Needs Are What We Infer
We work with Jobs because interviewing and quantitative research for the Need do not work. The customer cannot reliably tell us what is driving them at the Need layer — the introspection runs into the confabulation wall the previous section described, and self-report scales hit the same wall a different way.
The customer can tell us what they did, what they paid, what they compared, what counted as good enough. That is the Job. A Job is concrete: an expected outcome in a context, specific enough to interview against, design against, price, and build for. Underneath every Job sits a Need the Job is serving. We can hypothesize about that Need, infer it from the Jobs a person actually performs, even validate it through behavior. We cannot operate on it directly.
Once Needs and Jobs are separated, emotions stop looking like decoration. If Jobs are need-serving goals, emotions are the live readout of whether the person is moving toward the goal, away from it, or stuck on the way.