On progress, power, and why a useful framework still misses the social structure around the job
Jobs to Be Done became influential because it did something product teams desperately needed. It gave them a way to stop talking only about demographics and start talking about progress. Instead of asking who the customer is, it asked what the customer is trying to get done.
That shift was real progress. It moved product work closer to action, motivation, and context of use. It encouraged teams to pay attention to situations rather than only categories.
But for all its strengths, the framework still carries a major blind spot. It treats the job as something an individual hires a product to do. That makes it better than shallow segmentation. It does not make it fully sociological.
People do not only have jobs. They also occupy social positions. They act inside institutions, under norms, inside status systems, under economic pressure, and in relation to audiences that judge what kinds of behavior feel plausible or embarrassing.
That matters because two people can be trying to make the same progress and still encounter very different realities. One can "hire" the product with little risk. Another cannot. One has social permission. Another has to explain themselves. One has slack resources. Another is structurally constrained.
Once those conditions disappear from view, a framework that sounds contextual can still end up describing behavior as if it were mainly individual. The job remains legible. The social system around it does not.
This matters most when teams are working on behaviors shaped by legitimacy, identity, or unequal access. A budgeting product may frame the job as "help me stay in control of my finances." That sounds reasonable until you realize the real friction might be unstable income, debt burden, or the shame attached to admitting financial precarity. The product is not only helping someone do a job. It is entering a social reality with moral meaning already attached to it.
The same thing is true in education, health, work, and professional identity products. The user is not only hiring a product to make progress. The user is also navigating what kind of person this act makes them appear to be. A job can be clear while the social meaning of the act remains costly.
That is why I think JTBD can underdiagnose problems that are actually about audience, power, or norm formation. It is great at naming intended progress. It is weaker at naming the social conditions under which that progress becomes possible.
I would keep the question of progress and widen the frame around it. What is this person trying to get done, yes, but also: under what social conditions? In front of which audiences? With what structural constraints? Under what norms? At what identity cost? Who has permission to do this smoothly, and who has to work harder to make the same behavior feel legitimate?
That move sounds subtle, but it changes a lot. It shifts research away from isolated choice and toward socially situated action. It often changes the product response too. The right intervention may be trust transfer, smaller audiences, clearer norms, or different sequencing rather than a cleaner button or tighter positioning.
Practitioner writing from sociologists in UX, including Putting Users in Context, makes this point well: social context is not background noise. It is part of the mechanism.
Jobs to Be Done remains useful. I am not arguing to throw it out. I am arguing to stop treating it as complete. It is strongest when the problem really is about progress in a relatively unconstrained setting. It becomes thinner as the product moves closer to identity, power, institutions, and social risk.
If this essay names one limitation in the framework, Product Management Has an Individualistic Ontology names the deeper reason the limitation keeps appearing. And when the problem becomes visible in adoption behavior, the next place to go is The Product Funnel Starts Too Late.