explainer 4 min read
How to use jobs to be done without losing context
Use jobs to be done to understand the progress behind a product choice while preserving the circumstances, competing options, and constraints that shape behavior.
THE SHORT ANSWER
What you need to know
Use jobs to be done as a lens for understanding the progress a person seeks in a specific situation. Investigate what triggered the search, which alternatives they considered, and what made change difficult. Keep the job connected to observed episodes so it informs product choices without becoming a broad statement that could describe almost anyone.
Key takeaways
- Describe progress in the user’s situation.
- Study the transition between old and new approaches.
- Include emotional and social consequences when evidenced.
- Use a job statement to compare possible solutions.
Investigate a transition, not an abstract goal
A useful starting point is the last time someone changed how they handled a task. Suppose a small team moved from informal chat messages to a shared project tracker. Ask what happened before the move, when the old approach first became difficult, and what finally prompted action. Their goal may not have been better task management. It might have been to answer client questions without interrupting colleagues. The transition reveals what progress mattered in that situation and why the previous method stopped feeling adequate. Keep the sequence intact rather than reducing it immediately to a slogan.
Map competing options and resistance
Competition includes anything the person could do instead, including keeping the current workaround or avoiding the task. The team might have considered a weekly meeting, a document, or simply assigning one person to provide updates. Ask what each option offered and why it was accepted or rejected. Also investigate resistance to change: existing habits, setup effort, uncertainty about ownership, or concern about exposing incomplete work. These forces are part of the product decision. A proposed tool can promise a useful outcome yet remain unattractive if it creates a harder transition than the current workaround.
Write the job with its conditions attached
A practical statement connects a situation, desired progress, and consequence: when a client asks for an update during active delivery, help me understand the current status so I can respond without disrupting the team. Check the statement against the recorded episode. Do not add an emotional or social dimension merely because a framework includes one; add it when the participant’s account supports it. Keep separate statements when users face materially different circumstances. Combining unrelated jobs into a universal wish such as feeling confident often makes the statement too vague to guide a design decision.
Use the job to choose what to test
Compare solutions by how they support the progress and fit the conditions. In the project example, a status summary might help more than a detailed activity feed if the actual job is answering a client quickly. Test that interpretation with a realistic question and available project information. Ask whether the participant can complete the task, what information is missing, and what they would still need from a colleague. The checklist is to capture a recent transition, identify alternatives, examine resistance, write the bounded job, and compare solutions through the same episode. Review the job when the user or operating context changes.
Check the job against a case where the person chose not to change. If another project team kept informal messages because its clients rarely request status, that contrast defines an important boundary. The job should explain both the pressure toward a new approach and the circumstances that make the old approach sufficient. This comparison helps avoid turning one transition story into a universal description of the audience.
The progress people seek only explains part of their choice. Compare the manual processes, existing tools, and decisions to do nothing that compete in the same situation.How to research competitors through customer alternatives
Common questions
Is a job the same as a user task?
A task describes an action; a job describes the progress that makes the action useful in a particular situation. Connect them rather than treating the job as a replacement for workflow detail.
Can one product serve several jobs?
Yes, but separate their situations and consequences. Choose which job the first version supports clearly, then check whether additional jobs introduce conflicting requirements or make the promise harder to explain.
Do job statements replace personas?
They answer a different question. Use roles and constraints when those differences affect behavior, and use job statements to explain why someone seeks change within that context.
References & further reading
These primary references support the background. The practical frameworks and illustrative examples are written for this guide.
Prepared with AI assistance. Examples are illustrative; no client results are implied. Read our editorial approach.