Jobs-To-Be-Done is not a UX framework. It's a strategic one. It starts from a simple but uncomfortable observation: nobody wants your product. They want the progress your product makes possible. The product is just the best available means to an end they were already trying to reach.
This reframe changes everything about how you design. Instead of asking "what features should we build?" you ask "what job is the customer trying to get done, and what would it take for them to hire our product - or a competitor's, or nothing at all - to do it?" The answers to those questions reveal a completely different product priority than almost any internal roadmap process would produce.
When you understand the progress your customer is trying to make, you stop designing features and start designing outcomes.
How JTBD changes design decisions
- It forces specificity about who the user is and what they're trying to accomplish - "financial adviser completing an annual review" is more useful than "adviser" as a design brief
- It surfaces the competing alternatives - including doing nothing, using a spreadsheet, or hiring a human - which reveals what you're actually competing against
- It makes internal disagreements about features resolvable - "what job does this do?" cuts through more effectively than any prioritisation framework
- It shifts the success metric from feature completion to job completion - did the user accomplish the thing they came to do?
The hardest part of applying JTBD is that it requires genuine customer research, not assumption. The jobs customers are actually trying to do are rarely the ones a product team would guess from the inside. That gap - between assumed jobs and real ones - is where most product and marketing decisions go wrong.