# Common JTBD failures Nine-plus failure patterns with diagnoses and cures. The cross-cutting pattern: most JTBD failures share a single root, which is treating JTBD vocabulary as a substitute for analytical work. --- ## Failure 1: We did the JTBD workshop but nothing changed in our roadmap **Symptom.** A workshop was held. Job statements were produced. The wall has Post-its. The next quarter's roadmap looks the same as the prior quarter's. **Diagnosis.** Job-statement workshop as deliverable. The workshop became the artifact; the analytical work that should have followed never happened. **Cure.** Treat job statements as analytical input, not as workshop output. Re-evaluate roadmap candidates against the jobs. Apply the "no job, no priority" discipline. The roadmap should look different than it would have looked without the JTBD work; if it does not, the work is ritual. **Prevention.** Do not run JTBD workshops as standalone events. Pair the workshop with prioritization or positioning work that uses the job statements as input. Without downstream application, the workshop produces ritual. --- ## Failure 2: Our job statements all sound the same **Symptom.** Multiple job statements share similar situations, motivations, or outcomes. They are hard to distinguish. **Diagnosis.** Generic job statements; not grounded in specific struggling moments. The statements were written from intuition rather than from interview data. **Cure.** Re-ground in interview data. Each job should be traceable to specific moments in specific interviews. Statements that cannot be traced are projections; rewrite from the ground up. **Prevention.** Job statements emerge from clustering, not from whiteboard sessions. The clustering work surfaces the distinctions; whiteboard sessions tend to produce homogeneous statements. --- ## Failure 3: Our jobs read like feature requests **Symptom.** Job statements describe what users want from the product, not what users are trying to accomplish. **Examples that fail.** - "When using the dashboard, I want to see all my metrics on one screen." - "When in the settings page, I want to configure permissions easily." The motivations and outcomes describe product features, not job-doing. **Diagnosis.** Product-bound job statements. The motivation is bound to the product; the outcome is feature output. **Cure.** Apply the product-independence test. The motivation should make sense without naming any specific product. If the user is "in the dashboard," they are using a product; the underlying job is what they are trying to accomplish that brought them to the dashboard. **Prevention.** During job-statement writing, check each statement: could this make sense if the user had no product to use? If no, rewrite the motivation and outcome to describe the underlying job. --- ## Failure 4: We have personas and jobs and they contradict each other **Symptom.** The team has both demographic personas and JTBD job statements. Decisions get made differently depending on which framework the conversation invokes. **Diagnosis.** Personas are demographic; jobs are situational. They serve different purposes. Conflict often signals confusion about which framework drives which decisions. **Cure.** Decide the role of each framework. JTBD is usually better for product decisions (what to build, how to prioritize); demographic personas are sometimes useful for marketing audience targeting (who to advertise to). Use each where it adds clarity; do not require both for every decision. **Prevention.** When introducing JTBD, surface the relationship to existing personas. If personas are not driving decisions, consider deprecating them. If personas are useful for specific marketing work, keep them but separate from product decision-making. --- ## Failure 5: JTBD says we should build everything **Symptom.** Job statements identify many job-improvement opportunities. The team cannot pick. The roadmap becomes a list of all the jobs to address. **Diagnosis.** Without prioritization across jobs, JTBD identifies opportunities but does not pick. The framework is doing its discovery work; it is not doing prioritization work. **Cure.** Pair JTBD with strategic weighting (which jobs matter most for the strategy?), capacity constraints (what can the team actually deliver?), and impact estimation (which job improvements move the needle most?). JTBD informs prioritization but does not replace prioritization frameworks. **Prevention.** When applying JTBD to roadmap prioritization, surface the strategic-weight question explicitly. Some jobs matter more than others; the team's strategy decides which ones. --- ## Failure 6: We dropped JTBD because it became theater **Symptom.** The team adopted JTBD; produced workshop artifacts; never used them in decisions; and concluded JTBD does not work. **Diagnosis.** JTBD as ritual produced ritual. The framework was applied without the analytical work. **Cure.** Reintroduce JTBD as analytical tool, not as ritual. Apply where it earns its keep (discovery, prioritization, positioning). Skip the artifacts that decorate without informing decisions. Demonstrate the value through specific decisions JTBD informed. **Prevention.** When introducing JTBD, frame it as a tool for specific decisions, not as a methodology to be adopted org-wide. Start with one application (one discovery cycle, one prioritization debate) and show value before expanding. --- ## Failure 7: Our job statements are functional only **Symptom.** Job statements describe mechanical tasks. The product strategy prioritizes functional features. The product wins on functional dimension and loses to alternatives on emotional and social. **Diagnosis.** Functional-only synthesis. The interview prompts and synthesis stayed at the functional dimension; emotional and social dimensions were not surfaced. **Cure.** Re-interview a subset of users with emotional and social prompts. Add the dimensions to existing job statements. Re-evaluate strategy considering all three dimensions. **Prevention.** Interview structure should explicitly prompt for all three dimensions. Synthesis should surface all three. Single-dimension job statements are usually a sign that prompts or synthesis missed dimensions. --- ## Failure 8: We cannot agree on the job **Symptom.** Different team members describe the user's job differently. The team debates the framing; the framing does not converge. **Diagnosis.** Often signals different segments with different jobs. The team is right that there is more than one job; they are wrong to think there should be one consensus job. **Cure.** Surface the segment differences. The same product may serve different jobs for different segments. Naming the segments and their distinct jobs resolves the disagreement and improves strategy. **Prevention.** When defining jobs, ask explicitly: do all target users share this job, or does it differ across segments? Often the answer is "differs"; surface the segments rather than forcing consensus. --- ## Failure 9: Our marketing copy uses JTBD vocabulary but our product does not **Symptom.** Marketing positioning describes the job the product helps users accomplish. The product itself is built around feature-list thinking. Users adopt expecting one experience and encounter another. **Diagnosis.** Positioning-product gap. The marketing claim is not load-bearing in product decisions; product decisions are still made on feature-list grounds. **Cure.** Either align product decisions to the JTBD positioning (apply JTBD to prioritization), or revise the positioning to match what the product actually does. The mismatch erodes trust over time. **Prevention.** When introducing JTBD-led positioning, simultaneously apply JTBD to product strategy. Positioning that describes what the product is becoming should drive what the product becomes. --- ## Failure 10: JTBD vocabulary substituted for analytical work **Symptom.** The team uses JTBD language ("the job," "struggling moment," "hire criteria") in conversations but cannot trace decisions to specific JTBD analyses. **Diagnosis.** Vocabulary without analysis is ritual. The framework provides language; the language does not produce decisions on its own. **Cure.** Audit recent decisions: which were grounded in JTBD analysis (specific job statements, specific hire/fire criteria, specific user research)? Which used JTBD vocabulary as decoration around decisions made on other grounds? Re-anchor in analytical work. **Prevention.** When the team uses JTBD vocabulary, surface the underlying analytical work explicitly. "What job is this serving?" should produce a specific job statement traceable to research, not a hand-wavy answer. --- ## Failure 11: Force-fitting JTBD where it does not help **Symptom.** Every product question gets framed in JTBD. Even questions where the framing adds no clarity. **Diagnosis.** JTBD as mandate. The framework gets applied universally; tax for the team; signal-to-noise drops. **Cure.** Use JTBD where it earns its keep. Some questions (technical migrations, infrastructure decisions, urgent bug fixes) do not benefit from JTBD framing. Apply other frameworks where they fit better; apply JTBD where it fits. **Prevention.** Establish that JTBD is one tool among many. Frame the question first; then pick the framework. Do not start with the framework and look for questions to apply it to. --- ## The cross-cutting pattern Most JTBD failures share a single root: treating JTBD vocabulary as a substitute for analytical work. The vocabulary is easy: "job," "struggling moment," "hire criteria," "fire criteria," "functional, emotional, social dimensions." Teams adopt the vocabulary and signal that they have adopted JTBD. The analytical work is hard: structured interviews, struggling-moment grounding, clustering across users, naming jobs from data, surfacing all three dimensions, applying the framework to specific decisions, validating that the analysis informs decisions. When the vocabulary is adopted without the analytical work, JTBD produces ritual. When the analytical work is done with discipline, JTBD produces decisions and the vocabulary is incidental. The fix for almost any JTBD failure starts with the same question: where is the analytical work happening, and what decisions is it informing? If the answers are clear, the framework is doing its job. If the answers are vague, the framework is ritual. --- ## Methodology-level choices that stay in the public skill The eleven failure patterns with diagnoses and cures. The cross-cutting vocabulary-vs-analysis pattern. The discipline of using JTBD where it earns its keep. ## Implementation choices that stay internal Specific JTBD-application audits. Specific reviewer training on failure detection. Specific tooling that surfaces JTBD ritual vs analytical use. The team's own conventions for catching ritual before it spreads. These vary by team.