The Job Your Product Is Actually Being Hired For
Why the best PMs stop asking what people want and start watching what they do.
Most product failures aren't engineering failures. They're failures of attention.
The team built something real. It worked as specified. It shipped on time. And nobody came back, because the team solved the problem they assumed people had, not the one people actually brought to the door.
Jobs-to-be-done is a framework for paying attention properly.
The idea, developed by Clayton Christensen, starts with a deceptively simple observation: people don't buy products. They hire them to do a job. When someone downloads a meditation app at 11pm, they're not buying a wellness subscription. They're hiring something to quiet a mind that won't stop. When a first-generation college student buys a test prep book, they're not buying information. They're buying a version of themselves that belongs somewhere new.
The Three Layers Most Teams Get Wrong
The job has three layers, and most teams only see one of them.
The functional layer is what someone is trying to accomplish. "I need to fall asleep faster." "I need to pass this exam." Teams nail this layer, or think they do, and call it a day.
The emotional layer is how someone wants to feel while doing it. "I want to feel calm and in control instead of anxious and overwhelmed." This is harder to spec out. It doesn't show up in acceptance criteria. But it shapes whether someone comes back tomorrow or quietly deletes the app.
The social layer is what someone wants others to see. "I want to be the kind of person who has their life together. Who is capable. Who belongs in this new world." People rarely say this out loud. But it drives loyalty, word of mouth, and, crucially, pricing power. When a product nails the social layer, users become advocates without being asked. They're not recommending an app. They're sharing an identity.
The products that stick get all three right. The ones that don't mistake retention problems for marketing problems.
Why People Are Terrible Witnesses to Their Own Needs
What makes JTBD especially useful, and difficult, is the observation that you cannot learn the job by asking people what they want. People are genuinely bad at this. Not dishonest. Just bad.
What they're good at is telling stories. Ask someone about the last time they faced a problem, and watch what happens. The details come out. The workarounds. The frustrations. The tolerance thresholds. A clunky spreadsheet macro someone built because no tool existed. A pile of sticky notes on a monitor. The way someone describes their current process and apologises for it as if it's their fault.
That is your product brief. More honest than any survey. More useful than any focus group.
Behavior is the tell. Specifically:
- The hacks people build when no good solution exists.
- The things they tolerate even when they're painful, because switching feels worse.
- The moment they cross from "good enough" to "I need something better right now."
That last one, the switching moment, is the most underused insight in product development. When did they fire the old solution? What made that specific moment the one? The job was probably the same for months. Something in the context changed. Find that moment and you find the real lever.
How to Actually Use This
In user interviews, the best question is not "what would you like?" It's "tell me about the last time you had to deal with this." Stories beat preferences. Observation beats both. If you can watch someone navigate their current painful process, you will learn more in thirty minutes than in ten surveys.
Look for the moments when people switch. Not just to your product, from anything to anything in this problem space. Why did they leave the last solution? What was the specific trigger? What did they hope was true about the new one? That is the job, stated clearly, by the user's own actions.
The Job Is Not Static
One thing that trips teams up: the job changes. Not the category of job, but the context changes what counts as done.
What someone hires for at 11pm when they are spiraling is different from what they would hire for on a calm Sunday morning. The functional need might be the same. The emotional state is completely different. Great products either adapt to that or design explicitly for one context and own it.
This is why products built for the average user often serve nobody particularly well. The job is not abstract. It happens in a moment, in a state of mind, with a specific frustration in the background. The more precisely you understand that context, the simpler your roadmap becomes.
When You Find the Real Job
There is a specific clarity that comes when a team finally sees the job clearly. The roadmap simplifies. Prioritization gets easier. Features that seemed important because a competitor had them stop looking important. The question shifts from "what else can we build?" to "are we doing the job better than anything else could?"
That is the lever. It is not always obvious. It usually requires sitting in the uncomfortable space of actually understanding a person's struggle in context, not jumping to solutions, not building because you can, not shipping because the sprint is ending.
But when you find it and pull it, the product feels inevitable. Like it had to exist.
That is what product management done right looks like. Disciplined attention. Resistance to the obvious answer. Staying close to the person until you see what they actually need.