Quick definition: Jobs to be Done (JTBD) is a product-discovery framework that describes the progress a person or organization seeks in a particular situation, rather than defining needs primarily by demographics, product features, or stated preferences.
What is Jobs to be Done?
Jobs to be Done asks why someone “hires” a product, service, workaround, or internal process. A job is the progress a customer wants to make when a circumstance creates a need. Someone does not buy a reporting tool merely because they are a manager aged 35–44; they may be trying to confidently explain a weekly performance change before a leadership meeting without assembling data manually. That desired progress includes practical, emotional, and social dimensions.
JTBD shifts attention from features to context. Features can change quickly, but the underlying situation, desired outcome, constraints, and alternatives may remain more stable. The framework is useful for research, positioning, onboarding, and prioritization because it makes competition broader: a spreadsheet, consultant, status meeting, or doing nothing can compete with a product.
A job is not a slogan, an untested wish, or a metric. “Users want simplicity” is too broad to guide a decision. A usable statement identifies the circumstance, the progress sought, and a meaningful constraint. Product analytics can show behavior around a job, while interviews and observation help discover why the behavior exists. It complements behavioral cohorts rather than replacing them.
Components of a JTBD framework
Research begins with recent decisions. Ask participants to reconstruct the timeline: what changed, what triggered a search, which alternatives they considered, what created anxiety, who influenced the decision, what they tried, and what outcome made the choice feel successful or disappointing. Specific episodes reduce the risk of collecting abstract opinions about an imagined future.
| Component | Question | Reporting-product example |
|---|---|---|
| Situation | When does the need arise? | A weekly meeting is approaching and numbers disagree. |
| Desired progress | What change is sought? | Produce a trusted explanation quickly. |
| Functional outcome | What must be accomplished? | Combine sources and identify the driver. |
| Emotional or social outcome | How should the customer feel or appear? | Feel prepared and credible with leadership. |
| Constraints and alternatives | What prevents progress today? | Limited access, manual exports, spreadsheet habit. |
Turn evidence into outcome statements that are directionally measurable, such as “minimize the time needed to identify the largest change in weekly performance” or “increase confidence that a report uses current data.” Avoid embedding a solution in the outcome. “Add an AI summary” pre-chooses an implementation; the underlying outcome could be served by a data-quality alert, clearer drill-down, or a different workflow.
Prioritize jobs by importance, current satisfaction, frequency, strategic fit, and the organization’s ability to deliver responsibly. Interview frequency is not market size, and a vivid quote is not proof of demand. Validate candidate jobs with broader research, product usage, support data, and willingness-to-switch evidence. Preserve contradictory findings instead of forcing all customers into one narrative.
Connecting JTBD to product measurement
JTBD should produce observable hypotheses. If the job is to prepare a trustworthy weekly explanation, a product may measure successful data connection, report creation, data freshness, completed drill-down, time to insight, repeat weekly use, and customer-reported confidence. No single event proves the job was completed. Pair behavioral signals with outcome surveys, support themes, and retention where appropriate.
Define the unit of analysis. In B2B software, one analyst may perform the action, a manager may judge the outcome, and the workspace pays for the product. Measure person-level task completion and account-level renewal separately. A low feature-use count can be good if it means the product reduces manual work; a high count can be bad if users repeatedly retry an unclear task.
Cohort analysis helps evaluate whether a job-focused experience works for the intended situation. Group users by first job-relevant context or activation event, not by a later behavior caused by the new experience. Compare outcomes against a stable eligible denominator. Qualitative follow-up can explain a trend that quantitative events cannot: a user may stop opening dashboards because automatic delivery solved their problem.
Experiment scenario: first-value onboarding
Interviews with newly acquired analysts reveal a recurring job: “When I inherit a weekly performance review, help me produce a reliable first explanation without learning every reporting feature.” The current onboarding tours generic navigation. The team hypothesizes that a job-based setup, which asks the reporting cadence and data source then guides the analyst to a pre-built weekly variance report, will improve first value.
It randomizes eligible new analyst accounts before onboarding begins. The primary outcome is the share that completes a server-confirmed weekly report and saves or shares it within seven days. Diagnostics include source selection, connection success, report generation, error states, and time to completion. Guardrails include data-access errors, unsupported-source requests, support contacts, cancellation, and later report accuracy feedback. The team also surveys a sampled subset about whether the workflow helped them prepare for their review.
The treatment must be evaluated on all assigned eligible users. An analysis restricted to people who complete the context question would exclude users whom the treatment may have confused. If report creation rises but later weekly reuse does not, the flow may be a one-time demonstration rather than a better job solution. If survey confidence rises but accuracy issues increase, product quality needs investigation before broader rollout.
Interpretation and data limitations
JTBD research can overstate coherence. People give rational stories after decisions that were influenced by habit, budget cycles, colleague recommendations, or chance. Recruit recent switchers, non-adopters, churned customers, and people using alternatives; interviewing only advocates narrows the set of jobs. Translate quotes carefully and distinguish a participant’s language from the researcher’s interpretation.
Jobs can vary across roles, regulatory environments, company maturity, and urgency. A broad job statement may conceal crucial differences in permissions, risk tolerance, and purchasing authority. Do not claim that a job is universal because a few interviews sound similar. Link assertions to the sample and continue testing them against behavior.
Finally, JTBD does not establish that an observed product change caused an outcome. It helps form a stronger hypothesis. Use controlled experiments when feasible, predefine success criteria, and review downstream quality and customer outcomes rather than treating a more engaging interface as success.
Common mistakes
- Writing feature requests as jobs: state desired progress before choosing a solution.
- Using demographics as the explanation: investigate the triggering situation and constraints.
- Relying on interviews alone: triangulate with behavioral, support, and market evidence.
- Equating activity with completion: define a meaningful task outcome and quality check.
- Ignoring alternatives: include spreadsheets, services, habits, and non-consumption.
- Making broad causal claims: test job-based designs with a valid comparison.
FAQ
Is JTBD a persona framework?
No. Personas can describe who a customer is; JTBD focuses on the situation and progress sought. They can be used together.
Can one product serve multiple jobs?
Yes. Separate jobs should be prioritized and measured individually rather than blended into a vague promise.
How do you discover a job?
Study recent real decisions, reconstruct the timeline, identify desired outcomes and alternatives, and validate patterns across evidence.
Does JTBD replace feature analytics?
No. It gives feature analytics a customer-progress context and helps choose which behavior should matter.
Summary
Jobs to be Done frames product demand as customer progress in a particular circumstance. Research real decision stories, define desired outcomes without prescribing features, and connect job hypotheses to meaningful behavioral and qualitative measures. Use experiments and quality guardrails to determine whether a job-focused product change actually helps customers progress.
Sources
- Behavioral cohort
- Activation
- Feature adoption
- How to write an A/B test hypothesis