Interview for the decision, not the demographic profile
A job is the progress someone wants in a particular situation. “VP of Marketing at a mid-market SaaS company” describes a role, but it does not explain why that person changes tools this month. A useful interview reconstructs a recent decision: what made the old way inadequate, what alternatives were considered, who had to agree, and what remained risky.
Ask for specific events instead of opinions about ideal products. “Tell me about the last board report that was difficult to prepare” is more informative than “Would you use an AI board-report tool?” Follow the timeline from first frustration to shortlisting, purchase, rollout, and later evaluation. Capture exact language, but distinguish what one person said from a pattern across interviews.
| Research lens | Interview prompt | Possible content use |
|---|---|---|
| Trigger | What happened before you looked for a change? | Problem-focused opening |
| Desired progress | What would be different if it worked? | Outcome explanation |
| Anxiety | What made a new option feel risky? | Proof and implementation detail |
| Existing habit | What kept the current process in place? | Migration guidance |
Synthesize carefully
Group interview notes by situation and desired progress, not only by job title. Look for recurring triggers, constraints, and decision criteria. A researcher should keep links to the original notes so a strong quote does not become a universal claim. Public discussions and reviews can add hypotheses, but they may overrepresent unusually vocal users. Validate important patterns in direct conversations.
Write job statements in a concrete form: “When [situation], I want to [make progress] so I can [outcome].” Pair each with the anxieties and evidence needed to move forward. For example, a team preparing executive reports may want traceable recommendations, but worry that automated synthesis will hide assumptions. The message should show the evidence trail and review process, not simply promise “instant strategy.”
Use jobs to improve the journey
Map each job to an article, product explanation, proof page, or sales conversation. Check whether the content answers the buyer's next question and reduces uncertainty. Test messages in interviews or small campaigns, then revise them. Jobs-to-be-Done is useful because it keeps the team close to buying context; it does not guarantee that every job or objection has been discovered.
Reconstruct a recent buying journey
Interview someone who has already made or seriously evaluated a choice. Begin before the vendor search: what changed in their organization, and why did the old approach stop being adequate? Trace the first conversation, alternatives considered, constraints raised by colleagues, and the moment a new option became plausible. Ask what they actually did rather than inviting a prediction about what they might do next year.
Take notes in the buyer's language and separate observation from interpretation. “Our board asked for source links” is evidence; “all CMOs prioritize auditability” is an unsupported leap. Compare several journeys to find recurring situations. People with the same title may be solving different jobs, while people in different functions may share one urgent workflow.
Turn a job into a content hypothesis
Write a job statement with the triggering situation, desired progress, and outcome. Pair it with the habits and anxieties that keep the buyer in the current process. Then map the next question to content: a walkthrough for implementation risk, a comparison for tradeoffs, or a proof page for credibility. The interactive builder below can help draft wording, but it cannot replace an interview.
Test the language back with buyers. Ask whether it describes their decision accurately, which part feels generic, and what evidence they would need to move forward. Update the job statement when a new segment or buying situation emerges. A JTBD map is a working research artifact, not a claim that the team has found every motive or objection.
Questions to settle when writing a job statement
Is a buyer job the same as a feature request?
No. A feature request describes a possible solution; the job describes progress sought in a situation. “Export to slides” might be requested because the buyer needs to defend a quarterly investment decision. Interview around the event, constraints, and desired outcome before turning the requested feature into the entire strategy. A different solution might satisfy the same job better.
How do we know a job is shared?
Compare several completed or serious buying journeys. Look for recurring triggers, desired progress, and anxieties across interviews, while preserving meaningful segment differences. A vivid quote from one person is a hypothesis, not a universal pattern. Public reviews can suggest questions but should not replace direct evidence from your buyers.
Copy this interview synthesis card
Record recent decision, triggering event, previous workaround, alternatives, desired progress, people involved, anxiety, proof needed, and verbatim supporting quote. Write a job statement only after linking it to the source notes. Test the wording back with buyers and map it to content that answers the next decision question. The interactive builder can organize language, but it cannot confirm that a statement reflects a market.