Jobs to Be Done
Also known as: JTBD, Jobs to Be Done framework
What Is Jobs to Be Done?
Jobs to Be Done is a framework for understanding why people use a product by focusing on the outcome they're trying to achieve rather than the features they're using to get there. The central idea: people don't buy products — they hire them to accomplish a specific job in their lives.
That job can be functional (complete a task), emotional (feel more confident), or social (be seen a certain way by others). Identifying the real job behind user behavior tells product and design teams what needs to be solved.
How Is It Applied?
The Jobs to Be Done approach uncovers user motivations through interviews focused on situations and goals rather than demographics.
The aim is to surface statements like: "When I'm reviewing my team's work at end of day, I want to spot problems quickly, so I can address them before they escalate." That structure: situation, motivation, expected outcome, is called a job story.
Those stories become a lens for evaluating features, flows, and design decisions. Rather than asking "does this look good?" the question becomes "does this help users complete the job?"
What Are the Benefits?
Outcome focus — teams design around what users are trying to accomplish, not just what they've asked for or what competitors have shipped.
Feature prioritization — every proposed feature can be evaluated against a real job, making it easier to cut what doesn't serve users and invest in what does.
Shared language — job stories give product, design, and engineering a common frame for discussing user needs without defaulting to opinion.
Stability — jobs tend to hold consistent over time, even as technology and interfaces change, making them reliable anchors for long-term decisions.
What Are the Limitations?
Missing the "who" — because Jobs to Be Done focuses on goals rather than people, it can lose the contextual detail that helps teams design for specific user types or accessibility needs.
No standardized research method — the framework doesn't prescribe how to uncover jobs, so output quality depends heavily on the research behind it.
Risk of oversimplification — user behavior rarely reduces to a single clean job. Forcing it into that format can obscure nuance that matters at the design level.
When Does It Add the Most Value?
Jobs to Be Done is particularly useful early in a product cycle, when teams are deciding what to build and why. It's also effective during redesigns, when existing assumptions about user needs need to be re-examined from scratch.
The framework fits naturally within product strategy work, where uncovering user motivations and aligning them with business goals shapes every design decision that follows.