Attend to what the user hires the product to do
Aliases: jobs to be done · hiring a product · JTBD
What it is
Ask “why did you buy this software” and you get brand, price, a colleague’s tip. Ask “what did you hire it to do that time” and you get a piece of progress that had to move: turning invoices into a reimbursable state before a trip. A job to be done treats a product as something hired to advance a kind of progress, not as a bundle of features or a member of a category. Attention moves from what the product is to what had to get done in that moment. Features enter the analysis only as they were hired for the job.
Why it happens
Buying and using happen under concrete pressure: a deadline, substitutes already in hand, the risk of looking incompetent. Pressure selects a means that can move progress, not the thing that most resembles an “expense system.” Start from product attributes and the things actually compared in the hiring situation drop out—mail search, a shared sheet, asking an assistant. The hiring view forces a measure of progress: what counts as done, and what done would get the person out of. If progress cannot be written, the so-called job is a feature with a new label.
Studying it
Collect the most recent start / switch / stop as a dated event. Reconstruct the progress that had to move, the candidate means, and the triggering pressure; do not ask category preference. Write the event as “when…, I wanted…, so that…,” then check with observation or artifacts whether that hiring actually happened. Compare “feature satisfaction” with “was progress made” as predictors of continued use or abandonment. Outcomes: share of accounts that locate a single event, and whether a progress statement is intelligible with the product name removed.
Where it stops holding
Exploratory play, identity display, and undirected browsing need not be forced into a hiring sentence; forcing invents a job. In organizational buying, purchaser, operator, and beneficiary may be hiring different jobs; one “the user hires” erases the conflict. A mandated compliance system was not chosen for hire; analysis should contrast the official required job with the private means people actually use to get past it. Future jobs that have never occurred are hypotheses only.
Applying it
- Start interviews from the most recent concrete use or abandonment: what had to get done, which means were hired, and only then the product.
- A job statement with the product name stripped should still be intelligible to an outsider; if not, it is still a feature in costume.
- In design talk, filter proposals by “which progress is this applying for?” Features that cannot apply, even if a rival has them, do not automatically enter scope.
- Walk the statement through one real event. If pressure, candidates, and done-criteria miss the field, change the statement; do not change the event to save a slogan.