Jobs to Be Done workshop template for technology teams

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

1. Job statements

• Template: When I [context], I want to [progress], so I can [value].
• Keep statements solution-free and anchored in a real situation.

1. 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).

1. 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.

1. 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.

1. 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:

1. First thought: When did the current situation start to feel unsustainable?
2. Passive looking: What incidents or triggers built urgency?
3. Active looking: What alternatives did you compare and why?
4. Decision: What tipped you over the line? Who else influenced it?
5. First use: What surprised or blocked you in the first session?
6. 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)

1. Purpose and scope (15 min): primary beneficiary, domain, constraints.
2. Raw narratives (30 min): read stories; no solution talk.
3. Job statements (40 min): write functional/emotional/social versions.
4. Forces of progress (30 min): map push, pull, anxieties, habits.
5. Job map (25 min): mark friction at each step; add contexts and constraints.
6. Outcome statements (30 min): draft measurable outcomes; check SMART.
7. Opportunity scoring (25 min): rate importance and satisfaction; score and sort.
8. Pilot framing (25 min): choose one opportunity; define success metric and guardrails.
9. 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)

1. Decrease median time to first successful API call for new accounts within 24 hours.
2. Increase percent of first-session users who complete a safe test call.
3. Decrease first-week setup-related support contacts per new account.
4. 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.