Jobs to Be Done (JTBD) | Agile Scrum Master
Jobs to Be Done (JTBD) is a product discovery lens that explains why people choose and keep using a solution by focusing on the progress they are trying to make in a specific context. Jobs to Be Done (JTBD) improves prioritization and design by separating outcomes from features and by revealing the forces, constraints, and trade-offs that drive adoption. Key elements: job statements, functional and emotional drivers, context and constraints, job stories and outcome measures, interview and segmentation techniques, and experiments that validate whether a solution helps people complete the job.
How Jobs to Be Done (JTBD) improves product discovery and prioritization
Jobs to Be Done (JTBD) explains customer behavior by focusing on the progress a person is trying to make in a specific situation. Instead of starting from feature requests or internal assumptions, JTBD asks what outcome the person wants, what is preventing progress today, and what constraints shape their choices.
Jobs to Be Done (JTBD) makes discovery and prioritization more empirical by turning “why” into a testable model: teams make the job, outcomes, and constraints visible (transparency), validate them with real episodes and signals (inspection), and adapt roadmap and backlog decisions as evidence shifts (adaptation). The result is tighter feedback loops, clearer trade-offs, and less output-only delivery.
Core concepts in Jobs to Be Done (JTBD)
JTBD uses a small set of concepts to separate what customers want to accomplish from how they currently do it. The aim is to keep needs stable (outcomes) while allowing solutions to change as learning increases.
- Job - The progress a person is trying to make, expressed as an outcome rather than a solution.
- Main job - The central progress in a situation (for example, reach first value on a new platform).
- Related jobs - Supporting progress that accompanies the main job (for example, collaborate with a colleague or verify compliance).
- Consumption chain jobs - Setup, learning, integration, maintenance, and support required to use a solution effectively.
- Context - The situation and constraints that shape behavior (time pressure, environment, skills, policies, alternatives).
- Desired outcomes - What “better” means, expressed as a direction of change in time, effort, risk, errors, or confidence.
- Functional drivers - Practical outcomes such as completing a task faster, reducing errors, or improving reliability.
- Emotional and social drivers - Outcomes related to confidence, identity, trust, and how others perceive the person.
- Forces of progress - Push of the current situation, pull of a new approach, anxiety of change, and habit of the present.
- Job story - A succinct expression of context, motivation, and expected outcome: “When [situation], I want to [motivation], so I can [outcome].”
JTBD is not a slogan. It is a discipline for phrasing needs as outcomes and validating those outcomes through evidence, then updating decisions when the data says the model is wrong or incomplete.
Jobs to Be Done (JTBD) statements and job stories
JTBD uses formats that keep teams solution-agnostic long enough to learn. The goal is to make outcomes discussable, measurable, and easy to test with small experiments.
- Job statement - Describes the progress (for example, “manage monthly finances with confidence”) without specifying features.
- Job story - Frames context and motivation: “When [situation], I want to [motivation], so I can [expected outcome].”
- Outcome statement - Expresses success as a measurable change (for example, reduce reconciliation time from 2 hours to 30 minutes).
- Non-goals and constraints - Clarifies boundaries (compliance rules, risk limits, performance thresholds, outcomes that must not get worse).
- Alternatives - Captures how the job is done today, including workarounds, competitors, manual steps, and “good enough” substitutes.
These formats only help when they are grounded in real customer episodes. If they are invented to fill a template, they create confident-sounding assumptions and slow learning.
How to practice Jobs to Be Done (JTBD) - step by step
- Choose a scope - Pick a slice of the Customer Journey Map where progress is uncertain and value is meaningful, and name the decision JTBD should inform (opportunity selection, strategy, backlog ordering).
- Set a learning goal - Define what you need to learn first and what evidence would change your decision, so discovery work stays focused.
- Recruit participants - Include switchers who adopted or abandoned options, plus non-customers who still struggle with the job; balance by context, stakes, and recency.
- Run interviews - Use a timeline approach to capture triggers, constraints, workarounds, anxieties, trade-offs, and the sequence of steps people actually took.
- Extract jobs and outcomes - Cluster evidence into main job, related jobs, and consumption chain jobs; draft desired outcomes that are specific enough to observe.
- Prioritize opportunities - Compare outcomes by importance and current satisfaction; focus on what is important yet poorly satisfied to avoid chasing loud requests.
- Create job stories - Write short job stories for top opportunities; ensure they avoid solution language and specify an outcome that can be checked.
- Design thin experiments - Pick the smallest test that can falsify the riskiest assumption and produce a decision within days to weeks (prototype, concierge trial, incremental release).
- Decide and update - Promote ideas that move outcomes at small scale, stop those that do not, and record learning so the backlog reflects current evidence.
Interviewing and synthesis
JTBD relies on research to avoid projecting internal opinions onto customers. Interviews aim to uncover the situation, desired progress, constraints, and trade-offs that shaped behavior.
- Choose a scope - Select a clear job area and target context to avoid universal jobs that cannot guide design.
- Find real episodes - Discuss a specific recent decision or change so constraints and triggers are concrete.
- Capture forces and trade-offs - Identify what pushed the person away from the current approach and what pulled them toward an alternative.
- Separate outcomes from solutions - Translate feature language into outcome language and confirm what “better” means in that context.
- Segment by context - Group people by situation and constraints, not only by demographics, role labels, or a Persona name.
In Agile product work, JTBD findings should be traceable: a team should be able to point from an outcome to a hypothesis, to an experiment, to a decision, then inspect results and adapt.
How Jobs to Be Done (JTBD) connects to Agile delivery
JTBD strengthens Agile Product Management by turning strategy into opportunity language that guides backlog ordering. It complements Lean by replacing debate with experiments, and it complements DevOps by enabling small, safe releases with telemetry that makes outcome movement visible. Roadmap conversations can shift from feature advocacy to evidence-based choices about which outcomes to pursue now versus next.
JTBD improves delivery because it sharpens intent: when teams understand the job and outcomes, they can slice work into thin, end-to-end increments that deliver learning quickly, reduce rework, and keep work aligned to constraints.
- Problem framing - Define the progress and constraints before discussing solutions to reduce premature convergence.
- Backlog refinement - Use outcomes to shape acceptance criteria around observable behavior, not feature checklists.
- Prioritization - Order opportunities by unmet outcomes, importance, and evidence of constraints, not by stakeholder volume.
- Experiment design - Test the riskiest assumptions early with reversible changes and short learning loops.
- Validation - Inspect whether a change improves the ability to complete the job under real conditions.
- Review conversations - In Sprint Reviews, inspect outcome movement and learning, not only shipped output.
- Definition of done for learning - End experiments with evidence and a decision, and make the learning visible to stakeholders.
- Communication - Provide shared language across Product, Design, Engineering, and Go-to-Market functions.
JTBD does not replace user stories. It helps teams write better stories by anchoring them in customer progress, constraints, and measurable outcomes.
Jobs to Be Done (JTBD) Artifacts and how they connect
- Opportunity backlog - A prioritized list of unmet outcomes framed as opportunities rather than features.
- Opportunity solution tree - A visual link from outcomes to opportunities to solution options and experiments, keeping decisions auditable.
- Lean UX canvas - A compact way to turn job stories and outcomes into hypotheses, risks, and experiments.
- Discovery and delivery cadences - Dual-track flow that reserves capacity for experiments while delivering validated work.
- Outcome metrics - Measures such as activation, task success, error rate, or time to first value tied back to the job.
Good practices for rigorous JTBD
- Language discipline - Define jobs in customer words with neutral verbs (achieve, reduce, learn, verify), not solution terms.
- Segment by context - Split jobs by situation boundaries (frequency, stakes, device, environment) when they change constraints and behavior.
- Evidence hierarchy - Prefer observed behavior over opinions; use interviews to form hypotheses and experiments to validate outcome movement.
- Small bets - Test thin slices of the job within days to weeks to keep learning rapid and reversible.
- Traceability - Keep links from outcomes to job stories to experiments to decisions so stakeholders can inspect the evidence behind the roadmap.
Misuses and fake-agile patterns
JTBD is misused when teams adopt the vocabulary without changing how they learn and decide. These patterns create false confidence and reinforce output-focused delivery.
- Jobs as slogans - Broad jobs that apply to everyone and guide nothing; narrow by context, stakes, and constraints.
- No evidence loop - Declaring jobs and outcomes but not running interviews or experiments; make hypotheses explicit and inspect outcomes after each test.
- Feature translation only - Renaming requirements without changing priorities or slicing; use unmet outcomes to re-order work and remove low-impact scope.
- Over-segmentation - Too many micro-jobs that dilute focus; keep a small set of outcomes that materially change decisions.
- Metrics as targets - Using outcome metrics to punish teams encourages gaming; use metrics to learn, compare options, and adapt.
- Persona substitution - Using job labels as a replacement for real episodes; recruit by job context and switching event, then validate with evidence.
- Solution bias - Letting current product language define jobs; start from real-world steps, obstacles, and constraints before naming solutions.
- Vague outcomes - Outcomes that cannot be observed; specify direction of change, metric, object, and context.
- One-channel evidence - Relying only on interviews or only on analytics; triangulate qualitative insight with quantitative signals.
- Loss of cadence - Running JTBD once and reverting to feature intake; keep an opportunity backlog visible and run discovery on a recurring cadence.
JTBD is most useful when it tightens learning loops and makes decisions inspectable. Used this way, it improves discovery, slicing, and evidence-based prioritization without turning discovery into a heavyweight process.
Jobs to Be Done (JTBD) is a product discovery lens that explains why people choose solutions, focusing on desired progress, context, and outcome measures