## Introduction Jobs to Be Done (JTBD) focuses on the progress customers seek in a given context, independent of any specific feature or solution. For technology leaders, a well-run JTBD workshop converts scattered input into prioritized customer jobs, measurable outcomes, and a thin-slice pilot with explicit ownership and guardrails. This guide provides a complete, practical template you can run next week. Use JTBD when you need to understand progress, not preferences: before major bets, when usage patterns shift, or when teams disagree on priorities. Do not use JTBD to incrementally tune a stable, well-instrumented process; process-improvement methods may fit better there. ## When JTBD fits (and when it does not) Use JTBD to: - Frame problems by customer progress across functional, emotional, and social dimensions. - Align cross-functional leaders on desired outcomes before solutioning. - Prioritize opportunities by importance and dissatisfaction. Avoid or complement JTBD when: - The problem is known and causal (use DMAIC or similar for quality/process optimization). - You are writing implementation details (use user stories after outcomes are clear). - You need market sizing or segments by spend/behavior (use segmentation for go-to-market, and connect segments to jobs rather than personas alone). Common misunderstandings: - JTBD is not personas. Personas describe who; JTBD clarifies why progress matters and in what context. - JTBD precedes user stories. User stories express solution scope; JTBD articulates the underlying progress and outcomes. - JTBD complements design thinking and product discovery. Use JTBD to sharpen problem framing; use research, prototyping, and experiments to test solutions. ## Core JTBD concepts and templates - Job statements - Template: When I [context], I want to [progress], so I can [value]. - Keep statements solution-free and anchored in a real situation. - Functional, emotional, social layers - Functional: the concrete task to advance (e.g., integrate an API call). - Emotional: how the person wants to feel (e.g., confident, not stuck). - Social: how they want to be perceived (e.g., competent to peers or clients). - Desired outcomes - Measurable improvements that indicate progress, e.g., Decrease time to first successful API call for new accounts within 24 hours of sign-up. - Use SMART as a quality check and tie outcomes to leading and lagging metrics. - Contexts, constraints, and competing solutions - Contexts: circumstances shaping the job (device, time pressure, team maturity). - Constraints: compliance, security, dependencies, budget, talent. - Competing solutions: direct competitors, in-house scripts, spreadsheets, or non-consumption. - Job map (end-to-end steps) - Define the job as a process: Define -> Locate -> Prepare -> Confirm -> Execute -> Monitor -> Modify -> Conclude. - Identify friction and metrics at each step. ## Interviewing with the switching timeline and forces Interview purpose: reconstruct the timeline of a specific recent switch (or attempted switch) to expose the forces that drove progress. Switching timeline prompts: - First thought: When did the current situation start to feel unsustainable? - Passive looking: What incidents or triggers built urgency? - Active looking: What alternatives did you compare and why? - Decision: What tipped you over the line? Who else influenced it? - First use: What surprised or blocked you in the first session? - Ongoing use: What became routine? What still feels risky or clunky? Forces of progress to code as you listen: - Push (pain in the status quo) - Pull (attraction of the new way) - Anxiety (risks, unknowns, switching costs) - Habit (existing routines and inertia) Evidence capture: - Extract verbatim moments, then convert to job statements, desired outcomes, and job-map frictions. - Note context, constraints, and competing solutions mentioned. ## Workshop template Participants and roles - Facilitator: time, flow, decision clarity. - Product lead: scope, constraints, problem framing. - Engineering lead: feasibility, complexity, operational risk. - Design/UX: narrative insights, friction points. - Data/Analytics: metrics design, baselines, instrumentation. - Support/Solutions: frontline patterns and escalations. - Security/Privacy: boundaries and controls. - Finance/Operations (as needed): costs, capacity, process. - Decision maker (one): accountable for post-workshop decisions. - Scribe: captures jobs, outcomes, assumptions, and actions. Pre-work (asynchronous) - Collect 5–10 recent switching stories (tickets, notes, replays). Select ones with concrete context. - List 3–5 guardrails/constraints (compliance, SLAs, architectural limits). - Share 3–5 baseline metrics (activation, time to value, error rate). Timed agenda (2.5–4 hours) - Purpose and scope (15 min): primary beneficiary, domain, constraints. - Raw narratives (30 min): read stories; no solution talk. - Job statements (40 min): write functional/emotional/social versions. - Forces of progress (30 min): map push, pull, anxieties, habits. - Job map (25 min): mark friction at each step; add contexts and constraints. - Outcome statements (30 min): draft measurable outcomes; check SMART. - Opportunity scoring (25 min): rate importance and satisfaction; score and sort. - Pilot framing (25 min): choose one opportunity; define success metric and guardrails. - Ownership and next steps (15 min): owners, decision date, risks to watch. Primary outputs - Prioritized jobs and outcomes with evidence links. - Job map annotated with friction points. - Opportunity matrix with scores and assumptions. - One thin-slice pilot charter with owners and guardrails. - Decision log and review date. ## Opportunity scoring (lightweight ODI) Use 1–10 scales gathered from workshop participants informed by interviews. - Importance (I): how critical the outcome is to progress. - Satisfaction (S): how well it is met today (your product or current workaround). - Opportunity score: I + max(I - S, 0). Prioritize high scores. Triangulate with risk, cost, and strategic fit. ## Metrics that matter - Leading: move early (e.g., time to first value, setup completion rate). - Lagging: confirm impact (e.g., retention, expansion revenue). - Diagnostic: explain performance (e.g., error types per step). - Guardrail: protect the business (e.g., incident rate, P95 latency, access violations). - Vanity: avoid (e.g., page views without context). ## End-to-end example (technology org) Scenario - Problem: New developers struggle to activate an API within 24 hours of sign-up. - Assumptions: B2B SaaS API; self-serve onboarding; basic observability; SOC 2 constraints. - Owners: Product lead (accountable), Eng lead (responsible), Design and Data (contributors), Security (consulted). Interview evidence (constructed for illustration) - Push: Demo worked, but internal deadline looms and sandbox creds often fail. - Pull: Competitor shows cURL examples that run instantly. - Anxiety: Unsure which scopes are safe; fear breaking staging data. - Habit: Copy-paste old Postman collections; search Slack for past examples. Job statements - Functional: When I receive API credentials, I want to confirm a safe, successful request, so I can prove viability quickly. - Emotional: I want to feel confident I cannot expose sensitive data during first use. - Social: I want to look competent to my team by unblocking the integration in a day. Job map friction - Prepare: Credential setup unclear; env vars not documented for common stacks. - Confirm: No obvious safe endpoint to test; error messages are generic. - Execute: Example requests mismatch default SDK versions. - Monitor: Logs unavailable to new users without role changes. Desired outcomes (examples) - Decrease median time to first successful API call for new accounts within 24 hours. - Increase percent of first-session users who complete a safe test call. - Decrease first-week setup-related support contacts per new account. - Increase comprehension of permissions and safe scopes at first use. Opportunity scoring (illustrative 1–10) - Outcome 1: I=9, S=4 => score = 9 + (9-4)=14. - Outcome 2: I=8, S=3 => score = 8 + (8-3)=13. - Outcome 3: I=7, S=5 => score = 7 + (7-5)=9. - Outcome 4: I=6, S=3 => score = 6 + (6-3)=9. Priority opportunity - Focus on Outcome 1 (highest score). Keep 2 as a close secondary diagnostic. Pilot framing (do not jump to features too early) - Hypothesis: If new users can execute a safe, verifiable request in-app, time to first value will drop without raising risk. - Options to test: guided credentials check, pre-configured safe endpoint, stack-specific snippets, or a sandbox token with constrained scopes. - Chosen thin slice: Introduce a constrained-scope test endpoint and auto-generated request in onboarding. Metrics - Success (leading): median time to first successful call in target cohort. - Diagnostics: percent of users who run the safe call; error types on first request; comprehension quiz completion. - Guardrails: access violation count; P95 latency of auth; incident and rollback rate; support contacts per new account. - Lagging: 7-day activation retention; week-4 active integrations. Cohort, risks, and decision points - Cohort: internal users, then 20% of new self-serve accounts; exclude regulated tenants. - Risks: over-permissioning, misleading success that does not translate to real endpoints, added auth latency. - Controls: constrained scopes, rate limits, clear labeling of test-only endpoint. - Review after 2 weeks: expand, iterate, or revert based on success and guardrails. ## Boundaries and complements - Personas: helpful for who to recruit and message; do not use them to infer jobs. Start from jobs; map personas later for communication. - User stories: express solution scope once outcomes are set. Example: As a developer, I can run a safe test call so that... ties back to Outcome 1. - Design thinking: use to ideate and prototype multiple solution options after jobs/outcomes are clear. - Product discovery: JTBD is a discovery tool; combine with experiments, A/B tests, and qualitative follow-ups. - Market segmentation: segment by context and constraints that alter jobs (e.g., enterprise compliance vs. startup agility) rather than demographics alone. ## Decision and governance checklist - Clarity: Is the primary job statement solution-free and context-specific? - Evidence: Do outcomes reflect switching stories and job-map friction? - Priority: Are opportunity scores high because importance is high and satisfaction is low? - Risk: Are guardrails defined, instrumented, and owned? - Ownership: Who decides after the pilot, on what date, using which metrics? - Traceability: Are assumptions, options, and decisions recorded? ## Conclusion and next actions A disciplined JTBD workshop translates customer progress into prioritized opportunities and a safe, testable plan. Keep statements solution-free, map the job end-to-end, score opportunities with simple, transparent criteria, and run a thin-slice pilot with clear owners and guardrails. Next actions: - Schedule a 3-hour session and send pre-work within 48 hours. - Recruit 5–8 participants across product, engineering, design, data, and security. - Prepare three switching interviews and baseline metrics. - Commit to a single thin-slice pilot, success metric, guardrails, cohort, and review date.