---
title: "AI for Jobs to Be Done Research, a Guide"
description: "Pull job statements out of real transcripts with AI without letting the model invent the struggling moment, plus the check that catches a fabricated job."
canonical_url: "https://builderscamp.com/guides/tools/ai-for-jobs-to-be-done-research"
date_published: "2026-09-18"
date_modified: "2026-09-18"
author: "Andre Albuquerque, Mihaela Draghici"
publisher: "Builders Camp"
guide_class: "tools"
---

# How to use AI for jobs to be done research on real transcripts

**TL;DR:** A job statement is only as good as the struggling moment behind it, and that is the exact part a model invents first, because interviews rarely state it outright. Require a quoted passage where the participant narrates the specific occasion the old way stopped working, and mark any job without one as unconfirmed. Torres' floor of three to four story-based interviews before a first opportunity tree is a sensible floor here too.

## What are you actually asking the model to find?

Not a theme. A job to be done, in the framing Clayton Christensen set out for Harvard Business Review, is the progress a person was trying to make in a particular circumstance. Three things have to be present in the statement: the progress, the circumstance, and the person's own criteria for whether they got there. Strip any of the three and you have a persona attribute or a feature request wearing better clothes.

That matters for prompting because "find the jobs to be done in these transcripts" produces themes with the word job in front of them. The model has read a great deal of writing about jobs to be done and will happily generate statements in the correct grammatical shape. Shape is free. What you are paying for is whether a real person, in a real week, actually did the thing the statement claims.

## Why the struggling moment is the part AI invents first

The struggling moment is the occasion the old way stopped working and the person went looking. It is the load-bearing element of the whole framework, and it is the one that is usually absent from an interview transcript, because people narrate their current behaviour far more readily than the switch that produced it.

A model reading around that absence will fill it. The filled version is always plausible: the participant complained about a spreadsheet, so the model writes that they hit a breaking point when the spreadsheet grew past what they could track, which is a completely reasonable thing to have happened and may well be true. It is also not in the transcript. The finding now carries a fabricated origin story, and the origin story is the part that gets quoted in the roadmap discussion, because it is the part that makes the job feel real.

The fix is structural rather than clever. Every job statement carries a column called "moment", and that column holds a quoted passage in which the participant narrates a specific occasion. Not a summary of one. If there is no such passage, the job is recorded as unconfirmed, and the next interview has an obvious question waiting for it.

## How do you get a job statement out of a transcript without corrupting it?

Four passes, each one narrow enough to check:

- **Pass one, extraction only.** Ask for every passage where the participant describes something they did, with timestamps or line references, and no interpretation at all. Anthropic's own guidance for long documents is to have the model pull word-for-word quotes before it does any analysis, precisely because it grounds everything that follows.
- **Pass two, the switch.** From that extraction, ask for any passage describing a change in how they did something and what preceded it. Most transcripts yield one or two. Some yield none, and that is a finding about the interview.
- **Pass three, the statement.** Draft the job from the quoted material only, with an explicit instruction that any element not present in the quotes must be written as "not stated" rather than inferred.
- **Pass four, the challenge.** Ask the model to argue that the job statement is wrong, using only the same quotes. A statement that survives its own best counterargument is worth taking into a room.

Run these as separate prompts with the output of each saved to a file. Doing it in one conversation lets the model's first interpretation leak into every later step, which is the same reason human researchers are told to code before they cluster.

## What separates a job from a feature request in the output?

A job survives the disappearance of your product. "Export to CSV" evaporates if your product does not exist. "Get last quarter's numbers into the shape my finance lead accepts without re-keying them" persists, and once written down it explains why three unrelated feature requests keep arriving from the same account.

The practical test is to read each statement and ask whether it names any part of your interface. If it does, it is a solution the participant proposed, which is useful information about their mental model and terrible information about their goal. Nielsen Norman Group's guidance on interviewing users is the reason this keeps happening: what people say and what they do differ, memory is unreliable, and people construct rationalisations after the fact. A participant asked why they want a feature will produce a fluent answer that is not necessarily the reason.

The same source points at the repair. The critical incident method, asking about the specific occasion that went unusually badly or unusually well, produces material with actual behaviour in it, because vivid cases stay sharp while the average week has already blurred into an idealised version.

## How many interviews before the statement is worth anything?

Torres recommends three to four story-based customer interviews before a team builds its first opportunity solution tree, and the same floor works here. Below it, a model will still produce one confident job statement, and the confidence is coming from the model rather than from the data. Above it, you start seeing the same circumstance described in different words by different people, which is the only real signal that the job exists outside of one person's week.

Torres also draws a line that survives into AI-assisted work: opportunities on the tree come from interviews, because generating them from what the team already knows imports the team's own biases and half-truths. Support tickets and sales conversations are missing context, so they belong upstream as inspiration for what to explore, not as direct inputs. A model trained on the whole internet is that problem in a more articulate form, and it is why the extraction-first sequence above matters more than the prompt wording.

## What happens to the job statement next?

It becomes the root of a decision, not a document. The clean handoff is into an opportunity structure: the job and its circumstances at the top, the specific unmet needs underneath, candidate solutions below those, and an assumption test attached to whichever solution you are least sure about. See [the opportunity solution tree](https://builderscamp.com/guides/glossary/opportunity-solution-tree) for the structure and [jobs to be done](https://builderscamp.com/guides/glossary/jobs-to-be-done) for the definition it sits on.

Builders Camp teaches the front half of this in AI Prompting for Customer Discovery, a 1 week bootcamp covering hypothesis-driven discovery, interview planning prompts, thematic synthesis and insight-to-decision, whose practical challenge requires each theme to carry a supporting quote and a stated confidence level. Product Sense covers the judgement layer above it: separating a request from a real problem, working with weak signals and misleading data, and making a defensible call when the evidence does not settle the question. The Discovery Expert Track bundles interviewing, synthesis, opportunity mapping and validation into a single path.

## The sentence that should worry you in a jobs readout

"Customers are hiring us to feel confident about their numbers." It is grammatical, it is in the right framework, it is emotionally resonant, and there is no circumstance in it, no criterion for progress, and nothing you could disprove. Statements like that are what a language model produces by default, because they are the average of everything written about the framework, and they cost you a quarter before anyone notices the job was never observed.

Ask for the moment. If nobody can produce the passage where a real person narrates the week that made them go looking, you have a hypothesis worth testing in the next four interviews, which is a genuinely good place to be, as long as you call it that. For the interview craft that produces those passages, see [AI for customer interviews](https://builderscamp.com/guides/tools/ai-for-customer-interviews) and [how to run customer interviews](https://builderscamp.com/guides/other/how-to-run-customer-interviews).

[See the AI Prompting for Customer Discovery bootcamp](https://builderscamp.com/bootcamps/ai-prompting-for-customer-discovery?utm_source=guide&utm_medium=organic&utm_campaign=ai-for-jobs-to-be-done-research)

## Frequently asked questions

### Can AI write a job statement from a product description alone?

It will, and the result is worthless. A job statement asserts what a real person was trying to make progress on in a real circumstance, and a model given only your product description is reconstructing the job your marketing already implies. Feed it transcripts, or do not run it.

### What is the struggling moment, and why does AI invent it?

It is the specific occasion when the old way stopped working and the person went looking for something else. Models invent it because interviews rarely contain it verbatim, and the surrounding text supports a plausible reconstruction. Require a timestamped or quoted passage where the participant narrates that specific occasion, and mark the job unconfirmed when there is not one.

### How is a job different from a feature request in the output?

A job survives the disappearance of your product; a feature request does not. 'Export to CSV' is a request. 'Get last quarter's numbers into the format my finance lead will accept without re-keying them' is a job, and it explains why three different requests keep arriving. If the statement names your interface, it is not a job yet.

### How many interviews do I need before the job statement is stable?

Torres recommends three to four story-based customer interviews before a team builds its first opportunity solution tree, and that is a reasonable floor here too. Below it, a model will produce one confident job statement from three anecdotes, and the confidence is coming from the model rather than the data.

### Should the prompt ask for functional, emotional and social dimensions?

Ask, but require evidence separately for each. The functional dimension is usually stated outright in an interview. The emotional and social dimensions are inferred, and inference is where a model starts writing fiction that reads like insight. Keep the inferred dimensions in their own column, marked as inference, so nobody quotes them as findings.

### Can I use support tickets instead of interviews?

As a source of things to ask about, yes. As the basis for a job statement, no. Torres makes the same point about sales conversations and support tickets: they are missing context, so they work as inspiration for what to explore in upcoming interviews rather than as direct inputs.

### Where does Builders Camp teach this?

AI Prompting for Customer Discovery is the closest match: 1 week covering hypothesis-driven discovery, interview planning prompts, thematic synthesis and insight-to-decision, with a practical challenge that requires every theme to carry a supporting quote and a confidence rating.

## Sources

- [Harvard Business Review: Know Your Customers' Jobs to Be Done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done)
- [Product Talk: Why I Prefer Opportunity Solution Trees](https://www.producttalk.org/2016/08/opportunity-solution-tree/)
- [Nielsen Norman Group: Interviewing Users](https://www.nngroup.com/articles/interviewing-users/)
- [Anthropic: Reduce hallucinations](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations)
- [Builders Camp: AI Prompting for Customer Discovery](https://builderscamp.com/bootcamps/ai-prompting-for-customer-discovery)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.