thinking-jobs-to-be-done

name: thinking-jobs-to-be-donedescription: 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.disable-model-invocation: true

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:

Job statement: When …, I want to …, so I can …
Performers: primary / secondary (frequency, stakes)
Forces: push / pull / anxiety / habit
Competition: direct | indirect | non-consumption
Outcomes: minimize […] ; maximize […]
Priority implication: build / cut / reposition — because job gap is …
Countercase checked: …
Evidence used / gaps: …

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.