Jobs to Be Done (JTBD) is a way to understand the progress people want to make in a particular situation. Instead of starting with a feature request such as “add receipt scanning,” investigate what someone is trying to finish, why their current approach falls short, and what a better outcome would mean. The useful output is a grounded explanation of the job, not a longer feature list.
Start with a recent real event, identify the situation and desired progress, compare the alternatives the person considered, and write a job statement that leaves room for different solutions. You can arrange those findings on Mockitt’s collaborative whiteboard before deciding which part deserves a prototype.
What counts as a job to be done?
A job describes progress from an unsatisfactory situation toward a desired one. It is not simply a person's occupation or an action inside your application. “Upload a receipt” is an action. “Get a complete expense packet ready for review before the deadline” describes a wider outcome that uploading might help achieve.
The surrounding circumstances matter. An employee submitting one expense after a trip and a coordinator collecting expenses from several colleagues may use the same upload form but face different obstacles. One needs to remember the purchase; the other needs to know whose evidence is missing. Treat those as research questions rather than assuming one workflow fits both.
A job can involve functional progress, feelings, and social concerns. Someone may need a complete packet, want to stop worrying about overlooked receipts, and want colleagues to see them as reliable. Keep the latter two grounded in what people say or do. A plausible emotion written by the team is still an assumption.
Write a job statement without prescribing the feature
A useful starting format is: When [situation], I want to [make progress], so I can [reach an outcome]. Intercom describes job stories in terms of situation, motivation, and expected outcome. This compact format helps communicate a finding; filling in the blanks does not replace research.
| Draft | What it misses | A more useful direction |
|---|---|---|
| As a coordinator, I want receipt scanning. | Names a role and a proposed solution, but not the struggle. | Investigate what collecting and checking the receipts prevents the coordinator from finishing. |
| When the deadline approaches, I want a better dashboard. | “Better” is undefined; the statement still commits to an interface. | Describe what the person needs to see or decide. |
| When several colleagues submit expenses before the monthly deadline, I want to see what is missing from each submission so I can send a complete packet for review. | A bounded job to investigate, rather than proof of a universal need. | Check it against real events, exceptions, and current workarounds. |
Do not remove useful context in pursuit of an abstract statement such as “be more productive.” Equally, avoid burying the job in a particular button, file format, or AI capability. A good statement explains the problem well enough that two different solutions could address it.
Find the job in an actual recent event
Ask someone to walk through the last time the situation occurred. What started the work? What did they try? Where did they wait, repeat a step, or ask another person for help? What did they use to decide they were finished? Concrete events reveal constraints that a general question about preferences can miss.
If someone recently changed tools or approaches, a customer switch interview can uncover the sequence behind that change. Use the interview to understand the event, then use the job statement to communicate the progress it reveals. These are complementary activities.
Keep the evidence attached to the statement. Record an anonymized observation reference, the circumstance, the existing alternative, and any contradiction. If a colleague says missing attachments are the problem but the participant spends most of the session checking approval rules, investigate that disagreement instead of editing it away.
Example: collecting an expense packet
Consider a hypothetical team preparing expenses for a monthly review. A coordinator currently uses email, a shared folder, and a spreadsheet. The product question is whether a clearer collection workflow would help. The following notes show how to structure the investigation; they are not findings from an actual study.
- Situation: submissions arrive from several colleagues shortly before a deadline.
- Desired progress: identify missing information and assemble a reviewable packet.
- Current alternatives: chase people by email, inspect the folder manually, or postpone the submission.
- Constraints to investigate: who can supply a missing receipt, who can correct a category, and what makes a packet ready.
- Open question: is the main difficulty collecting files, understanding requirements, or coordinating responsibility?
These possibilities imply different designs. A missing-file problem may call for clearer completeness status. A requirements problem may call for examples beside the relevant fields. A coordination problem may call for an explicit owner and a request-for-information state. Jumping straight to receipt scanning could leave any of those obstacles untouched.
Compare the alternatives people actually use
Your competitor is not always another application. A shared document, a conversation, an assistant, or deciding to do nothing can be a practical alternative. Ask why the person kept using an approach despite its drawbacks. Familiarity, coordination costs, confidence, and access may matter more than an extra feature.
Use a small comparison that stays specific to the job:
| Alternative | What it helps accomplish | What still needs investigation |
|---|---|---|
| Email and a folder | Collect files using tools colleagues already know. | How the coordinator notices missing items and tracks responsibility. |
| A shared checklist | Make required items and current status visible. | Whether the checklist stays accurate and who updates it. |
| A guided submission flow | Collect the necessary information in a consistent sequence. | Whether exceptions can be handled without blocking the whole packet. |
This is a set of options to investigate, not a scorecard proving a preferred product wins. Keep the conditions of comparison the same: the same submission, missing information, roles, and intended end state.
Turn the job into a design decision
Choose one obstacle supported by evidence and sketch an alternative that addresses it. For the expense example, a prototype could show a submission with one missing receipt, a clear owner for the next action, and a ready-for-review state. Ask a participant to identify what remains to be done and how they would resolve it.
The prototype can reveal comprehension or interaction problems. It cannot, by itself, establish sustained adoption, operational savings, or willingness to pay. Match the next research activity to the uncertainty that matters. When the uncertainty is whether the proposed idea offers useful value, use concept testing before polishing the workflow.
Revisit the job statement when new evidence changes your understanding. Keep a stable description when the underlying progress remains the same, but do not defend the original wording at the expense of what people actually need. The framework earns its place when it helps the team choose a better problem to solve.