domains / families / general / thinking-jobs-to-be-done

thinking-jobs-to-be-done

separate

Deciding what to build or why adoption fails. Recover the progress users hire a solution for under a circumstance, then rank by outcome and competing workarounds.

When to use

• Choosing what to build, cut, or prioritize when user need is unclear
• Explaining low adoption of a shipped feature
• Mapping competition beyond same-category products (email, spreadsheets, manual work, non-consumption)
• Positioning or research when the progress sought is contested

When not to use

• Pure execution once the job is known (bug fix, schema, CI, performance)—implement, do not rediscover the job
• Retro-justifying a decision already locked—framework theater
• Infrastructure/internal work with no end-user progress decision
• When the open question is only *how* to implement a settled job

Skill page

Source