What is jobs to be done?
Jobs to be done is a way to understand the progress a person wants to make when a particular situation arises. A customer chooses a product, service, or workaround because it helps them address that situation. Looking at the circumstances can reveal competition that a feature comparison misses.
The Christensen Institute describes functional, social, and emotional forces in these decisions. A practical task may involve completing a report, while the wider desired progress includes feeling prepared or being seen as dependable. Explore those dimensions through the customer's experience rather than assigning them from a persona template.
For SaaS founders, the framework can help explain why someone starts looking, what they currently use, and what makes switching difficult. It is a lens for investigation. A well-written job statement still needs evidence about demand, product fit, and the customer's actual ability to change.
Start with a recent decision and reconstruct the situation
Ask about a concrete occasion when the person adopted a product, tried an alternative, or decided to keep an existing method. Recent events are easier to investigate than broad questions about what people generally prefer. Establish what happened before asking for an explanation.
Build a timeline: the first sign of a problem, a moment that made action worthwhile, the search, the alternatives considered, the decision, and the first real use. Ask what was happening in the person's work at each point. An approaching deadline or a new responsibility can change how a familiar inconvenience is evaluated.
Use the customer interview guide for invitations, neutral questions, and evidence records. Useful prompts include 'What happened the last time?', 'What did you do next?', and 'What made that option difficult?' Avoid introducing your product as the expected answer.
Work through an original SaaS switching story
Our fictional buyer, Riley, runs a small client services studio. Riley previously assembled a Friday project update by asking colleagues for notes, copying changes into a document, and sending the result to clients. The workflow was familiar and flexible, even though it required repeated chasing.
A client asks why an important risk appeared only after a deadline slipped. Riley becomes concerned that a scattered update process hides unresolved issues. The next week, Riley searches for a way to collect project status and unresolved questions before the client call.
Riley considers a shared document template, a recurring team meeting, a project-management tool already in use, and a new SaaS called StatusLedger. These are competing approaches to the same progress, even though they belong to different software categories or require no new purchase.
In this invented story, Riley tries StatusLedger using one internal project and checks the output before sending anything to a client. The appeal is a dependable preparation process. The hesitation is whether colleagues will maintain another system and whether client information can be handled appropriately.
The story is deliberately fictional. It shows what a research record might contain, not evidence that studios in general have this job or would buy StatusLedger. Real conversations should be able to contradict the founder's preferred explanation.
Map the forces behind the switch
Separate the pressure from the current situation, the attraction of a new approach, the uncertainty about changing, and the comfort of the existing method. This is a useful working map for the story. Keep the person's words and observed actions beside your interpretation.
Riley's existing document wins on familiarity and flexibility. A new app has to justify setup, team behavior change, and the risk of a poor client-facing result. More features may do little to address those concerns. A safe internal trial and an inspectable output might answer a more important question.
| Force | Story observation | Question to investigate |
|---|---|---|
| Pressure to change | A client learns about a risk after a missed deadline | Was this an isolated incident or part of a recurring preparation problem? |
| Attraction of the approach | Riley wants issues collected before the client call | Can the proposed workflow expose the right unresolved questions? |
| Anxiety about switching | Riley worries colleagues will not maintain another app | What is the smallest additional task, and who owns it? |
| Habit and existing benefits | The shared document is familiar and easy to edit | Which existing strengths must the new approach preserve? |
Write a job statement that leaves room for alternatives
One useful drafting pattern is 'When [situation], I want to [make progress], so I can [desired outcome].' This is a writing aid rather than a universal formula. Describe the situation and result without baking your feature into the job.
For Riley, a draft could be: 'When I prepare a client project review, I want unresolved issues gathered and checked before the call, so I can explain the current state confidently and agree on the next action.' A shared document, meeting, or application could potentially serve that job.
Record related functional, emotional, and social dimensions as hypotheses. Functional progress might be a checked issue list; emotional progress might be reduced uncertainty before the call; social progress might be appearing dependable to a client. Confirm these interpretations rather than putting motives into Riley's mouth.
A job can connect people across demographic categories, but circumstances still matter. A freelancer preparing one update and an agency coordinating ten teams may face different constraints. The customer segmentation guide helps decide which differences affect the product and route to market.
Separate evidence, interpretation, and the next test
Preserve a compact evidence table. A recorded action or permitted quote is different from an inferred motive. Confidence should depend on the quality and range of observations, not on how neatly the story supports your idea.
In real research, seek counterexamples: someone who had the problem but stayed with a document, someone who tried the app and stopped, or someone whose approval rules make the workflow unsuitable. These cases can reveal constraints that a successful-adopter story misses.
Do not convert five similar interviews into a market-size estimate. Use them to clarify language, identify mechanisms, and choose further tests. Demand, willingness to pay, procurement, and sustained use require their own evidence.
| Entry type | Fictional example | What it supports |
|---|---|---|
| Observed action in the story | Riley trials one internal project before client use | An internal trial was part of this described decision |
| Interpretation | Anxiety about a poor client-facing result shaped the trial | A hypothesis to check with the buyer |
| Open question | Would a clearer document template solve the problem? | A comparison to investigate |
| Next test | Observe an approved synthetic project review with both approaches | Evidence about the workflow under the stated conditions |
Use the job to shape product and messaging decisions
The fictional job points to a workflow that gathers issues, makes omissions visible, and supports a human review. It also suggests that setup effort and inspection of the final output matter. These are candidate priorities to investigate through product discovery.
For messaging, describe the circumstance and progress in recognizable language. The value proposition guide helps turn supported customer evidence into an offer. Avoid claiming that the product removes every risk or guarantees client trust.
Keep the job statement editable. As you observe different contexts, refine the boundary or split genuinely different jobs. A useful JTBD record explains a decision well enough to improve a next step and remains open to evidence that changes the explanation.
Download the JTBD switching worksheet
The original worksheet includes the Riley story, a timeline, a forces map, job statement prompts, an evidence table, and a blank research record. Use it to prepare and interpret a permitted conversation about an actual decision. All people, products, and observations in the worked story are fictional. Source checked October 27, 2026.