Most product teams have a jobs-to-be-done framework. It lives in Notion or Confluence, it was assembled by someone who read Christensen or attended a workshop, it gets cited in strategy decks, and it is almost never touched again during user interviews.
The interviews happen. Notes accumulate. Synthesis produces themes. Those themes go into a report. The JTBD framework is not consulted. The two documents never connect.
This is the gap that makes qualitative research expensive to defend. You have a theory of your customer (the JTBD framework) and you have raw evidence (the interviews). You're doing them in parallel without asking: what does this evidence say about that theory?
How JTBD Frameworks Get Used in Practice
Clayton Christensen's formulation of jobs-to-be-done — the idea that customers "hire" products to make progress in specific circumstances — was always intended as a lens for understanding demand, not just a strategic taxonomy. In Competing Against Luck, Christensen and co-authors describe how deeply understanding a job changes what you look for in customer research. The job statement isn't just a label; it's a structured hypothesis about what the customer is trying to accomplish and why.
But in most product orgs, the JTBD framework gets flattened into a strategy artifact. You have a list of four to eight job statements. You reference them when talking about product direction. Nobody has operationalized what it would mean to find evidence for or against each job in an individual interview session.
Bob Moesta, who worked alongside Christensen on the demand-side application of JTBD and later wrote Demand-Side Sales 101, has described this as confusing the map for the territory. The JTBD framework is a map. The interviews are dispatches from the territory. Using the map only for strategy — never to read the territory dispatches against — means the map never gets updated and the territory never gets precisely understood.
What "Synthesis Lens" Means Operationally
Using your JTBD framework as a synthesis lens means something concrete: before you run synthesis on an interview, you have your active job statements in front of you, and your synthesis question is "what evidence did this interview produce for each job?"
Not: "what themes can I extract?" That's the affinity approach — it generates new categories from the data.
Instead: "which of my existing jobs did this participant's language map to, and was that mapping clear or ambiguous?" That's the JTBD synthesis approach — it evaluates evidence against a pre-existing theoretical structure.
The practical difference is substantial. When you synthesize with your jobs as the anchor, you get output that directly answers the questions your roadmap is asking. "Three of the five interviews this week produced strong evidence for Job #3 (cross-team coordination), and all three participants described the same obstacle: attachment handling in the handoff step." That sentence goes straight into a roadmap conversation. No translation needed.
The Interview Guide Has to Reflect the Framework
A problem that often surfaces when teams try to apply this: their interview guide wasn't designed to surface JTBD evidence. The questions are feature-focused ("what do you think of the new dashboard?") or satisfaction-focused ("what are your biggest pain points?") rather than job-focused ("walk me through the last time you had to share research findings with someone who wasn't in the interview room").
Moesta's interview methodology — what he calls the timeline interview — works precisely because it anchors questions in specific past events rather than general preferences or attitudes. "Walk me through the last time you did X" surfaces the job context: the circumstance, the progress the person was trying to make, the obstacles they encountered. Generic pain-point questions generate generic pain-point answers that don't map cleanly onto job statements.
The implication is that the JTBD framework needs to inform the interview guide, not just the synthesis step. You write questions that will surface job evidence: they're retrospective, situational, and specific. If you've done this, synthesis becomes dramatically more tractable — the interview data is already organized around the right units of analysis.
The Mapping Step in Practice
Consider how this plays out concretely. A growing B2B SaaS team ran eight interviews in a single discovery cycle, all with senior operations leads at mid-size companies. Their JTBD framework had five job statements. After the first three interviews, their researcher ran a mapping exercise: for each meaningful utterance in each interview, she noted which job it mapped to and how confident she was in the mapping. She flagged any utterance that didn't map to any existing job — potential evidence of an uncharted job.
By interview five, a pattern was visible: all five participants had generated dense evidence for Job #2 (coordinating work across time zones) but almost nothing for Job #4 (onboarding new team members). Job #4 had been a significant investment area on the roadmap. The synthesis was producing a signal that the team's JTBD theory might be wrong about Job #4's importance — or that the interview sample was skewed toward participants who didn't experience it.
Neither of those conclusions was available from an affinity diagram. The affinity diagram would have generated themes from what was said. The JTBD mapping surfaced what wasn't said — which was the more important finding.
What Good Job-Mapped Synthesis Produces
When synthesis is organized around job statements rather than emergent themes, the output has a structure that's useful beyond the immediate research cycle. Each job statement has an evidence file: the quotes that support it, the quotes that complicate it, the sessions that produced no relevant signal. Over time — across multiple studies, multiple interview rounds — this evidence file grows into an institutional knowledge layer.
The PM who joins the team six months later can query: "What have we heard about Job #3 across our last four studies?" The answer isn't buried in a Miro board or a Notion page full of old themes. It's structured evidence, traceable to participants and sessions, organized by the jobs the team is tracking.
GetWhys is built around exactly this workflow. You import your existing job statements — paste them directly, or pull from a Notion table — and every interview you synthesize gets themed against that framework. Each quote card carries a job tag, a confidence score, and a direct link back to the transcript segment that generated it. The synthesis output is a running evidence file for your JTBD theory, not a one-time report.
The Limit of This Approach
It's worth being honest about when this method creates friction. If you're in genuinely early discovery — pre-product, or exploring a new market where you don't yet have a JTBD framework — forcing everything through existing job statements will make you miss signals. The emergent-theme approach has a real advantage in exploratory contexts: it surfaces what you didn't know to look for.
We're not saying JTBD-anchored synthesis replaces exploratory research. The right sequence is: use exploratory methods to build your initial framework, then shift to framework-anchored synthesis once you have jobs worth tracking. The mistake most teams make isn't that they use affinity methods in early discovery — it's that they keep using them in evaluative and directional work, long after they have a framework worth leveraging.
The other friction point: the quality of the synthesis is only as good as the quality of the job statements. If your JTBD framework is vague — job statements that are really just solution descriptions dressed up as jobs — the synthesis will be vague too. Getting the framework right is upstream work that pays dividends every time you run an interview round. Teams that invest in that work report that their research findings become dramatically more actionable, and that the translation step between "what users said" and "what we should build" compresses significantly.
That compression is the whole point. An interview costs a researcher half a day. A synthesis session costs another two hours. If the output of that investment is a cluster map that requires another translation step before it can inform a decision, a significant portion of that investment is being consumed in overhead. JTBD-anchored synthesis eliminates the overhead by making the translation step part of the synthesis itself.