Jobs-to-be-Done (JTBD)
Jobs-to-be-Done (JTBD) is a framework that defines products by the underlying progress customers are trying to make, rather than by customer demographics or product features.
Also known as: jobs to be done, outcome-driven innovation, JTBD framework
Jobs-to-be-Done (JTBD) is a framework for understanding why customers buy. It holds that people hire products to make progress in a specific situation, and that the job, not the persona, is the stable unit of analysis. The job includes functional, emotional, and social dimensions, and naming it well reframes how a company thinks about positioning, product priorities, and the alternatives buyers actually consider.
What Jobs-to-be-Done Means
Jobs-to-be-Done shifts the unit of analysis from the buyer’s identity to the buyer’s situation. Where a persona describes who the buyer is (role, goals, demographics), JTBD describes the progress the buyer is trying to make and the context in which that progress matters. The framework is most powerful when it reframes a category around outcomes rather than features, because product comparison alone rarely captures why a buyer chose a particular solution at a particular moment. Jobs come in three dimensions (functional, emotional, social) and most considered B2B purchases involve all three at once, which is why feature-led messaging often underperforms outcome-led messaging in markets where capability parity is the norm.
How Jobs-to-be-Done Works
The framework is applied through switch interviews with recent buyers, focusing on the trigger event, the struggle, the alternatives weighed, and the hoped-for outcome. Patterns across interviews reveal the core jobs your product is hired to do. The insights then shape positioning, messaging, content topics, roadmap priorities, and segmentation, because they reveal what buyers are really trying to accomplish rather than just describing who they are or what they liked. Strong products typically anchor on one or two primary jobs and address several smaller related jobs as a secondary benefit; trying to address many primary jobs makes positioning incoherent, so the discipline is choosing the lead job and treating others as adjacencies, not equal priorities.
Common Pitfalls and Misconceptions
A frequent misconception is that Jobs-to-be-Done replaces personas entirely. In practice, many B2B teams use both: the job explains the motivation and context, while persona and ICP work explains who holds the job and how to reach them. Another mistake is confusing a job with a feature request or a vague goal, ending up with a list too literal or too broad to guide decisions. Teams also frequently skip the real switch interviews and invent jobs internally in workshops, which produces job statements that feel plausible but do not match how buyers actually describe their decisions. And many teams write job statements either too specific to last a release cycle or too abstract to test.
Jobs-to-be-Done in Practice
The hardest discipline in Jobs-to-be-Done is writing job statements specific enough to be testable and abstract enough to be stable. Statements at the feature level become outdated within a release cycle; statements at the goal level become so general they fit every competitor. The pattern that works is naming the trigger, the desired progress, and the constraint together, which gives sales and product a job statement they can both act on without re-litigating the framing each time. Mature programs treat JTBD as the input to value proposition work rather than a substitute for it: the job statement names the progress to anchor on, and the value proposition expresses how the offering enables that progress better than the alternatives the buyer weighed.
Common questions.
How is Jobs-to-be-Done different from a buyer persona?
Where does JTBD show up in marketing?
How do you uncover the job?
What is a common mistake when applying Jobs-to-be-Done?
When should a team use Jobs-to-be-Done?
How does JTBD relate to value proposition work?
How many jobs should a product address?
Related Terms
More from Strategy.
Let’s Talk
Let’s talk about what your next quarter could look like.
Tell us what you’re working on. A senior practitioner reads it, not an SDR queue, and replies, usually within one business day.
- Reviewed personally, not routed through a queue.
- A conversation about what you’re actually working on, not a generic pitch.
- No pressure, just a chance to talk it through.