A Jobs-to-be-Done map is one of the highest-leverage artifacts a designer can carry into a roadmap meeting, because it reframes "what features do users want" into "what progress are users trying to make." Building one by hand from eight interview transcripts used to eat a full day. With Granola, Otter, or Fathom transcripts fed into Claude with a structured prompt, the first draft arrives in fifteen minutes. The trap is that Claude is fluent enough to write a job statement that reads beautifully and is grounded in nothing. This lesson gives you a structured JTBD prompt, a verification pass that forces every job to carry a verbatim quote, and a defensible JTBD canvas you sign with your own name because you checked it, not because the model produced it.

The Job Statement That Sounded Right

A designer feeds eight transcripts about a freelance-invoicing app into Claude and asks for a JTBD map. Out comes a clean canvas with eight job statements, each in the textbook format. Job number two reads: "When I finish a project, I want to feel confident I will be paid, so I can focus on the next client." It is grammatically perfect, emotionally resonant, and structurally flawless. Everyone in the review loves it. Then the lead asks, "what did a user actually say that maps to 'feel confident I will be paid'?"

The designer scrolls. The closest real utterance is from participant six: "I send the invoice and then I just have no idea if they even opened it." That is not "feeling confident about payment." That is a specific, observable gap about invoice-status visibility. The model had taken a concrete functional job (know whether my invoice was received) and rewritten it as a fuzzy emotional job (feel confident about payment) because emotional job statements are abundant in the JTBD writing it trained on. The statement was plausible. It was also ungrounded, and it would have steered the team toward reassurance messaging when users actually needed a read receipt.

This is the JTBD-specific version of the synthesis trap. The framework's own conventions, the "when, I want to, so I can" grammar and the functional-emotional-social layering, are exactly the patterns the model reproduces most fluently and grounds least reliably. The more textbook-correct the canvas looks, the harder you have to check it.

Why JTBD Is Uniquely Vulnerable to Fluent Fabrication

Jobs-to-be-Done has a large, well-written public corpus: books, blog posts, case studies, conference talks. That corpus taught the model what a good job statement sounds like with extraordinary precision. The result is that Claude can generate job statements that pass the eye test of any JTBD practitioner while having only loose contact with your eight participants. The fluency is the danger. A clumsy, obviously-wrong output gets caught. A polished, framework-perfect output gets approved.

The Functional, Emotional, and Social Trap

JTBD distinguishes functional jobs (the practical task), emotional jobs (how the user wants to feel), and social jobs (how the user wants to be perceived). Models love to populate all three layers for every job because complete-looking frameworks are well-represented in training data. But your eight participants may have expressed only functional jobs clearly and barely touched the emotional or social layers. When the model fills the emotional and social rows anyway, it is inventing, not synthesizing. The empty cell is a more honest artifact than the plausibly-filled one. Resist the pull to complete the framework when the evidence does not support it.

The Structured JTBD Prompt That Forces Grounding

The single most important tool in this lesson is the prompt, because a loose prompt invites fluent fabrication and a tight one constrains it. Here is the structure to use with Claude, adaptable to your domain.

Instruct the model explicitly: "From these eight transcripts, extract Jobs-to-be-Done. For each job, you must output four fields. One, the job statement in the format 'When [situation], I want to [motivation], so I can [outcome].' Two, the single verbatim quote from the transcripts that most directly supports this job, copied exactly, with the participant number. Three, the job type: functional, emotional, or social. Four, how many of the eight participants expressed this job. Critical constraint: if you cannot find a verbatim quote that directly supports a job, do not output that job. Do not invent emotional or social jobs that participants did not express. Leave a layer empty rather than fabricate it. Use only words and meanings present in the transcripts."

That constraint block, the instruction to leave cells empty rather than fabricate and to refuse jobs without a supporting quote, is what converts Claude from a confident author into a constrained extractor. It will produce fewer jobs. The fewer jobs will be real.

A JTBD map is only as good as the worst-grounded job on it. One fluent fabrication does not just waste a row; it makes the reader doubt the eight rows you got right.

The Verification Pass: Quote-Pull for Every Job

Even a tightly-prompted model needs verification, because constraints reduce fabrication but do not eliminate it. The pass is mechanical and fast once you make it a habit. For each job on the draft canvas, do four things.

First, open the cited transcript at the participant number given and confirm the verbatim quote exists, exactly, in context. Second, confirm the quote actually supports the job statement, not a smoothed version of it; the invoice example fails here because "no idea if they opened it" does not support "feel confident I will be paid." Third, confirm the job-type label matches what the user expressed, downgrading invented emotional jobs to the functional job they actually stated. Fourth, confirm the participant count against the transcripts, replacing any vague count with a verified fraction.

Mark each job verified, regrounded, or cut. "Regrounded" is the status that earns its keep: it is where you kept a real job but rewrote the statement to match the user's words instead of the model's. The invoice job becomes "When I send an invoice, I want to know the client received and opened it, so I can stop wondering whether to follow up." That is grounded, specific, and designable.

The Defensible JTBD Canvas You Sign

The artifact is a JTBD canvas built for review, not for decoration. It is a table or FigJam board with one row per verified job and these columns: the job statement, the job type, the verified participant fraction, the single strongest verbatim quote with participant number, and a priority weight. The priority weight is your judgment, not the model's: it combines frequency (how many participants) with intensity (how strongly they expressed it) and reach (how many users the job likely affects). You assign it because prioritization is design judgment grounded in evidence, and the model has no stake in your roadmap.

At the bottom of the canvas sits the line that makes it defensible: a sign-off that reads "Synthesized with Claude from eight transcripts; every job verified against a verbatim quote by [your name] on [date]." That signature is not ceremony. It is a claim of accountability. You are stating that you, a human, checked every job against a real human utterance, and that you stand behind the map. A canvas without that line is a draft. A canvas with it is an artifact.

Why the Signature Changes the Conversation

When you sign a JTBD map, the conversation in the room shifts from "do we trust the AI" to "do we trust the priority weights." That is a much better conversation, because the weights are your defensible judgment and the jobs are verified facts. The signature moves the locus of trust to where it belongs: on the designer's evidence-backed judgment, not on the model's fluency. It also makes you read the map more carefully, because your name is on it.

The Three JTBD Failures to Catch by Name

Across many AI-generated JTBD maps, three failures recur. Naming them speeds your verification.

Failure One: The Emotional Upgrade

The model rewrites a concrete functional job as a fuzzy emotional one because emotional job statements dominate the JTBD corpus. "Know whether my invoice was opened" becomes "feel confident I will be paid." Catch it by checking the job type against the actual utterance, and downgrade invented emotional jobs to the functional reality. Functional jobs are usually more designable anyway, because they point at an observable gap.

Failure Two: The Framework Completion Reflex

The model fills every functional, emotional, and social cell for every job because complete frameworks look right. Catch it by treating empty cells as valid output. If your participants did not express a social job for a given situation, the social cell stays empty, and the map is more honest for it.

Failure Three: The Merged Job

The model collapses two distinct jobs from different participants into one tidy statement because consolidation reads as insight. "Get paid faster" might merge a job about invoice visibility with a separate job about payment-terms negotiation. Catch it by checking whether the single cited quote really covers the whole job statement; if the quote supports only half of it, the job is two jobs wearing one label, and you split it.

Putting It to Work This Week

Take eight real transcripts from Granola, Otter, or Fathom and run the structured prompt with the constraint block intact. Then run the four-step verification pass on every job, marking each verified, regrounded, or cut. Assign your own priority weights. Sign the canvas with your name and date. Bring it to the roadmap meeting and watch the conversation move to the weights instead of the trust.

You will know it is working when you cut a job that read beautifully because no participant actually said it, and the map gets shorter and stronger at the same time. The discipline that matters here is not generating the canvas, which the model does in minutes. It is the willingness to delete a fluent, plausible job statement that has nothing under it, and to leave a cell empty rather than fill it with something that merely sounds like research. That willingness is what your signature certifies, and it is what makes a JTBD map survive contact with a roadmap.

Why You Synthesize Jobs and Not Features

It is worth pausing on what the JTBD frame buys you, because the discipline of grounding is only valuable if the artifact it produces is the right artifact. A feature list is a record of what users asked for. A jobs map is a record of what users were trying to accomplish, and those are very different things. Users are notoriously good at requesting solutions and notoriously bad at diagnosing their own problems. The freelancer who said "I just have no idea if they even opened it" might, two minutes later, ask for "an email-confirmation feature." If you synthesize the feature request, you build a confirmation email. If you synthesize the job behind it, "know that my invoice was received so I can stop wondering whether to chase it," you discover that a read receipt, a status badge in the app, and a gentle nudge to the client are all candidate solutions, and the confirmation email might be the weakest of the three.

This is precisely why the model's fluent fabrications are so costly in a JTBD context. When the model invents an emotional job, it is not just adding an unverified row; it is quietly substituting its own theory of what users want for the evidence of what they were trying to do. "Feel confident I will be paid" points your whole team toward reassurance and trust-building. "Know my invoice was opened" points them toward visibility and status. Those are different roadmaps with different costs, and the only thing standing between them is whether you grounded the job in the participant's actual words. The grounding pass is not bureaucratic hygiene. It is the difference between solving the problem the user had and solving the problem the model imagined.

The Job Story as a Grounding Variant

If you find your team arguing about the "When, I want to, so I can" grammar instead of the substance, switch to the job-story format as a forcing function: "When [situation], I want to [motivation], so I can [expected outcome]," rewritten in the participant's own register. The value of the job story for AI-assisted synthesis is that it is harder to fake. A generic JTBD statement can be assembled from corpus patterns; a job story tied to a specific situation ("when I send an invoice on a Friday and hear nothing by Tuesday") demands a real moment from a real transcript. Use the format that makes fabrication most obvious in your domain, and treat the situation clause as the part you verify hardest, because the situation is the piece the model is most likely to genericize into "when I finish a project" when the participant actually said something far more specific and far more useful.

From Canvas to Roadmap Without Losing the Grounding

A verified JTBD canvas is not the end of the story; it has to survive the trip into a prioritization conversation, and that is where well-grounded maps often quietly lose their grounding. The failure mode is subtle. A product lead looks at eight jobs, picks the three that match the quarter's theme, and the verbatim quotes that justified the other five evaporate from the conversation. Six weeks later nobody remembers that job four was the most intensely expressed problem in the entire study, because it did not fit the theme and there was no quote in the room to defend it. Carry the quotes forward. When a job gets deprioritized, the canvas should record why, in one line, next to the quote that still argues for it. "Deprioritized this quarter despite 6 of 8 frequency; revisit in Q4" is a sentence that protects a real user need from being silently dropped.

The priority weight you assigned earlier is the hinge here, so be honest about what it is and is not. It is a structured judgment that combines frequency, intensity, and reach, and it is yours, not the model's. But a weight is a starting position for a conversation, not a verdict that ends one. The most common mistake designers make with an AI-accelerated JTBD map is treating the speed of generation as if it confers authority on the prioritization. It does not. The model can extract jobs fast; it cannot tell you which job matters most to your business, your users, and your quarter. That synthesis of evidence and context is the part of the work that is most yours, and it is the part you should slow down for even when everything upstream went fast. The whole point of buying back a day with AI synthesis is to spend a few of those reclaimed hours on the judgment that actually decides what your team builds.

Why Eight Transcripts Is the Floor, Not the Target

Eight is a deliberate number, and understanding why protects you from two opposite mistakes. Below roughly six to eight interviews, you do not have enough cross-participant repetition for the participant-fraction column to mean anything; a job stated by "2 of 4" is noise dressed as signal. Above eight, the volume starts to exceed what you can hold in your head, which is exactly the condition under which an ungrounded model job survives because no human reviewer remembers the raw material well enough to flinch. Eight transcripts sits in the sweet spot: enough repetition that frequencies are meaningful, few enough that you can personally re-read every cited quote during verification. If you scale past eight, do not scale your trust in the model along with it. Scale your verification instead, and consider splitting the synthesis into two passes of equal size so each pass stays human-checkable.

Key Takeaways

• A JTBD map reframes "what features do users want" into "what progress are users trying to make," and Claude can draft one from eight transcripts in fifteen minutes, but its fluency with JTBD conventions makes it grounded in nothing unless you verify.
• JTBD is uniquely vulnerable to fluent fabrication because a large, well-written public corpus taught the model exactly what a good job statement sounds like, so polished, framework-perfect outputs pass the eye test while barely touching your participants.
• Use a structured prompt with a hard constraint block: every job must carry a verbatim quote with a participant number, and the model must leave functional, emotional, or social cells empty rather than fabricate them.
• Run a four-step verification pass per job: confirm the quote exists, confirm it supports the statement, confirm the job-type label, confirm the participant count. Mark each verified, regrounded, or cut.
• The three JTBD failures to name: the emotional upgrade (a functional job rewritten as a fuzzy emotional one), the framework completion reflex (filling every cell whether or not participants expressed it), and the merged job (two distinct jobs collapsed into one tidy statement).
• Ship a defensible JTBD canvas with your own priority weights and a signature line certifying that you verified every job against a verbatim quote. The signature moves the room's trust from the model's fluency to your evidence-backed judgment.