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.

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 Procedure 1. 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. 2. 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. 3. Map forces and switch. From artifacts: what push made the old way fail, what pull the new progress offers, what anxiety blocks switching, what habit keeps the status quo. List what they hire today—including non software and non consumption. 4. Define done and outcome metrics. How the performer knows the job is finished. List outcomes to minimize and maximize (time to progress, rework, confidence, surprises). Prefer frequent, poorly served jobs over rare, adequately worked around ones. 5. Score candidates against the job. For each feature/priority: which job step it serves, performer share, frequency, quality of alternatives. Promote high frequency underserved dimensions; demote polished work for well served or low stakes jobs. 6. Strongest countercase. State the best case that the stated job is wrong (wrong performer, vanity metric, process is the job, competition is actually non consumption). If the countercase fits evidence better, revise the job before recommending build. 7. Stop. Stop when one primary job statement, competing set, and outcome metrics are evidence backed enough to change a build/position decision—or when artifacts cannot answer and research is the only next step. Output Produce a JTBD decision artifact: Verification Falsify: If replacing the job statement with a feature name does not change the recommendation, you never left solution space—rewrite the job from circumstance and progress. Stop: Do not keep mapping job steps once the ranking decision is stable. Over application guard: Skip on pure implementation tasks and known jobs. Never fabricate user quotes or personas to fill missing evidence.

thinking-jobs-to-be-done