Jobs to Be Done

Core rule: users hire solutions for progress in a situation. Prioritize the job, forces, outcome, and competing workaround—not the feature list.

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

Requires at least one evidence source: PRD/spec, tickets, support/sales notes, analytics/logs, or current product behavior. If none exist, name the research gap; do not invent quotes.

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