Feature requests tell you what users say they want. Jobs-to-be-Done tells you why — and the why is what actually predicts whether a feature will get used.
1The Job Is the Stable Unit, Not the Feature
Features come and go, but the underlying job a user is trying to accomplish tends to be stable for years. Anchoring product decisions to the job, rather than the current feature request, produces decisions that age better.
2Find the Job by Asking About the Moment of Hiring
Ask users to walk you through the specific moment they decided to use your product: what were they doing right before, what triggered the decision, what were they afraid would happen if they didn't act. That story reveals the real job far better than asking 'what features do you want.'
3Step-by-Step Breakdown
Jobs-to-be-Done (JTBD) reframes the question from 'what does the user want' to 'what job is the user hiring this product to do.' The classic example: people don't want a quarter-inch drill, they want a quarter-inch hole — and if a better way to get the hole appears, the drill gets fired.
The same feature can be hired for very different jobs by different users. A 'save for later' button might be hired as 'remind me to buy this on payday' by one user and 'let me compare it against three other options' by another — and those two jobs suggest very different follow-up features.
What does Jobs-to-be-Done encourage you to ask instead of 'what feature does the user want'?
- →What color should the button be?
- →What progress is the user trying to make in their life or work, and what are they hiring this product to do for them?
- →What does the competitor's product look like?
- →What's the cheapest feature to build this sprint?
Because the job is the real unit of competition, your product's real competitor might not look like your product at all. A meal-kit service's 'job' might be 'let me feel like I cooked something without deciding what to make' — which means it's competing with takeout, not just other meal-kit companies.
Why might a note-taking app's real competitor be a sticky note, not another note-taking app?
- →It isn't — apps only compete with other apps
- →Because both are 'hired' for the same job (quickly capture a thought before losing it), even though they look nothing alike
- →Because sticky notes are more colorful
- →Because note-taking apps never have real competitors
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1The Job Doesn't Change, But the Path to It Might Need To
A screen-reader user is hiring your product for the exact same job as a sighted user — 'capture this thought,' 'finish this purchase' — even though the interaction path differs. Designing for the job, not a specific input method, naturally pushes toward more accessible flows.
// Job: "complete checkout quickly"
// Must work via: mouse, keyboard, and screen reader alikeSEO Implications
- 1
Target 'jobs to be done framework for engineers' rather than the generic marketing-oriented JTBD content
Engineers researching this want it applied to feature prioritization decisions, not brand positioning exercises.
Best Practices
Ask 'What Would They Use Instead?' to Find the Real Job
If your product vanished tomorrow, what would this user actually do? Their honest answer (a competitor, a spreadsheet, a sticky note, nothing) reveals the job and your real competitive set far better than a feature comparison chart.
Frequent Bugs
Assuming every user hires the same feature for the same job, and building one-size-fits-all improvements based on that assumption.
When a feature has mixed engagement signals, check whether it's being hired for multiple different jobs by different user segments before deciding it 'doesn't work' — it might be working differently for each group.
Real-World Examples
The Milkshake Study
A fast-food chain studying milkshake sales found a large share were bought alone, in the morning, by commuters — not hired as 'dessert' but as 'something filling and easy to consume one-handed during a boring commute.' That job insight, not a taste survey, drove the right product changes (thicker shake, easier to buy fast).
// Wrong question: "how can we make the milkshake taste better"
// Right question: "what job is a 7am milkshake purchase actually doing"