# The Jobs to Be Done Playbook ## PROMPT 0 — Retrieval, provenance, and source limits ### Source record The local EPUB identifies Jim Kalbach as author, Michael Schrage as foreword writer, Rosenfeld Media as publisher, and 2020 as publication year. EPUB metadata names ISBN 9781933820682 and 323 pages. The archive passes its integrity test. The complete readable spine includes the foreword, introduction, eight chapters, final thoughts, quick-reference plays, resources, index, acknowledgments, and author material. No Readwise source or annotation layer was available, so the local EPUB is Layer 1. I use chapter anchors `KAL-INTRO` and `KAL-C01` through `KAL-C08` rather than reader-highlight IDs. This costs personal emphasis: nothing in the source says which claims Courtney marked as important. The book is a playbook, not a controlled test of JTBD. It gives practical techniques, case stories, field experience, cited research traditions, and method comparisons. Its reported interview counts, market effects, and company cases can explain how the author recommends working; they cannot by themselves establish that JTBD caused a company’s performance. ### Source hierarchy | Layer | Role | Limit | | --- | --- | --- | | L1 | Kalbach’s definitions, research plays, cases, methods, and stated cautions | Practitioner synthesis; case attribution limits | | L2 | [Rosenfeld Media’s publisher page](https://rosenfeldmedia.com/books/jobs-to-be-done-book/) | Confirms title, author, and intended practical use | | L3 | [Christensen et al.’s JTBD account](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done) and research on JTBD interview limitations | Context and comparison, not proof of each play | | L4 | Vault connections and recommendations | Review inference; never author attribution | ### Connection contract This belongs with [[4. Archives/Book reviews/The Jobs-to-be-Done Pyramid]], [[4. Archives/Book reviews/Jobs to Be Done — Theory to Practice]], [[4. Archives/Book reviews/Mastering Community Management]], [[4. Archives/Book reviews/On Value Creation in Developer Relations (DevRel) - A Practitioners' Perspective]], [[3. Resources/MOCs/DevRel MOC]], [[3. Resources/Permanent Notes/A Metric Is Vanity Only Against Your Own Outcome Data]], [[3. Resources/Permanent Notes/A Feedback Signal Not More Automation Is What Makes a System Self-Improving]], [[3. Resources/Permanent Notes/Casual Contributors Are Users Not Community Members]], and [[3. Resources/Literature Notes/Making Data-Driven Product Decisions]]. Kalbach supplies the research discipline that a DevRel or product team needs before it turns “customer insight” into messaging, a roadmap, an event program, or a community initiative. The right unit is a person’s objective under stated circumstances. It does not make developers, users, or community members a means to a funnel. ## PROMPT 1 — Reading contract, questions, priors, and drift > [!warning] Inferred inputs > The user supplied the book but no personal reading purpose. I infer an analytical, professional purpose from its adjacency to DevRel, product strategy, and community work in this vault. Correct this if the reading served another goal. ### Reading contract - **Purpose:** evaluate a workable JTBD research process for product and DevRel decisions. - **Practical use:** scope research, recruit people who actually perform a job, distinguish job maps from company journey maps, and link evidence to a decision. - **Success:** preserve Kalbach’s actor, job, process, need, and circumstance distinctions while naming research, ethics, accessibility, and power limits. - **Evidence that would change this review:** direct comparisons showing no decision-quality gain from JTBD over ordinary discovery research, or a repeated failure of job statements to travel across relevant contexts. - **What the book cannot establish:** causal business impact of JTBD, representative market need from a small qualitative sample, or hidden participant motivation inferred from product data. - **Constraints:** no raw research corpus, no reader highlights, no independent reanalysis of cited cases, and no permission to alter related MOCs. ### Open questions 1. What makes a job distinct from task, outcome, need, preference, or aspiration? 2. Which JTBD school fits a discovery question: Switch, ODI, or a lighter playbook sequence? 3. When does a stable functional main job become too abstract to guide a decision? 4. Does “functional first” underweight social safety, emotion, identity, or care? 5. Who performs the job, buys the solution, approves it, maintains it, and lives with its effects? 6. How do job maps and customer journey maps answer different questions? 7. How many interviews are enough to form a hypothesis, and what follows before market claims? 8. What makes an outcome statement readable and testable across participants? 9. Can a job map account for collective work rather than a single performer? 10. Which conditions invalidate a “timeless” job statement? 11. How should a team handle people who cannot articulate their workaround, emotion, or constraint? 12. What duties arise when interviews expose disability access barriers, financial hardship, discrimination, or workplace risk? 13. Can JTBD make a DevRel program more useful without reducing contributors to adoption metrics? 14. What outcome would justify stopping a proposed feature, campaign, or community program? 15. How do AI-generated research summaries preserve traceability to participant evidence? 16. What data must not be collected simply because it might help a job map? ### Priors seed table | Claim | Prior | Reason | Evidence needed | | --- | ---: | --- | --- | | Objective-under-circumstance research can correct product-centric framing | Moderate-high | Strong explanatory mechanism | Decision comparisons and participant accuracy checks | | Job performers should be distinct from buyers and approvers | High | B2B and household roles differ | Actor and workflow evidence | | Direct interviews are useful for early discovery | Moderate-high | Contextual method, with limits | Recruitment diversity and synthesis audit | | Five to twelve interviews establish market opportunity | Low | Qualitative saturation does not establish prevalence | Representative survey or market evidence | | Functional jobs should always come before social/emotional dimensions | Low-moderate | Useful sequence in some work, not universal | Context-specific outcome evidence | | A job map is different from a customer journey map | High | Their objects of study differ | Map review and decision use | | Surveyed opportunity ratings can prioritize needs | Moderate | Depends on sample, wording, denominator, and decision model | Transparent instrument and validation | ### Drift assumptions The book’s 2020 claims do not change. Applied context does: research-recruitment channels, AI transcription and synthesis, privacy practices, accessibility standards, product categories, organizational structure, and language around identity and inclusion. Review a live JTBD process whenever those conditions shift or at least every twelve months. ## PROMPT 2 — Inspectional map and project ### Book map | Unit | Main work | Anchor | | --- | --- | --- | | Foreword + introduction | Positions JTBD as usable organizational inquiry | KAL-FORE; KAL-INTRO | | 1. Understanding JTBD | Defines the tradition, schools, and core orientation | KAL-C01 | | 2. Core concepts | Defines performer, job, process, need, circumstance, and job statements | KAL-C02 | | 3. Discovering value | Jobs and Switch interviews, Four Forces, job maps | KAL-C03 | | 4. Defining value | Desired outcomes, measurement, and opportunity discovery | KAL-C04 | | 5. Designing value | Translates insight into concepts, value propositions, and design | KAL-C05 | | 6. Delivering value | Maps consumption and service delivery | KAL-C06 | | 7. (Re)Developing value | Strategy, disruption, organization, and aspirations | KAL-C07 | | 8. JTBD in action | Compares full methods and combinations of plays | KAL-C08 | | Final thoughts + references | Condensed plays and routes to further method detail | KAL-FINAL | ### Central project Kalbach reconciles several JTBD traditions into a practical sequence for aligning markets, organization, and strategy around what people seek to accomplish. His core definition is “the process of reaching objectives under given circumstances.” He asks teams to begin with the job performer and a solution-independent main job, then map process stages, define needs as desired outcomes, investigate circumstances, and distinguish functional from social and emotional aspects. Later chapters turn the research into design, delivery, strategy, and organizational action. The book’s rhetorical modes are teach, explain, persuade, and guide practice. It assumes readers have an organization, a product or service context, and a decision to inform. Its emphasis on lightweight use makes it especially helpful for teams that need a concrete first pass, but it also creates a risk that users stop at the lightest play before evidence is strong enough. ### Provisional summary The Jobs to Be Done Playbook treats JTBD as a shared unit of inquiry rather than a slogan about customer focus. Kalbach separates a job performer from buyers, approvers, technicians, managers, audiences, and assistants; he distinguishes a solution-independent main job from related, emotional, social, and consumption jobs. The playbook then offers research and strategy moves: recruit job performers, conduct open jobs interviews or Switch interviews, map job processes, state desired outcomes, assess opportunity, translate needs into concepts and value propositions, map a consumption journey, examine disruption, and organize work around jobs. Kalbach’s most useful contribution is methodological precision: a job map investigates the person’s objective, while a journey map examines interaction with a company’s offering. His limits are equally clear. The book is a wide practitioner synthesis, so its outcome and company-success claims need independent research and transparent measurement before they become strategic commitments. ## PROMPT 3 — Classification and terminology ### Classification This is a practitioner field guide within product strategy, UX research, innovation, and organizational design. It compares the Switch and Outcome-Driven Innovation schools while borrowing from journey mapping, design, service delivery, and disruptive innovation. It is not an empirical validation study or an ethics code for customer research. ### Controlled vocabulary | Term | Author’s use | Operational definition | Confusion risk | Anchor | | --- | --- | --- | --- | --- | | Job | Process of reaching objectives under circumstances | A stated, solution-independent objective in a context | Treating a task or feature as a job | C01–C02 | | Job performer | Person executing the main job | Primary research participant for the main job | Conflating performer with buyer | C02 | | Main job | Broad functional objective anchoring scope | The bounded objective a study investigates | Making it a value proposition or need | C02 | | Related job | Adjacent objective | An objective that may compete with or inform the main job | Pulling every life goal into scope | C02 | | Process | Sequence of smaller jobs | A chronological job map | Calling product clicks the person’s process | C02–C03 | | Need | Desired outcome while performing the job | A measurable condition to improve or avoid | Treating a feature request as a need | C02; C04 | | Circumstance | Context framing job execution | Time, place, trigger, constraint, and social conditions | Generalizing beyond the studied context | C02 | | Emotional job | Desired or avoided feeling while doing the job | Participant-described experiential outcome | Guessing feeling from behavior | C02 | | Social job | Desired public perception | Participant-described social outcome | Inferring identity or status | C02 | | Jobs interview | Open inquiry into objective, process, and needs | Consented qualitative research session | Product-feedback interview disguised as discovery | C03 | | Switch interview | Retrospective study of a change in solution | Inquiry into forces around a specific switch | Treating hindsight story as causal fact | C03 | | Job map | Solution-independent process map | Map of the main job’s stages | Confusing it with a company journey | C03 | | Consumption job | Goal in finding, acquiring, or getting value from an offering | Buyer-side journey objective | Equating it with main job | C06 | | Desired outcome | Criterion for successful job performance | Wording to investigate and later prioritize | Rating an undefined or compound outcome | C04 | ### Category-error controls | Error | Status | Control | | --- | --- | --- | | Job performer = buyer | Present risk | Map both roles and their distinct evidence | | Job map = customer journey | Present risk | State whether the map centers independent progress or company interaction | | Interview story = population rate | Present risk | Use qualitative work to create hypotheses, not prevalence claims | | Functional first = emotions unimportant | Present risk | Check whether safety, dignity, trust, or social risk changes the functional outcome | | Stable job = unchanging person or context | Present risk | Retest circumstances and access conditions | | Persona = representative group | Present risk | Keep recruitment and evidence trail visible | | Customer success = organization success | Present risk | Test both benefits and distribution of burdens | ## PROMPT 4 — Claims and dependencies ### Claims inventory | ID | Claim | Type | Label | Expected evidence | Falsifier | Anchor | | --- | --- | --- | --- | --- | --- | | C-001 | JTBD studies objectives independent of a particular solution. | Definitional | EA | Interview and alternative-solution evidence | Objective cannot be expressed without the product | C01 | | C-002 | A job is a process of reaching objectives under circumstances. | Definitional | EA | Process accounts across contexts | No coherent process or condition can be specified | C01–C02 | | C-003 | A job performer differs from buyer and other actors. | Descriptive | EA | Role and workflow evidence | One actor reliably has all relevant needs in setting | C02 | | C-004 | Main jobs should be functional and solution-independent. | Methodological | EA | Stable goal statements across technologies | Functional framing omits decisive concern in a setting | C02 | | C-005 | Job maps show people’s process, not a company’s purchase funnel. | Methodological | EA | Independent process mapping | Map relies mainly on company touchpoints | C02–C03 | | C-006 | Jobs interviews can discover goals, workarounds, and needs. | Practical | EA | Interview corpus and synthesis trace | Participants cannot provide relevant process evidence | C03 | | C-007 | Switch interviews reveal forces around a solution change. | Practical | EA | Time-anchored switching accounts | No switch or unreliable recall | C03 | | C-008 | Desired outcomes can be measured and used to identify opportunity. | Methodological | EA | Validated items, sample, analysis, decision outcome | Items fail reliability, validity, or actionability | C04 | | C-009 | Job insight can inform design concepts and value propositions. | Practical | EA | Traceable design decision and participant evaluation | Design does not address stated job/need | C05 | | C-010 | Consumption maps aid service delivery and retention. | Practical | EA | Journey evidence and intervention results | Mapping does not improve delivery decision | C06 | | C-011 | JTBD can help organizations respond to disruption. | Strategic | EA | Comparative market and response evidence | Job analysis does not improve response | C07 | | C-012 | A common JTBD language can align departments. | Organizational | EA | Decision and coordination evidence | Language creates confusion or conflict without improvement | C01; C08 | | C-013 | ODI requires rigor and can mislead when cut short. | Methodological | EA | Full-method comparison, calculation audit | Reduced method has equivalent valid results | C08 | | C-014 | Customer-centric companies outperform others. | Causal | EA-limited | Transparent longitudinal, controlled evidence | Confounding explains performance | Intro; C08 | | C-015 | JTBD should start with participant goals while also mapping affected actors and power. | Practical | RI | Stakeholder, harm, and access map | Performer-only analysis captures all material effects | Review inference | | C-016 | Interview insight needs a traceable decision and response path. | Practical | RI | Research-to-decision record | Insight report changes nothing or cannot be audited | Review inference | | C-017 | DevRel research must separate voluntary community participation from a company’s consumption journey. | Ethical/practical | RI | Participant consent and purpose separation | Collapsing both yields equal trustworthy findings | Review inference | EA means explicit author claim. RI means review inference and must not be attributed to Kalbach. C-014 is a broad performance claim whose cited business examples do not establish JTBD as the cause. ### Dependency graph ```mermaid flowchart TD A["Job performer and circumstances C-002 to C-003"] --> B["Main job C-004"] B --> C["Job process and job map C-005"] A --> D["Qualitative discovery C-006 to C-007"] C --> E["Desired outcomes C-008"] D --> E E --> F["Design and delivery decisions C-009 to C-010"] F --> G["Strategic and organizational claims C-011 to C-012"] H["Consent, access, affected actors C-015 to C-017"] -.-> A H -.-> D H -.-> F ``` The load-bearing claim is C-006: a valid, well-scoped interview process must yield a sufficiently accurate account of the job. C-008, C-011, C-012, and C-014 can fail independently. A good discovery method does not prove organizational alignment or financial performance. ## PROMPT 5 — Evidence and calibration policy The book supplies practitioner guidance, examples, published research references, and selected business stories. It does not provide a common dataset or a head-to-head experimental comparison of JTBD against competing research approaches. I therefore use qualitative confidence bands rather than invented numerical certainty. | Grade of confidence | Use | | --- | --- | | High | Clear scope or role distinction with an observable mechanism | | Moderate | Plausible practice guidance that depends on execution and context | | Low | Broad performance claim or quantitative result without inspectable method | | N/A | Ethical recommendation or definition not primarily empirical | | Calibration risk | Severity | Reason | | --- | --- | --- | | Source dependence | High | Practitioner examples and author experience are one evidence family | | Selective success cases | High | Intercom, Intuit, and disruption examples are not counterfactual studies | | Small qualitative samples | High | Interviews generate insight but do not establish market prevalence | | Outcome-item wording | High | Small wording changes can change a survey result | | Proxy measures | High | Satisfaction, retention, and funding do not prove a job mechanism | | Recruiter and access bias | Moderate-high | Who can participate shapes what the team hears | | Motivated interpretation | Moderate | Organizations may seek validation for an existing strategy | ## PROMPT 6 — Analytical scaffold ### Argument spine 1. Customer goals and circumstances offer a stronger unit of inquiry than product attributes or demographics alone. 2. A job ecosystem separates performer, buyer, approver, technician, manager, audience, and assistant. 3. A main functional job organizes process, needs, related jobs, and emotional/social dimensions. 4. Jobs and Switch interviews produce research material for maps and outcome statements. 5. Job, consumption, and strategy methods translate insight into design, delivery, and organizational choices. 6. The depth of method must match decision stakes; rigorous quantitative work cannot be safely imitated in miniature. ### Evidence ledger | Evidence family | Supports | Independence | Limitation | | --- | --- | --- | --- | | Author field experience | Play design and practical sequencing | Low | No raw corpus or reanalysis | | JTBD thought-leader traditions | Definitions and methods | Medium | Schools disagree and publish different standards | | Illustrative company cases | Possible organizational use | Low-medium | Selection and attribution problems | | Interview guidance | Responsible discovery mechanics | Moderate | Must be tested in the target context | | ODI critique from author experience | Rigor warning | Low-medium | One practitioner’s implementation history | ### Weakest link and repair The weakest link is the path from early interviews to market-level opportunity and organizational impact. Repair it with documented recruitment, consent, coding, participant-language traceability, an outcome instrument, independent review, and a decision log that records null findings. The book itself points toward this repair by distinguishing lightweight discovery from ODI’s more demanding quantification. ### Entry conditions for evaluation Before treating an applied JTBD result as actionable, name the main job, circumstances, participant inclusion/exclusion rules, other actors, evidence sample, research questions, data retention rule, outcome decision, and how contradictory accounts will be handled. ## PROMPT 7 — Fair evaluation ### Strongest reconstruction Kalbach’s strongest contribution is not a new theory of motivation. It is a clear practical grammar for JTBD. His distinction among job performer, main job, process, needs, and circumstances improves research design. His insistence that job maps are different from company journey maps protects teams from drawing a funnel and mistaking it for the person’s life. He also candidly states that full ODI requires time, sample size, wording discipline, and statistical competence; a superficial imitation can give false readings. ### Evidence grades | Claims | Grade | Current conclusion | | --- | --- | --- | | C-001–C-005 | B | Coherent, usable analytical distinctions; context remains decisive | | C-006–C-007 | B/C | Strong qualitative research guidance; retrospective and recruitment limits remain | | C-008 | C | Sound aspiration, but validity depends on an inspectable instrument and sample | | C-009–C-010 | B/C | Plausible bridge from research to decisions; outcome proof must be local | | C-011–C-012 | C | Useful organizational hypotheses, not universal results | | C-013 | B | Appropriate warning about a demanding method | | C-014 | D | Broad business-performance attribution is weakly matched to the evidence shown | | C-015–C-017 | B/N/A | Necessary review safeguards, not author claims | The pattern favors method discipline over performance promises. The book helps a team ask better questions and preserve distinctions. It gives less confidence that any organization will get better results merely by adopting the label. ### Biases, counter-observations, and repairs - **Success-case selection:** company stories may spotlight growth and alignment while omitting failed JTBD programs. Impact: moderate. - **Causal overreach:** funding, profitability, retention, or disruption response can have many causes. Impact: high for C-014. - **Functional sequencing bias:** “solve functional first” can be practical, but dignity, trust, social safety, and access can be functional conditions rather than later decoration. Impact: moderate. - **Authorial self-critique:** Kalbach says jobs interviews do not capture all of a person’s experience, and he warns that ODI is difficult to execute faithfully. These concessions limit, rather than erase, bias concerns. Repair C-014 by changing it to: “JTBD can give an organization a common way to investigate customer objectives; any business effect must be measured in the organization’s own context.” Repair functional-first sequencing by treating social, emotional, accessibility, and safety constraints as possible conditions of successful functional completion. ## PROMPT 8 — Context and comparison ### Intellectual and historical placement Kalbach’s 2020 book synthesizes the JTBD schools associated with Christensen, Moesta, and Ulwick while connecting them to UX research, service design, journey mapping, and organizational strategy. It appears at a point when customer research and product teams increasingly share analytics, experimentation, and cross-functional delivery systems. Those systems can support discovery, but the book correctly argues that analytics alone do not reveal objectives and workarounds. [Kalbach’s publisher](https://rosenfeldmedia.com/books/jobs-to-be-done-book/) describes the book as a practical reconciliation of JTBD schools. Later interview-method discussion still finds limited empirical evidence about JTBD interview practice and identifies validity threats, which supports treating it as a hypothesis-generating method rather than a replacement for research validation ([overview](https://www.researchgate.net/publication/379988396_Unveiling_Customer_Needs_A_Comprehensive_Exploration_of_Jobs_to_be_Done_Interviews)). ### Comparison with Burleson | Question | Kalbach | Burleson | Recommendation for this vault | | --- | --- | --- | --- | | Starting unit | Functional main job under circumstances | Five-layer motivational inventory | Start with Kalbach’s job ecosystem and context | | Product interaction | Consumption journey, distinct from main job | Product Jobs are a Pyramid level | Use a journey map for company interaction, then test whether interaction friction blocks core progress | | Emotion and social meaning | Add after functional job is clear | Split into role identity, image identity, and emotion | Treat added layers as interview hypotheses, never inferred labels | | Research method | Interviews, maps, outcomes, optional rigor | Market Lens, inventory, profiles, pathways | Use Kalbach for evidence collection; use the Pyramid only when it creates a decision-relevant distinction | | Quantification | ODI is demanding and easy to misuse | Ratings described but not validated in the book | Do not rate opportunity without method, sample, and decision rule | This comparison is review synthesis, not evidence of influence between the authors. ### Vault connections | Note | Connection | Tension to retain | | --- | --- | --- | | [[3. Resources/MOCs/DevRel MOC]] | Research developer progress before choosing program, content, docs, or event work | Developer relations also has community, public-good, and ecosystem duties | | [[4. Archives/Book reviews/On Value Creation in Developer Relations (DevRel) - A Practitioners' Perspective]] | Jobs can connect a DevRel activity to a stated developer outcome | A business case cannot overwrite participant-defined benefit | | [[4. Archives/Book reviews/Mastering Community Management]] | Community roles and listening can provide discovery pathways | A community member is not automatically a research subject | | [[3. Resources/Permanent Notes/A Feedback Signal Not More Automation Is What Makes a System Self-Improving]] | JTBD provides a prompt for useful feedback | Feedback needs a visible response path | | [[3. Resources/Permanent Notes/Casual Contributors Are Users Not Community Members]] | Actor distinctions resist treating every user as a contributor | Participation and power must be examined separately | | [[3. Resources/Literature Notes/Making Data-Driven Product Decisions]] | Desired outcomes organize evidence and decisions | Quantified data needs a method and qualitative context | ## PROMPT 9 — DEIB, accessibility, and transfer audit ### Inclusion strengths The book explicitly distinguishes actors who often get collapsed in product work: performer, buyer, approver, reviewer, technician, manager, audience, and assistant. That structure helps reveal that a purchase decision can burden someone other than the buyer. It also names circumstances as essential, which gives a natural entry point for disability access, care obligations, time, language, cost, and social risk. ### Omission risks and controls | Risk | Control | | --- | --- | | The “job performer first” rule excludes people affected by the outcome | Map affected people, gatekeepers, and people bearing risk before committing to a decision | | Recruitment favors accessible, available, fluent participants | Offer accessible and compensated formats; document who cannot participate | | A function-first sequence sidelines safety or dignity | Treat safety, access, privacy, and social consequence as conditions of success | | Job statements erase cultural and institutional context | Preserve context and participant wording beside the abstracted job | | Social jobs invite image-based stereotypes | Never infer social status, gender, race, disability, sexuality, or identity from use data | | Interview disclosure creates risk | Minimize collection, separate research from performance management, and make withdrawal practical | ### Transferability table | Setting | Adaptation | | --- | --- | | Product discovery | Recruit actual job performers and build a traceable job map | | DevRel documentation | Study the job and circumstances that produce friction, then make an accessible change | | Community programs | Separate community consent and member benefit from acquisition or retention goals | | Enterprise buying | Map performer, buyer, approver, security/compliance reviewer, and administrator separately | | Public-interest or high-stakes service | Add ethics review, accessibility expertise, and affected-community governance | The syntax is accessible to an experienced business reader; reference density is high because it moves among several JTBD schools, research techniques, and strategy concepts. A novice reader should pair it with an introductory research-methods source and accessibility/consent guidance. ## PROMPT 10 — Notes pipeline ### Fleeting notes - A job map asks about a person’s independent objective; a journey map asks about interaction with an organization. - The job performer, buyer, and approver can have conflicting needs. - A main job needs a stated circumstance before it can guide research. - Interviews create hypotheses and language; they do not produce prevalence by themselves. - Functional completion can depend on safety, dignity, access, and social conditions. - A research report without a decision and response path becomes archived knowledge rather than action. ### Literature notes | Candidate | Source | Connection | | --- | --- | --- | | Job ecosystem roles | KAL-C02 | [[3. Resources/Permanent Notes/Casual Contributors Are Users Not Community Members]] | | Job map versus journey map | KAL-C02–C03; KAL-C06 | [[3. Resources/MOCs/DevRel MOC]] | | Jobs and Switch interviews | KAL-C03 | [[3. Resources/Literature Notes/Making Data-Driven Product Decisions]] | | Desired outcome rigor | KAL-C04; KAL-C08 | [[3. Resources/Permanent Notes/A Metric Is Vanity Only Against Your Own Outcome Data]] | | JTBD method combinations | KAL-C08 | [[4. Archives/Book reviews/The Jobs-to-be-Done Pyramid]] | ### Permanent-note candidates 1. **A job map and a customer journey map investigate different objects.** Confidence: high. Scope: product and service research. 2. **A buyer’s approval does not establish a job performer’s success.** Confidence: high. Scope: B2B, enterprise, and household decisions. 3. **A functional outcome can depend on access, safety, dignity, and social conditions.** Confidence: high. Scope: inclusive research and design. 4. **Qualitative job research creates hypotheses; representative evidence tests market prevalence.** Confidence: high. Scope: product and strategy decisions. 5. **Research insight needs a traceable decision, response, and null-finding record.** Confidence: high. Scope: DevRel and product research. These candidates and cross-vault links are review inferences. Do not attribute their wording to Kalbach. ## PROMPT 11 — Teaching pack ### Audience and objectives For product, DevRel, customer support, design, research, and community teams. Learners should be able to: 1. distinguish job performer, buyer, and affected actor; 2. write a solution-independent main job with stated circumstances; 3. explain job-map versus journey-map scope; 4. build a consented discovery plan and a decision trail; 5. state what qualitative interviews can and cannot establish. ### Four-session sequence | Session | Activity | Misconception check | | --- | --- | --- | | 1. Scope the job | Turn a feature request into performer, job, process, need, and circumstance hypotheses | A job is not a feature or persona label | | 2. Map actors | Identify performer, buyer, approver, reviewer, audience, and affected people | The payer is not necessarily the user | | 3. Conduct discovery | Draft recruitment, consent, and open interview prompts | A five-person sample cannot estimate market share | | 4. Make a decision | Compare job map, journey map, and evidence needed for a reversible change | A research insight has no value until a decision can be inspected | ### Facilitator cautions - Do not conduct covert research in a community, support channel, or workplace. - Do not teach “functional first” as a reason to defer safety, accessibility, or dignity. - Do not present company case stories as proof of a universal return. - Do not turn a job statement into a profile of someone’s identity. ## PROMPT 12 — Action, PARA, experiments, and drift ### Action inventory - **Take:** write a one-page research brief that names main job, performer, circumstances, affected people, and decision. - **Consider:** use a job-map/journey-map comparison when a DevRel or product team has conflicting explanations for a friction point. - **Avoid:** running interviews only to confirm a chosen roadmap, campaign, or engagement target. - **Need more evidence:** whether an outcome survey is valid enough to rank a decision. The most likely misuse is treating “customer needs” as permission to extract intimate context or turn community participation into a purchase funnel. The safeguard is a consent statement, minimal data collection, a documented benefit to participants, and a public response path for feedback. ### Reversible experiments | Experiment | Hypothesis | Measure | Stop condition | | --- | --- | --- | --- | | Scope a documentation problem | A main-job map reveals a different friction than a feature request | Evidence-backed problem statement and decision | Stop if no participant-facing benefit is clear | | Run 5–6 consented discovery interviews | Actual performers name recurring process constraints | Coded themes, contradictions, and coverage gaps | Stop if recruitment excludes people with material access needs | | Compare map types | Job and journey maps produce different decisions | Decision log and stakeholder review | Reject if they create duplicate ceremony | | Map an enterprise actor chain | Buyer and performer needs diverge in a visible way | Actor map and trade-off record | Stop if participant data could reach performance management | | Record a null result | An assumed need does not survive participant evidence | Retained negative finding | Do not recast the null as an opportunity | ### Decision rules and drift Adopt a play when it makes the decision, evidence boundary, and participant benefit clearer. Adapt it when job language works but actor, access, or social conditions need expansion. Defer an opportunity rating without a validated instrument. Reject any plan that needs hidden identity inference or coercive data collection. Review methods annually and on changes to AI-assisted research, privacy policy, recruitment availability, accessibility requirements, or a major change in the target job’s circumstances. The historical account of JTBD schools and the local source record do not need recurring review. ## PROMPT 13 — Visual thinking pack ### JTBD ecosystem ```mermaid flowchart LR P["Job performer"] --> J["Main job\nobjective under circumstances"] J --> PR["Process / job map"] PR --> N["Desired outcomes / needs"] B["Buyer"] --> S["Solution decision"] A["Approver, reviewer, technician, manager, audience, assistant"] --> S N --> S X["Access, consent, affected people, power"] -.-> P X -.-> S ``` ### Map distinction ```mermaid flowchart TD J["Job map\nPerson's independent objective and process"] --> D["Discover unmet outcomes"] C["Journey map\nInteraction with a specific organization or offering"] --> E["Improve acquisition, use, support, retention"] D --> F["Product or service hypothesis"] E --> F G["Participant evidence and contradictory cases"] -.-> D G -.-> E ``` ### Comparison matrix | Question | Kalbach’s Playbook | Burleson’s Pyramid | | --- | --- | --- | | How do we collect evidence? | Interviews, Switch accounts, job maps, outcomes | Refers to research; strongest value is a synthesis structure | | How do we distinguish actors? | Explicit job ecosystem | Job executor persona is primary, other roles less developed | | How do we handle motivation? | Functional main job plus social/emotional aspects | Product, Core, Role, Image, and Emotional layers | | What is the main risk? | Weak sampling or incomplete method | Unvalidated taxonomy and inferred identity | | Recommended order | Start with Kalbach’s research discipline | Add Pyramid layers only if they sharpen a live decision | No timeline is included because the source’s historical overview is secondary to its methodological use. No causal-loop diagram is included because the book does not establish feedback loops strongly enough for a reliable system model. ## Session completion check | Check | Result | | --- | --- | | EPUB integrity and source identity verified | PASS | | Complete source coverage recorded | PASS | | Reader-emphasis loss disclosed | PASS | | Prompts 0–13 have usable outputs | PASS | | Prompt 7 uses Prompt 5 policy and Prompt 6 scaffold | PASS | | Author claims, cases, and review inference separated | PASS | | Methods and evidence limits stated | PASS | | Accessibility, consent, power, and inclusion review included | PASS | | Existing vault connections verified as outbound links | PASS | | One-file constraint honored | PASS | ### Final verdict This is the stronger of the two current JTBD books in the vault for beginning real discovery work. Kalbach gives teams a useful grammar for actors, scope, job statements, interviews, maps, needs, delivery, and organizational follow-through. Use the playbook’s research discipline first. Use Burleson’s extra identity categories only when participants’ own evidence makes the distinction decision-relevant. In either case, keep circumstances, access, consent, affected people, and a traceable response path visible. JTBD improves questions; it does not excuse a team from listening, validating, and accepting a null result.