Jobs to be Done (JTBD)
Customers hire products to make progress on a job, not because they love the product itself, so find the job and you find what actually needs fixing.
The chain runs from spotting the job someone's trying to get done through to testing whether the fix actually helps.
Reach for this when…
- Usage is falling but nobody in the building can say why.
- You keep adding features and retention doesn't move.
- You're about to build the roadmap and want it anchored in something other than opinion.
How to run it
- Ask what job the customer is 'hiring' your product to do.
- Separate the functional, emotional and social parts of that job.
- Map what they currently hire, including scrappy workarounds and competitors.
- Find where the current solution underperforms the job.
- Redesign around the job, not the product category.
- Test the redesign with real customers before you scale it.
A worked example
Situation. Rosa Quispe ran Cooperativa Illimani, a savings-and-loans cooperative in La Paz, Bolivia, and couldn't explain why members kept opening the mobile savings app once and never returning.
Applied. Interviews using JTBD framing found members weren't hiring the app to save money - they were hiring it to build a visible repayment history that would qualify them for a loan.
Result. She rebuilt the app around a loan-readiness score instead of a savings balance, and return visits more than doubled within two quarters.
The catch
The 'job' is often several jobs stacked together, and forcing them into one framing loses real texture. It works best with genuine customer interviews - guessing at the job from your desk defeats the purpose. And a job well served today can be served differently tomorrow by a competitor you never saw coming.
If your 'job statement' still names your product, you haven't found the job yet.
Origin: Clayton Christensen; Tony Ulwick (Outcome-Driven Innovation)