QUICK ANSWER
What should a jobs to be done template include?
A jobs to be done template should include one bounded research question, target-population reference, recent-change selection rule, interview timeline, situation, motivation, desired progress, functional, social, and emotional dimensions, pushes, pulls, habits, anxieties, minimized evidence quotes, synthesis confidence, counterevidence, limitations, desired-outcome hypotheses, proposal-only decision implications, review history, and explicit authority boundaries.
A jobs to be done template should preserve the story behind a change: the circumstance, struggle, desired progress, functional, social, and emotional dimensions, the forces that pushed and pulled on the decision, and the interview evidence behind the synthesis. It should show how confident the team is without converting a few accounts into a universal customer truth.
This downloadable pack owns one qualitative switch-interview study and its reviewable synthesis. It includes canonical JSON, generated Markdown, interview, quote, synthesis, and implication CSV views, a closed schema, a dependency-free validator, and mutation tests. Its desired outcomes are hypotheses, and its decision implications remain proposals rather than approved personas, journeys, use cases, stories, research conclusions, strategy, requirements, or roadmap commitments.
Move from a change story to a bounded JTBD synthesis
Start with a recent decision or change, reconstruct the timeline before interpreting it, and preserve each inference as evidence-linked and confidence-bounded. This pack follows a qualitative switch-interview path; quantitative ODI work remains a separate method and validation stage.
Bound the progress question and selection rule
Name one circumstance and recent change that make an interview eligible. Use a target-population reference, evidence cutoff, review date, owner role, and reviewer roles. Demographics may help recruit, but the synthesis owner is the progress sought in a circumstance, not a persona profile or a claim that the sample represents a market.
Sources: [jtbd-pack], [christensen-jtbd]
Reconstruct the decision timeline before asking for a slogan
Capture first thought, passive looking, active looking, decision, and use as an ordered account. Ask for specific moments, alternatives, tradeoffs, and what changed rather than relying only on an abstract reason stated after the fact. Keep minimized excerpts linked to their interview and access-controlled raw evidence outside the portable pack.
Sources: [jtbd-pack], [rewired-interview], [ico-minimisation]
Separate desired progress from the chosen solution
Synthesize the situation, motivation, desired progress, and one solution-independent job statement. Preserve functional progress, social meaning, and emotional energy as distinct dimensions. A feature request can be evidence about a struggle, but it is not automatically the job, a use case, a requirement, or a user story.
Sources: [jtbd-pack], [christensen-jtbd], [hbr-jtbd]
Map the forces that make change advance or stall
Record pushes from the current situation and pulls toward a new way alongside habits that preserve the current way and anxieties about change. Link each proposed pattern to interviews and evidence quotes. Do not treat a tidy force diagram as proof of causality or assume every interview belongs to one segment.
Sources: [jtbd-pack], [christensen-jtbd], [rewired-interview]
Write outcome hypotheses without inventing quantitative authority
Express each desired outcome with a direction, measure, and context, then link it to evidence and state confidence. In this qualitative pack, `surveyValidated`, `opportunityScored`, and `outcomeGuaranteed` stay false. ODI uses a separate, quantitative path for survey-ready desired outcomes and opportunity scoring; this record does not imitate that validation.
Sources: [jtbd-pack], [strategyn-template], [json-schema-2020-12], [rfc-2606], [owasp-csv-injection]
Route implications to their accountable owners
Record research follow-ups, experience hypotheses, messaging hypotheses, or operating-model questions as proposals with evidence, outcomes, confidence, and an owner role. Keep product-strategy approval, roadmap commitment, and requirement approval false, then hand each proposal to the owner that can evaluate the broader evidence and tradeoffs.
Sources: [jtbd-pack]
The JTBD interview-and-synthesis owner boundary
Use this record to explain a proposed progress pattern from bounded qualitative evidence. Link neighboring artifacts by reference whenever the work changes from interpreting decisions to modeling audiences, experiences, solution behavior, delivery, market findings, or strategic choices.
Included
- One versioned qualitative study, one research question, recent-change selection rule, target-population reference, evidence cutoff, review date, owners, reviewers, method, and limitations
- Interview situation, motivation, desired progress, five-phase change timeline, pushes, pulls, habits, anxieties, and stable evidence-quote references
- Public-safe fictional quote excerpts with interview IDs, context, recorded time, directness, source reference, and explicit fictional state
- Synthesis of situation, motivation, desired progress, job statement, functional, social, and emotional dimensions, forces, confidence, support, counterevidence, and limitations
- Desired-outcome hypotheses with direction, measure, context, evidence, confidence, and false survey, opportunity-score, and guarantee flags
- Proposal-only decision implications, ordered review history, all-false adjacent-authority boundaries, canonical JSON, generated Markdown and CSV, closed schema, validator, tests, and reproducible ZIP
Not included
- User persona identity, demographic or behavioral profile, goals, traits, segment approval, audience narrative, or claim that interview participants represent a market
- Customer journey stages, touchpoints, channels, experience metrics, service blueprint, journey governance, or approved end-to-end experience map
- Use-case actor-system contract, main and alternate flows, system guarantees, interface behavior, user-story backlog item, acceptance criteria, or delivery status
- Market-research program, sampling and recruitment authority, survey instrument, raw transcript archive, broader market findings, market size, demand estimate, segmentation conclusion, or statistical inference
- Product-strategy choice, positioning approval, competitive advantage, business case, prioritization, resource allocation, roadmap commitment, requirements approval, or release decision
- Participant names, contact details, raw recordings or transcripts, consent evidence, credentials, sensitive research, legal or privacy approval, representativeness, causality, product-market fit, or outcome claims
DOWNLOADABLE RESOURCE
Download the jobs to be done template pack
Start with the canonical JSON, use Markdown for the research review, and use the four CSV views for interview, quote, synthesis, and implication review. Run the included checks before any downstream team treats the record as evidence.
Jobs to be done template pack
A qualitative switch-interview and synthesis record with situation, motivation, desired progress, dimensions, forces, evidence quotes, confidence, desired outcomes, implications, review history, and explicit owner boundaries.
Format: Markdown, CSV, JSON, JSON Schema, validator, and tests in one reproducible ZIP archive
Locally reproduced August 1, 2026. SHA-256: e810f2a0032c726f7991b5ccc1019c61f5d5edda5421f050b0347a2a51c4ac6a
Included
- Canonical starter and completed fictional JSON plus deterministic Markdown study reviews
- Starter and completed fictional interview, evidence-quote, synthesis, and implication CSV projections
- Closed JSON Schema Draft 2020-12 and dependency-free validation for exact shapes, values, IDs, references, dates, timelines, safety, boundaries, and projection parity
- Seventy deterministic positive, mutation, security, boundary, and reproducibility tests plus a seventeen-file ZIP allowlist
Verification boundary
Validated both canonical records, regenerated and matched ten projections, ran 70 tests, copied an exact seventeen-file allowlist, stripped ZIP metadata, fixed timestamps, checked clean extraction, and reproduced the archive across timezones.
Three review layers in the fictional JTBD study
The fictional example follows three small-team coordinators who replaced improvised inbox intake. It demonstrates traceability and uncertainty; it is not real customer research or evidence that any product or market behaves this way.
Three change timelines with forces and quotes
Use when: A team needs to reconstruct what happened before, during, and after a recent choice instead of collecting only abstract preferences.
Each fictional interview records the qualifying change, situation, motivation, desired progress, five timeline phases, four force categories, and public-safe fictional quote references.
Structure
- Stable interview and quote IDs keep the account separate from later synthesis
- First thought, passive looking, active looking, decision, and use preserve the sequence without pretending that memory proves causality
Watch for: The public excerpts are fictional and minimized. A real study still needs appropriate recruitment, consent, access, retention, privacy, and research-quality review.
Sources: [jtbd-pack], [rewired-interview], [ico-minimisation]
Progress dimensions, forces, and confidence
Use when: Several eligible accounts appear to share a circumstance and desired progress, but the team needs to expose evidence and limits before naming a pattern.
The example separates functional, social, and emotional progress; proposes pushes, pulls, habits, and anxieties; links three supporting interviews; and keeps confidence low because the data are fictional.
Structure
- Situation, motivation, desired progress, and a solution-independent job statement remain distinct
- Confidence carries rationale, supporting and counterevidence interview IDs, and limitations rather than a decorative score
Watch for: A coherent synthesis is not a persona, segment, journey, representative market finding, causal model, or proof of demand.
Sources: [jtbd-pack], [christensen-jtbd], [hbr-jtbd]
Outcome hypotheses and decision handoffs
Use when: The research team needs to preserve what could be tested next without turning qualitative evidence into an approved product decision.
Three outcome hypotheses link direction, measure, context, dimension, quotes, and low confidence. Three implications route follow-up research, experience testing, and an operating-model question to owner roles.
Structure
- Survey validation, opportunity scoring, and outcome guarantees remain false on every desired outcome
- Product-strategy approval, roadmap commitment, and requirement approval remain false on every implication
Watch for: Outcome wording does not create quantitative evidence. Use a method appropriate to the next decision, sample, and risk before scoring or prioritizing.
Sources: [jtbd-pack], [strategyn-template]
Choose the neighboring owner when the question changes
Keep the JTBD record narrow: why progress was sought in a circumstance and what evidence supports that interpretation. Move the work when it begins to own a person model, experience map, system contract, delivery item, market conclusion, or strategic choice.
The team needs an archetype with attributes, goals, behaviors, needs, and segment evidence.
Choose: Create or update the user persona owner, citing the reviewed research rather than turning participants into a composite person inside the JTBD study.
Tradeoff: The audience model lives in another record, but a circumstance-based progress pattern is not confused with who a customer is.
The team needs stages, touchpoints, channels, feelings, breakdowns, and experience measures across time.
Choose: Use the customer journey map owner and reference the relevant job and evidence IDs as research inputs.
Tradeoff: The journey adds operational detail without turning the JTBD decision timeline into an approved end-to-end service map.
The work describes an actor interacting with a system or a bounded backlog item to implement.
Choose: Move actor-system behavior to a use case and delivery intent to a user story, then link back to reviewed JTBD evidence.
Tradeoff: Behavior and implementation require separate records, but the job stays solution-independent and does not become a feature request.
The question expands to sampling, market demand, segments, competitors, or broader findings.
Choose: Use the market research owner for the research program and its reviewable findings; reference this bounded qualitative study as one input.
Tradeoff: The broader program adds method and evidence obligations while the JTBD synthesis avoids claiming representativeness or market size.
An implication would choose positioning, competitive advantage, priority, resources, roadmap, or requirements.
Choose: Route the evidence-linked proposal to product strategy, roadmap, PRD, or requirement owners and preserve their explicit decision state separately.
Tradeoff: A downstream owner may reject the implication, but a research file cannot silently approve a product bet.
Someone wants to calculate opportunity scores from the qualitative outcome hypotheses.
Choose: Design a separate quantitative outcome-research process with appropriate statements, sampling, survey, scoring, and review; keep all three validation flags false here.
Tradeoff: Quantitative validation requires more work, but a few interviews are not laundered into survey evidence or a ranked opportunity list.
From evidence to a research workflow
Build the review tool your research team needs
Use Playcode to turn a reviewed JTBD structure into an internal tool with interview references, evidence access, synthesis states, and decision handoffs that match your process.
Explore internal toolsAdapt recruitment, permissions, consent, privacy, retention, security, and decision authority before connecting real research records.
See how Playcode supports internal toolsThe product page describes the current builder; it does not recruit participants, conduct interviews, validate evidence, approve research, or choose strategy.
What this template cannot prove
A closed record can make qualitative reasoning inspectable. It cannot turn a plausible customer story into market truth, decision authority, or measured impact.
- The validator checks exact shapes, values, dates, references, timeline order, safe public-example rules, all-false boundaries, and projection parity; it does not judge interviewer skill, leading questions, recall bias, interpretation, or research quality.
- Three fictional interview accounts demonstrate a structure only. They do not establish saturation, representativeness, segments, prevalence, demand, causality, or product-market fit.
- A quoted excerpt can preserve evidence context, but it does not prove the account is complete, truthful, correctly interpreted, lawfully processed, or safe to publish in a real study.
- Functional, social, and emotional dimensions and four force categories are synthesis lenses, not a guarantee that every decision fits one model or that the named forces caused the choice.
- Desired outcomes in this pack are qualitative hypotheses. They have not survived a survey, received an opportunity score, or been shown to predict behavior or business results.
- Implications remain proposals. They do not approve personas, journeys, use cases, user stories, market findings, strategy, positioning, roadmap, requirements, releases, or investment.
- Reserved URLs, synthetic aliases, no-PII flags, and CSV formula checks reduce public-example risk; they do not secure a research repository, spreadsheet, recording system, or downstream application.
- This ordinary informational article does not grant AI signup credits. The linked product page follows its own current eligibility and limits.
Primary sources and verification record
Primary theory and practitioner sources support the circumstance, progress, dimension, interview, force, and outcome distinctions. The local pack supports its exact fictional model and tests. No source endorses this artifact or certifies an adapted study.
[jtbd-pack] Playcode:Completed fictional JTBD interview and synthesis record
Checked August 1, 2026. Supports: The locally reviewed study identity, three fictional switch timelines, six fictional quotes, progress dimensions, forces, confidence, three outcome hypotheses, three decision proposals, authority boundaries, generated views, and 70 tests. Public availability remains unverified until deployment.
[christensen-jtbd] Christensen Institute:Jobs to Be Done Theory
Checked August 1, 2026. Supports: Primary theory guidance that JTBD examines progress in circumstances, forces toward and away from decisions, and functional, social, and emotional dimensions. It does not prescribe this schema or validate this fictional synthesis.
[hbr-jtbd] Harvard Business Review:Know Your Customers’ Jobs to Be Done
Checked August 1, 2026. Supports: The authors’ primary account of focusing innovation work on the progress customers seek in particular circumstances rather than only customer attributes. It does not establish this pack or a real customer finding.
[rewired-interview] The Re-Wired Group:JTBD Interview - Live Demonstration
Checked August 1, 2026. Supports: Bob Moesta’s practitioner demonstration of a decision interview, forces of progress, decision timeline, emotional, social, and functional energy, anxieties, tradeoffs, and pattern analysis. It does not certify this interview format.
[strategyn-template] Strategyn:Jobs to Be Done: The Original Framework by Tony Ulwick
Checked August 1, 2026. Supports: The explicit distinction between qualitative story-shaped JTBD work and Outcome-Driven Innovation, plus ODI’s solution-independent, measurable desired-outcome statements and separate survey and opportunity-scoring path. This pack does not claim ODI conformance.
[ico-minimisation] Information Commissioner's Office:Principle (c): Data minimisation
Checked August 1, 2026. Supports: UK regulatory guidance that personal data should be adequate, relevant, and limited to what is necessary. This article is not legal advice and does not assess a real research process.
[json-schema-2020-12] JSON Schema:JSON Schema Draft 2020-12
Checked August 1, 2026. Supports: The schema dialect declared by the downloadable closed JSON Schema.
[rfc-2606] RFC Editor:RFC 2606 Reserved Top Level DNS Names
Checked August 1, 2026. Supports: Use of the reserved `.test` top-level domain for fictional population and evidence references.
[owasp-csv-injection] OWASP Foundation:CSV Injection
Checked August 1, 2026. Supports: The known risk of formula-leading spreadsheet cells. The generator rejects such values, which does not secure an importing application.
Jobs to be done template questions
What is included in this jobs to be done template?
It includes a versioned study identity, research question, recent-change selection rule, method and limitations, five-phase interview timelines, situation, motivation, desired progress, functional, social, and emotional dimensions, four force categories, evidence quotes, synthesis confidence, desired outcomes, proposal-only implications, review history, owner boundaries, JSON, Markdown, CSV, schema, validator, and tests.
What is the difference between Jobs to Be Done and a user persona?
JTBD explains the progress someone seeks in a circumstance and the forces around a decision. A user persona owns a modeled audience pattern with attributes, goals, behaviors, needs, evidence, and segment boundaries. The same person can have different jobs in different circumstances, so link evidence rather than treating a job statement as a persona.
What is the difference between a JTBD timeline and a customer journey map?
A JTBD decision timeline reconstructs first thought, passive looking, active looking, decision, and use to understand a change. A customer journey map owns the broader experience over time, including stages, touchpoints, channels, feelings, breakdowns, measures, and service handoffs. One can inform the other, but they are not interchangeable.
Is a job to be done the same as a use case or user story?
No. A job describes desired progress without requiring a particular solution. A use case owns actor-system interactions, main and alternate flows, and guarantees. A user story owns one bounded backlog item with actor, context, need, value, acceptance evidence, dependencies, risks, and ready or done boundaries. Link them only after the product intent is reviewed.
Does this JTBD record replace market research?
No. This owner preserves one bounded qualitative switch-interview study and synthesis. A market research record owns the broader question, sampling and recruitment plan, multiple methods and sources, aggregate evidence, findings, contradictions, gaps, and representativeness limits. This JTBD study can be one cited input to that program.
Can JTBD findings decide product strategy or roadmap priority?
Not by themselves. This pack records evidence-linked implications as low, medium, or high-confidence proposals, while product-strategy approval, roadmap commitment, and requirement approval remain false. Strategy owners must consider the broader market, company capabilities, alternatives, economics, risks, and constraints before choosing a bet.
Are desired outcomes from interviews ready for opportunity scoring?
No. The outcomes in this qualitative pack are hypotheses with direction, measure, context, evidence, and confidence. ODI uses a separate discipline for survey-ready desired outcomes and quantitative opportunity scoring. Until that work is designed and reviewed, `surveyValidated`, `opportunityScored`, and `outcomeGuaranteed` remain false.
Can the downloadable pack store real interview transcripts?
It should not. The public pack requires fictional, public-safe excerpts and excludes participant names, contact details, recordings, and raw transcripts. Store real evidence in an access-controlled research system with the consent, privacy, security, access, retention, and legal controls appropriate to the study.
What does the validator check?
It checks closed shapes, allowed values, stable unique IDs, exact references, the five ordered timeline phases, normalized UTC timestamps, review chronology, reserved example hosts, fictional public-safe evidence, formula and sensitive-pattern rejection, outcome and implication limits, all-false adjacent authority, and exact Markdown and CSV projection parity.
Create the next step
Turn reviewed JTBD evidence into a usable research system
Describe the interview, synthesis, evidence, or review workflow you need and build a first version with Playcode.
Build an internal toolThis ordinary informational article does not grant AI signup credits. Current product eligibility and limits apply.