Jobs to be Done Framework (JTBD)
Jobs to be Done says customers do not buy products, they hire them to make progress on a specific job, so you design around the job, not the demographic.
See the path narrow from a customer's struggle to the product hired to solve it.
Reach for this when…
- Customers who look nothing alike keep buying the same product for different reasons.
- A new feature tests well but sales do not move.
- You are guessing at customer needs from demographics instead of asking what they were trying to get done.
How to run it
- State the job in the customer's own words, not your product's.
- Interview people around a recent purchase or switch, not a survey.
- Map the steps of the job from start to finish.
- Find where the job is underserved: too slow, too risky, too awkward.
- Design and price against the job, then test with people who actually switched.
A worked example
Situation. Ananya Rao ran Setu Money, a mobile-money agent network in Bengaluru, India, and could not work out why customers used three different agents instead of sticking with hers.
Applied. She interviewed people around their last cash-out, not about the app. The job was not "send money", it was "get cash to my mother before she closes her stall" - speed and certainty beat convenience every time. Setu Money redesigned around a same-hour guarantee instead of a lower fee.
Result. Customers stopped shopping agents on price. Repeat use through Setu Money rose because it was the only agent that reliably met the real job.
The catch
The framework only works if you interview around real behaviour, not opinions, and that takes discipline most teams skip in favour of a quick survey. It also tends to undersell the emotional and social jobs sitting alongside the functional one. Get the job statement too broad and it stops guiding any decision at all.
Origin: Clayton Christensen; Bob Moesta