thinking-jobs-to-be-done

1# Jobs to Be Done
2 
3Core rule: users hire solutions for progress in a situation. Prioritize the job, forces, outcome, and competing workaround—not the feature list.
4 
5## When to Use
6 
7- Choosing what to build, cut, or prioritize when user need is unclear
8- Explaining low adoption of a shipped feature
9- Mapping competition beyond same-category products (email, spreadsheets, manual work, non-consumption)
10- Positioning or research when the progress sought is contested
11 
12Requires 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.
13 
14## When NOT to Use
15 
16- Pure execution once the job is known (bug fix, schema, CI, performance)—implement, do not rediscover the job
17- Retro-justifying a decision already locked—framework theater
18- Infrastructure/internal work with no end-user progress decision
19- When the open question is only *how* to implement a settled job
20 
21## Procedure
22 
231. **Name performers and circumstance.** Who hires a solution, in what trigger situation, how often, and with what stakes. Prefer primary performers with daily high-stakes jobs over rare secondary ones.
242. **State the job, not the solution.** Frame: `When [circumstance], I want to [progress], so I can [outcome]`. Reject solution-shaped statements ("use Slack", "add a dashboard"). Capture functional, emotional, and social dimensions only if evidence supports them.
25…