Introduction
Jobs-to-Be-Done (JTBD) reframes product thinking around a simple idea: customers don't buy products, they hire them to do a specific job. This shift changes how teams evaluate features and understand competition.
The Core Idea
The classic example: people don't want a drill, they want a hole in the wall. Applied to software, users don't want a project management tool — they want to feel confident their team is on track. Understanding the underlying job reveals competitors a feature list would miss entirely, since a spreadsheet or a Slack channel might be "hired" for the same job.
Finding the Real Job
The job is usually uncovered by asking why a customer switched to (or away from) a product, not by asking what features they want. "Walk me through the situation that made you look for a tool like this" surfaces the real job far more reliably than a feature request survey.
Applying It to Feature Decisions
Once the core job is clear, features can be evaluated by how directly they help users get that job done, rather than by how impressive they sound. A feature that doesn't serve the core job, however clever, is usually a distraction from the product's real value proposition.
Common Mistakes
Teams often confuse the job with the current solution category — assuming the job is "use better project management software" rather than the deeper "feel confident my team is on track," which broadens the view of both competition and opportunity considerably.
Conclusion
JTBD isn't a replacement for user research — it's a lens that sharpens it, forcing teams to look past feature requests toward the actual outcome customers are trying to achieve.
Frequently Asked Questions
What's the classic example used to explain Jobs-to-Be-Done?+
People don't want a drill, they want a hole in the wall — the product is 'hired' to accomplish an underlying job, not valued for its own features.
How do I find the real 'job' my product is hired for?+
Ask customers to walk through the specific situation that made them look for a product like yours, rather than asking what features they want — this surfaces the underlying job much more reliably.
What's a common mistake teams make with JTBD?+
Confusing the job with the current solution category — assuming the job is 'use better project management software' rather than the deeper outcome, like feeling confident a team is on track.