# Nmt Analyze Interviews

> Take one or many customer-interview files and extract the AJTBD structure — segments by Core Jobs and success criteria, personas, Consideration Set, existing Solutions and Problems, value hypotheses — using Ivan Zamesin's AJTBD / Next Move Theory methodology (distinct from generic Christensen JTBD). Input: a folder or files — interview transcripts, notes, sales calls, support logs, survey open-ends; AJTBD or not, one file or dozens (each read in its own subagent, so context never overflows). Asks your business task and market first, extracts Core Jobs with per-interview confidence, clusters into segments, maps every source to its segment. Output — one report: data quality, segments with confidence, per-interview feedback, gaps to interview next. Use when the user says "analyze my interviews", "extract jobs from these transcripts", "find the segments in these calls", "synthesize my interviews". Modes: Quick (default) and Deep (subagents + web). Plain language; defaults to English.

- Skill: `zamesin/nmt-analyze-interviews-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add zamesin/nmt-analyze-interviews-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zamesin/nmt-analyze-interviews-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: zamesin (https://skillmd.com/u/zamesin)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/zamesin/nmt-analyze-interviews-2

---


# Analyze Interviews v1

> **v1 in one breath.** You already ran the interviews; this skill pulls the methodology out of them. It takes **one or many** interview files (transcripts, notes, sales calls, support logs, survey open-ends — AJTBD or not, good or bad), asks **which business task** you're solving (and helps you pick one if you can't), then reads **each interview in its own subagent** — a fan-out that keeps the run from ever overflowing context no matter how many large transcripts you load. Each interview is distilled to the AJTBD constructs with an **honest confidence** (a clean Core-Job extraction vs. a weak hypothesis) and **per-interview feedback** (what was found, what's missing, whether this interview can serve your task). The distillations are clustered into **segments by similar Core Jobs + similar success criteria + similar priority order**, and each segment's confidence is **computed from its supporting interviews' confidence**. Output — one report: data-quality summary, segments with personas, structured Solutions + Problems, a Consideration Set per segment, value hypotheses, and what to interview next.

> **Producer contract (binding) — `../PRODUCER-CONTRACT.md`.** Eleven cross-cutting behaviors shared by all producer skills: (1) print a **helicopter-view** before the first question; (2) ask **Markdown or HTML** output; (3) treat **all** user input as hypothesis and emit a *"risks I see in what you gave me"* block — here the inputs are interviews, so this becomes the per-interview quality read; (4) print **validation framing** — extracted Jobs are hypotheses with a confidence, only as strong as the interviews behind them; (5) accept a **custom output path**; (6) Deep mode runs an **evidence floor + self-critic loop** and offers a **web-MCP fallback**. Five more came from the anti-hallucination pass: (7) ask the **market + audience language** and build every example, channel, and price anchor from it; (8) **list the repo-context files found on disk and read them only after a yes**; (9) every claim carries its **status** — backed, derived, or the model's own hypothesis; (10) **frequency counts on every aggregated claim**, and a single source never carries a segment-level conclusion; (11) **confidence scaled to the input** — thin input gets ranges, a visible warning, and the top-3 inputs that would fix it. The hooks below wire each into this skill.

> **New here, or not sure this is the right skill?** Start right here — or run `/nmt-chat`, describe your situation, and it points you to the right one. Quick map: **new idea →** `nmt-market-research` · **live product or a metric moved →** `nmt-diagnose` · **have customer interviews →** `nmt-analyze-interviews` · **ready to build →** `nmt-product-requirements` · **positioning / launch copy →** `nmt-craft-value-proposition` → `nmt-craft-go-to-market`.

## Where this skill sits

The **post-fieldwork half of the interview loop** — the study design and interview guide *before* the field are a separate (not publicly shipped) product; ask `/nmt-chat` to help you prepare interviews. This skill analyzes the transcripts *after*. Distinct from `/nmt-market-research`, which **invents** segments from web research and reasoning — this skill **reconstructs** segments from *your real interviews* and tells you how far the data can be trusted. Its output feeds `/nmt-craft-value-proposition`, `/nmt-diagnose`, and `/nmt-craft-go-to-market`.

| Skill | Input | Answers |
|---|---|---|
| `nmt-chat` (interview prep) | segment + Job hypothesis | help designing the study before the field |
| **`nmt-analyze-interviews`** | **the interview files you already have** | **what's in them, the segments by Core Jobs, and whether the data can solve your task** |
| `nmt-market-research` | an idea / product | market size + GO/NARROW/PIVOT (segments invented from research) |

## What this skill produces

**A single file** (one file per run — `CLAUDE.md` Rule 4) with:

1. **Data-quality summary** — how many files, the type/quality mix (AJTBD / partial / non-AJTBD; well / poorly conducted), and whether the set can serve the chosen business task.
2. **Segments by Core Jobs** — each with a persona (= the causal criteria), Core Jobs in canon grammar, Big Jobs, **a confidence level and the interviews it stands on.**
3. **What they use today and where it falls short** — for each tool they hired, the set of tasks it does for them, and each problem traced to the task it botched (task → tool → problem). DIY counts as a tool.
4. **What they weighed before choosing** — the options, how they compare, the named products plus a way in, and their fears (their consideration set), as its own block.
5. **Value-creation hypotheses** — underserved success-criteria + a one-line mechanic direction (no feature list — that is `/nmt-craft-value-proposition`'s job).
6. **Single signals** — everything said by exactly one person, held out of the segment conclusions until it's checked.
7. **Hypotheses to validate** — ideas the model added that nobody in your files said, kept clearly apart from the findings.
8. **Source → segment map + per-interview appendix** — every file, its assigned segment, an anchor quote, and what was extracted from it.
9. **Gaps + what to interview next** — what the current data cannot answer for the task, and whom to re-recruit (past-payment screener).

**Two modes:**
- **Quick (default):** no internet. Subagents distill each interview; one Claude synthesizes the segments.
- **Deep (opt-in, longer):** also sends web subagents to enrich the competitor / Consideration-Set picture and mine real review language around the Jobs surfaced. See "Deep mode" at the end.

---

## Methodology — source of truth (progressive loading)

The **only** source of methodology is the Next Move Theory canon, read at runtime. **Don't load all of it up front** — read the eager core first; pull staged files only when the run reaches the stage that needs them.

**Eager core (the orchestrator reads before synthesis — every run):**

| File | What it powers | ~tokens |
|---|---|---|
| `Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/ajtbd-key-theses.md` | the whole model: Job, Job Graph, value, the Aha Moment, the segmentation root | ~13k |
| `Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/segmentation.md` | clustering into segments; causal vs. symptomatic criteria; persona = causal criteria | ~5k |

**Each distiller subagent reads (its slice only):**

| File | Why | ~tokens |
|---|---|---|
| `Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/job-structure.md` | the eight Job elements + the per-element extraction question + the quality signals | ~9k |
| `Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/job-types-and-properties.md` | typing the Job (Fake / Tax / Orientation / Emotional / Viral / Regular); the Fake-Job past-behaviour test | ~5k |

**Staged — the orchestrator loads only at the stage that uses it:**

| File | Load when | Used by | ~tokens |
|---|---|---|---|
| `Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/consideration-activators.md` | writing the Consideration Set per segment | the four-slot container + the five Activators | ~4k |
| `Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/critical-chain.md` | the task is conversion / retention / acquisition | Previous / Next Jobs, chain breaks, Aha placement | ~6k |
| `Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/behaviour-change.md` | extracting switching barriers / fears | the blockers, Solution-as-label, habit, fears | ~10k |
| `Next-Move-Theory-Canon/Advanced-Jobs-To-Be-Done/value-creation-mechanics.md` | generating value hypotheses (Section 5) | the published mechanic menu | ~5k |

> **Path note.** Use the paths above. If a file is not found, retry with a `1-` prefix on the canon folder (`1-Next-Move-Theory-Canon/...`) — the source repo orders folders with a numeric prefix the public repo strips.

**Do NOT use generic JTBD from the internet or prior training.** Ivan Zamesin's AJTBD diverges substantially. The mis-defaults to never propagate (per the project `CLAUDE.md`):
- A **Job** is a desired *transition* — State A (situation) → expected outcome (State B), in order to perform a higher-level Job. Not "a struggle for progress."
- `I want to + verb` is the **primary element** of an eight-element Job, not the whole Job. **Each infinitive verb is a separate Job** — parse multi-verb statements into the hierarchy.
- A **Problem** is a consequence of a Solution hired for a Job and underperforming its success criteria — not a root cause.
- **Value** is greater energy efficiency for the brain in performing a Job, vs. its prediction; the **Aha Moment** is the customer-experience of value beating prediction; the **Problem** is value falling below it. Never use the abbreviations PPE/NPE.
- A **Solution** is a real thing in the world *and*, inside the Job Graph, a label for the sub-graph of Core + Micro Jobs it installs. DIY ("I just did it myself") is a Solution too.

**Methodological invariants — output is invalid if any is violated:**
- Segments are formed by **similar Core Jobs sharing similar success criteria *in a similar priority order*** — never by demographics, industry, or Big Job as the primary cut. *Speed-first* vs *no-stress-first* on the same Job = different segments.
- A "real / causal" segmentation criterion is a **cause** (a behaviour or characteristic that changes value, margin, or demand), never a paraphrased value or a consequence.
- **Study Jobs by past expenditure (money / time / energy), never by future intent.** Future-tense intent with no past commitment is a **Fake Job** — extract its Big Job, never the Fake Job itself.
- Personas are the **causal criteria**; demographics are second-order correlates, never the first cut.

---

## The fan-out architecture (this is what makes the skill scale)

**The orchestrator never reads the raw transcripts into its own context.** It spawns **one distiller subagent per interview** (or per batch of 3–4 short files). Each distiller reads *its* file plus its canon slice and returns **only a compact structured distillation** (~600–1,200 tokens with 2–3 anchor quotes), not the raw text. The orchestrator synthesizes segments from the distillations.

Why this matters: 18 deep interviews at ~8–10k tokens each are ~150k tokens — they cannot fit one 200k window alongside the canon and the report, and forcing them in triggers compaction that *summarizes away the verbatim customer utterances AJTBD depends on*. Fan-out turns ~150k of raw transcript into ~15k of distillation, fits comfortably, and **preserves the exact quotes on purpose.** The concurrency cap handles the rest — pass all N files; they run in waves.

- Distillers run with the `Agent` tool, `subagent_type: "general-purpose"`, `run_in_background: true`; the orchestrator waits for the wave, collects the returns.
- **No per-interview files.** Each distiller returns its distillation in its final message. The orchestrator holds them in context and writes the one report (Rule 4).
- **Run in waves and checkpoint into the one result file.** Cap concurrent distillers (~4–6) and take the set wave by wave. After each wave, write that wave's rows into the result file's source → segment map and per-interview appendix — the file is created early, in draft, and grows. If the run is cut off by a context or usage limit, the finished distillations are already on disk and the rerun starts at the first un-checkpointed file instead of from zero. Say in chat which wave just landed and how many files remain.
- **Never let raw transcript text into the orchestrator's context.** If a distiller returns more than ~1,200 tokens or pastes long stretches of transcript, ask it for the compressed form again. The only verbatim text that reaches the orchestrator is the anchor quotes.
- **Load canon by stage, not up front.** The orchestrator holds only the eager core and reads each staged file at the stage that uses it (see the loading table above); distillers read their two-file slice only, never the whole canon. This is what leaves room for 18+ transcripts' worth of distillations plus the report.

---

## Plain-language output — the reader is a builder, not a methodologist

Write the report in the plain language the user speaks; when a methodology term genuinely adds precision, lead with the plain meaning and put the term in parentheses the first time — never lead a sentence or heading with a raw term. Keep quotes verbatim. Confidence is reported in plain words (clean read / directional / weak / not usable), with the methodology rubric behind it.

**The zero-knowledge test (hard rule).** Every line of the report — and every tooltip inside it — has to land for someone who has never heard of this methodology. Explain it the way you would explain it to a smart 8-year-old, in everyday words. This covers research and audio jargon too (*speech-to-text*, *speaker separation*, *saturation*, *screener*, *open-end*), not only AJTBD terms. If a sentence only works for a reader who already knows the term, rewrite it.

**In HTML output, every abbreviation and methodology term gets a tooltip on its first use** — `<abbr title="the task a person hires a product to do for them">Core Job</abbr>` — and the tooltip text is the plain-words explanation, not the canon definition. In Markdown the same rule applies without the markup: a short plain parenthetical on first use. (Same as the shared readability gate — `../READABILITY-CONTRACT.md` Gate 9.)

---

## Evidence discipline — how many people said it, and what kind of claim it is

Two labels ride on **every** claim in the report. They are what stops one vivid quote from becoming "the segment's main pain."

**1. How many said it, and which ones.** Any claim made at segment or market level carries a count and the sources behind it: *"said by 7 of 22 interviews: #3, #7, #9, #11, #14, #18, #21."* No count — the claim does not ship.

- **A claim supported by exactly one source may not appear in a segment-level conclusion.** It goes to the separate **"Single signals — verify before acting"** list (report §6) with its interview number and the quote. It may well be true and important; it just isn't yet evidence about a group.
- Count against the people who *could* have said it, and state that denominator: *"4 of the 9 who had used a competing tool"* is a real number, *"4 of 22"* hides one.
- The quote illustrates a counted claim, never replaces it. Pick the anchor quote **after** the count, from inside the counted set.

**2. What kind of claim it is.** Every claim is one of three and says which:

| Status | How it is written |
|---|---|
| **Backed** — a quote or a figure taken from the source material | cite it: the verbatim quote + the interview # |
| **Derived** — worked out from the data | say from what: *"derived from the 6 interviews where the trial stalled before the first export"* |
| **The model's own hypothesis** | marked as such, and it lives only in "Hypotheses to validate" (report §7) |

- **A number a respondent says out loud is that person's opinion, not a market fact.** *"60–70% of deals go through tenders"* is written *"per the sales lead in #4 — their estimate, not a measured figure."* Never promote such a number to a headline, never average several of them into one figure.
- **Explanations from founders, managers, and salespeople are claims about the world, not observations of it.** What they did and saw is data; why they think it happens is their opinion, recorded with the role attached.
- **An idea that appears in none of the sources may never enter the segments, the Problems, or the value hypotheses as fact** — a warranty nobody mentioned, a price sensitivity nobody voiced. If it is worth keeping, it goes to "Hypotheses to validate" with the cheapest check that would confirm or kill it.

---

## Output file (one file per run — `CLAUDE.md` Rule 4)

The skill writes **exactly one** file. Default location (unless the user gave a custom output path in intake — `PRODUCER-CONTRACT.md §5`):

```
Skills-Results/{product-slug}/analyze-interviews/{YYYY-MM-DD_HH-MM}_{product-slug}-analyze-interviews-result.{md|html}
```

- **Extension follows the chosen output format** (`PRODUCER-CONTRACT.md §2`): `.md` (default) or one self-contained `.html` (inline CSS, working in-page anchors, `<details>` for the per-interview appendix and the long segment blocks, `<abbr title="…">` tooltips on every term's first use, source links opening in a new tab). HTML carries identical content. Never write both; one file per run.
- If the user gave a custom path, write the one file there with the same filename pattern.
- `{YYYY-MM-DD_HH-MM}` (24h local time) makes each run unique; reruns never overwrite.
- Everything internal (the distillation traces, discarded clusters, the climb from a Fake Job to its Big Job) stays in-context, not in a separate file.

**Disclaimers (Rule 3) at the very top of the file (once):**

> ⚠️ **Numerical disclaimer.** Every confidence level, segment size, and Job-budget figure here is an LLM-generated estimate from your interviews — including the confidence scores themselves. Treat them as a reading of your data's strength, not a measurement. Validate before any expensive decision.
> ⚠️ **Hallucination disclaimer.** This document is generated by an LLM and may contain hallucinations in unknown places — including Jobs read into a transcript that the respondent didn't actually express. For decisions with expensive consequences, re-read the anchor quotes and run a confirming interview pass; do not act on this document alone.

**Attribution (Rule 23).** Open with the attribution top-line (first content, above the disclaimers) and close with the attribution block — `utm_source=nmt-analyze-interviews&utm_medium=skill-artifact`.

---

## STAGE 0 — Orientation (helicopter view) + language & market

**First, the orientation block** (`PRODUCER-CONTRACT.md §1`) — before any question, in plain words:

> **What you'll get:** one report — the customer segments hiding in your interviews (grouped by what they hire a product to do), each with a persona, the existing solutions they use and where those fall short, what they weigh before choosing, value ideas, and — honestly — how much your interviews can be trusted to answer your question.
> **The steps:** (1) you tell me the business task you're solving (I'll help if you can't name one) → (2) you point me at your interview files → (3) I read each one separately and pull out the tasks people hire a product for, with an honest confidence → (4) I tell you, per interview, what I found and what's missing → (5) I cluster them into segments and tell you which ones the data really supports → (6) one report, plus what to interview next.
> **Where I work vs. where you decide:** I extract and cluster what's in the transcripts; I can't add what isn't there. Where an interview is thin, I'll say so and tell you what to ask next time.
> **Two modes:** *Quick* (default — no internet; reads and synthesizes your files) · *Deep* (opt-in — also researches the real competing products and review language around the tasks I find, to enrich the competitive picture).
> **Honest caveat:** the output is only as good as your interviews. If they're about hypotheticals or never touched a real past purchase, I'll flag that — and the right next step is better interviews, not a prettier report.

Then **document language.** Default to **English**; if the user writes in another language, offer to work in it (`AskUserQuestion`: English / their language / Other). Hold the choice; all communication and the file use it; canon files and URLs stay as-is.

Then **the market** (`PRODUCER-CONTRACT.md §7` — mandatory, never inferred). Ask in the same breath: *"Which market or region are these customers in, and what language do they speak?"* Never infer it from the user's own language or from the fact that most examples you know are American. Everything market-shaped in the report comes from that answer — the named competitors and Consideration Set, price and Job-budget anchors, the channels in §9. If the interviews themselves name a different market, say so and confirm which one to write for.

---

## STAGE 1 — The business task (asked first — it is the spec on the extraction)

The chosen business task changes *what to dig for and at what altitude* — the canon: *"the shortlisted mechanics are the spec on the research… without them you interview blind"* (`Next-Move-Theory-Canon/Algorithms/the-algorithm.md`). So pin it before extracting. Run this waterfall:

1. **Ask directly** (`AskUserQuestion`) — *"What business task are you trying to solve with these interviews?"* — offer the menu below.
2. **If the user can't name one** → *"Describe in your own words what you're trying to figure out or fix."* (free text).
3. **Infer from the description.** If you can confidently map it to a task on the menu, **play it back in one sentence and confirm.**
4. **If you can't confidently map it** → propose the **2–4 most likely tasks** (`AskUserQuestion`) and let the user pick.
5. **If several tasks apply** → ask them to rank; the top one drives extraction emphasis, the rest are secondary.

**Business-task menu** (distilled from the canon's Algorithms + mechanics catalog — `Next-Move-Theory-Canon/Algorithms/the-algorithm.md`, `Next-Move-Theory-Canon/Next-Move-Theory/mechanics-catalog.md`; cited as provenance, no need to read them for the menu):

- **Create value / beat competitors** — perform the Jobs more efficiently than the alternatives.
- **Increase conversion to sale / activate customers into value** — repair the path to the first Aha Moment.
- **Increase retention / decrease churn** — keep customers using it over time.
- **Increase repeat / return rate** — get the same customer back more often.
- **Increase average order value / improve unit economics** — lift value per customer / make the math close.
- **Launch / find PMF / find a segment / validate value** — for an early product.
- **Position & differentiate** — communicate validated value to a validated segment.
- **Grow / scale an existing product** — more segments, sub-segments, geographies, or more of one customer's Jobs.
- **Escape direct competition / climb a level** — relocate where you compete.
- **Not sure / challenge my goal** — a "broken metric almost never sits where it shows" → diagnose upstream (route to `/nmt-diagnose` if it turns out there are no interviews to analyze yet).

**Hold the chosen task** — STAGE 3 conditions the extraction on it (see "Business-task → extraction emphasis").

---

## STAGE 2 — Intake the interviews + run settings

Collect in a short stream + one or two batched `AskUserQuestion` calls (max 4 each).

### Step 1 — The interview files
> Point me at your interviews — a folder, or a list of files. They can be deep-interview transcripts, interview notes, sales-call or demo recordings turned to text, support or chat logs, or open-ended survey answers. One file or many; AJTBD-style or not; polished or rough — I'll sort the quality myself.

- Accept a **folder path** (read every text-like file inside) or a **list of paths**. Supported: `.md`, `.txt`, `.docx` (read as text), `.vtt` / `.srt` (strip timestamps), `.csv` (survey open-ends — one row = one mini-interview).
- Everything taken from the files is tagged **[user data]** in-context. **All of it is hypothesis** (`PRODUCER-CONTRACT.md §3`) — an interview is the respondent's account, not ground truth; a sales call is a pitch, not a Job study.
- **Light context (optional, free text):** the product these interviews are about, and the segment(s)/Jobs the user already believes exist — held as *prior hypotheses to test against the data*, never merged in as fact.

### Step 1b — Files already sitting in the working folder (ask before opening any of them)
If the working directory holds anything that looks like product context — a `README`, product docs, a survey export, a review dump, an analytics or CRM/deal export, older interview notes — **list the candidates and ask permission before reading them**:

> I see these files in your folder that might be useful context: {list}. Want me to read them? **This context is processed only by your agent locally — it is not sent anywhere.**

Read only what the user says yes to; a "no" is final, don't re-ask mid-run. Anything read this way is [user data] and hypothesis like everything else (`PRODUCER-CONTRACT.md §3`) and enters the same evidence discipline: a deal export is data you can count, a README is the team's claim about their own product.

### Step 2 — Batch: mode, output format, output path
- **Mode** — Quick (default; no internet) / Deep (subagents + web — enrich competitors + Consideration Set + review language).
- **Output format** (`PRODUCER-CONTRACT.md §2`) — Markdown (default; faster) / HTML (collapsible appendix + working navigation; links stay clickable).
- **Where to save the result** (`PRODUCER-CONTRACT.md §5`) — default `Skills-Results/{product}/analyze-interviews/…` / or a folder path to match your repo. One file per run regardless (Rule 4).

**Hold** everything in context.

---

## STAGE 3 — Per-interview distillation (the fan-out)

Spawn **one distiller subagent per interview** (batch 3–4 short files into one agent). Each distiller reads its file + `job-structure.md` + `job-types-and-properties.md`, applies the **extraction schema** and the **quality rubric** below, conditions its dig on the **chosen business task**, and returns a structured distillation. The orchestrator collects all returns.

### The extraction schema (what each distiller pulls)

For every distinct Job episode in the interview, extract the **eight Job elements** and the companion Solution (`job-structure.md`; `ajtbd-key-theses.md §3`):

1. **Context** — the person/situation features that make them want *this* outcome with *these* criteria (keep only features that change a criterion; discard background noise).
2. **Negative emotions (State A)** — what they felt *before*, while the result wasn't reached. Absence is not evidence of absence — flag "not surfaced," don't record "none."
3. **Consideration Set** — which ways of getting the higher-level outcome they weighed (four slots: known Job Graphs · comparative efficiency · named products + entry path · fears).
4. **Trigger** — the concrete moment that flipped them from thinking to acting (a moment in time, not "when I felt ready"). For recurring Jobs, the schedule substitutes.
5. **Expected outcome** — the `I want to + verb` clause, captured **verbatim**. A noun ("rental management") has the verb amputated — push to the verb. **Each infinitive verb is a separate Job** — parse stacks.
6. **Success criteria + priority order** — the concrete, measurable conditions for "good enough" (direction + level). Adjectives ("fast," "reliable") are wishes — push to a number/fact. **Capture the ranking** — which criterion is non-negotiable, what's traded off. The priority order is itself a segmentation criterion.
7. **Positive emotions (State B)** — how they wanted to feel after (dig past first-pass facts to the named emotion).
8. **Higher-level / Big Job** — climb "in order to…" until answers repeat (repetition = you hit the need; don't record the need as a Job). Don't claim the Big Job as what the product delivers.

Plus, on each Job: **frequency**, **Job budget** (what they paid / spent), **importance** (if elicited); **the chosen Solution** (brand / route / DIY) structured as *label + the sub-graph of Core + Micro Jobs it installs*; the **Job type** (Regular / Orientation / **Tax** / **Fake** / Emotional / Viral); the **Aha Moment** (a pleasant surprise *while using a product*, beating the criteria they came in with); every **Problem** on its `Job → Solution → Problem` chain; **switching barriers & fears** (habit, identity, objective barriers, fears from real past experience vs. imagination); and the **Previous / Next Jobs** in the chain.

**Tag what kind of thing each captured item is** (the distiller does this, so the orchestrator never has to guess — see "Evidence discipline"):
- **Did / saw** — what this person actually did, paid, or witnessed (paid $400 in March, called support twice, switched after the second outage). Data.
- **Their estimate about the world** — a number or share they state about the market, their industry, or other people (*"60–70% of deals go through tenders"*, *"everyone here uses X"*). Record it with the speaker's role and the label *their estimate, not a measured figure*. Never carry it forward as a fact.
- **Their explanation / argument** — why they think something happens, especially from founders, managers, and sales people. Opinion, attributed to the role.
Keep the verbatim wording for all three; the tag rides alongside, it doesn't replace the quote.

### The quality rubric (per interview → a confidence on its Core Jobs)

**Hard gates** (a "no" caps the interview's Core Jobs at *not usable* — Fake-Job risk):
- **G1 — real past expenditure.** Did the respondent actually pay money / spend time / burn energy on this outcome in the past?
- **G2 — they performed the Job themselves.** Are they narrating their own past behaviour (not hypotheticals, not "users in general")?
- **G3 — a concrete past episode exists.** A specific reconstructable instance (one-off) or a clear habitual pattern + frequency (recurring).

**Quality dimensions** (each strong / partial / absent): trigger present · context present · expected outcome as a verb · **success criteria concrete (+ ranked)** · Big Job laddered · emotions surfaced · Consideration Set present · low leading-question contamination · respondent's own words preserved · awareness zone right (a status/identity *why* taken at face value is a quality failure even in a smooth interview).

**Roll-up to a confidence on the Core Jobs from this interview:**
- **Clean read (High)** — gates pass; trigger, context, outcome, concrete ranked criteria, and Big Job all strong; open-first + no leading; Consideration Set present. The eight elements are essentially reconstructable.
- **Directional (Medium)** — gates pass; the outcome and some concrete criteria are there, but gaps (no Big-Job ladder, thin Consideration Set, criteria only partly concrete, some leading). Usable directionally.
- **Weak (Low)** — gates pass but the dig is shallow: abstract criteria only, no trigger, opinions/satisfaction-heavy, heavy leading, or a Zone-2 *why* taken as fact. Only candidate hypotheses survive.
- **Not usable** — G1 or G2 fails, or pure future/hypothetical/feature-wishlist talk with no real episode. Do **not** extract Core Jobs as findings.

### What to still salvage from a Weak / Not-usable interview
Even unusable transcripts aren't zero: climb to the **Big Job above a Fake Job** (often real — "learn Spanish someday" → "feel at home with my partner's family"), record **named Solutions / competitors**, capture **stated Problems** (as orphan symptoms, flag the missing Job), and mine **behavioural signals over self-report**. Label every one a *hypothesis to validate*, never a finding, and route the respondent to a re-recruit on a past-payment screener.

### Distiller return shape (in its final message — no files)
Per interview: usability classification (AJTBD / partial / non-AJTBD; well / poorly conducted) · the rubric verdict (gates + roll-up) · each Job episode with the eight elements + Solution + type + Aha + Problems + barriers + Previous/Next Jobs, **each item tagged did-saw / their-estimate / their-explanation** · 2–3 anchor quotes per Core Job · the per-Job confidence · what's **missing** for the chosen business task · **one candidate anchor quote for the source → segment map.** Cap the return at ~1,200 tokens; compress rather than paste transcript.

### Business-task → extraction emphasis (the delta beyond the always-on spine)
The spine (Core Jobs + ranked success criteria + Solutions) is always extracted. The chosen task tells the distiller what to dig *deeper* on:

| Business task | Dig deeper on |
|---|---|
| Create value / beat competitors | Big Jobs · Consideration Set · Jobs outside Core (Previous / Next / sibling Small) · Problems with current Solutions |
| Increase conversion / activation | Critical Chain breaks before first value · Aha placement · the 3 barriers (don't-see-value / fears / cost) · triggers |
| Retention / churn | Next Jobs · the Aha stream over time · "why they stay" + "why they left" · Problems after start · habit & switching cost · frequency |
| Repeat / return rate · AOV · unit economics | multiple Jobs per person · Job budget · frequency · high-margin criteria |
| Grow / scale | adjacent & sub-segment Job Graphs · Common Jobs across graphs · budget per Job |
| Position & differentiate | Core Jobs + ranked criteria · Big Job · barriers & fears · Aha · triggers |
| Escape competition / climb a level | Consideration Set incl. out-of-category Solutions · the Big Job above · Previous / Next Jobs |

---

## STAGE 4 — Per-interview feedback (what was found + can it serve the task)

From the distiller returns, build the **per-interview feedback** the user asked for — one row per file:
- **Type & quality** — AJTBD / partial / non-AJTBD; well / poorly conducted (with the one decisive reason).
- **What was extracted** — the Core Jobs found (with their per-Job confidence) + the key elements present.
- **What's missing** — the elements absent or thin.
- **Serves the task?** — given the chosen business task, can this interview contribute? (e.g., *"for retention you need Next Jobs and reasons-to-leave; this interview has neither — usable only for Core-Job hypotheses."*)

This is this skill's version of the producer contract's *"risks I see in what you gave me"* block (`PRODUCER-CONTRACT.md §3`): the inputs are interviews, so the risk read is the quality read.

---

## STAGE 5 — Synthesis into segments + confidence propagation

Cluster the distilled Job extractions across all interviews into candidate segments, then score each segment's confidence.

**Clustering rule (the segmentation root).** Two interviewees are the **same segment** when they perform **similar Core Jobs with similar success criteria *in a similar priority order*** (`segmentation.md §2`; `ajtbd-key-theses.md §12`). They are **different segments** if any of these differs: the Core Job; the criteria (same outcome + different criteria = different Job); **or the priority order** (*control-first* vs *done-for-me-first* = different segments). Same surface verb ≠ same segment. One person with several Jobs is **one segment** (their whole graph places them), not many.

**Anti-pattern checklist — run it on every candidate segment before it is written down** (`segmentation.md §2`, `§7`, `§14`). A candidate that trips one of these gets fixed or merged back, and the report says which check fired:

- **A purchase channel is not a segment.** *"Buys through tenders," "came via the marketplace," "inbound vs. outbound"* describes how the money arrived, not what the person hires a product to do. One tender queue holds resellers (Core Job: *"win my client's order at a workable margin"*) next to end users (Core Job: *"keep the line running"*) — different Jobs, different criteria, different products. Split the channel by Core Job; never let the channel itself be the segment.
- **An industry or vertical is not a segment when the Core Jobs and success criteria coincide.** Don't cut a B2B set into "manufacturing / logistics / retail" if all three perform the same Core Job with the same ranked criteria — that is one segment wearing three industry labels. Industry turns causal only when it actually changes the Job, the criteria, the margin, or the buying chain (a certification, an audit, a procurement route). Name the change, with the interviews that show it, or merge (`segmentation.md §14`).
- **Every segment is defined through Core Jobs + success criteria + their priority order.** If the cut in your hand is demographic, firmographic, channel-based, or industry-based, write the causal sentence — *this property changes the value we can create, the margin, or the demand* (`segmentation.md §7`) — and back it with interview numbers. No causal sentence, no segment: merge it and re-cluster on the Jobs.
- **A segment needs more than one source.** A cluster standing on a single interview is a *Hypothesis*, and whatever makes it look distinctive goes to "Single signals," not into a segment description.

**Persona = the causal criteria** (`segmentation.md §7`): the Core Jobs + ranked criteria + the cause-level situational facts that produce them. Demographics are second-order correlates, never the first cut. Each criterion that survives must be a **cause** that changes value, margin, or demand — not a restated value ("they'll save $2,000" is value, not a criterion). Each persona bullet carries its count and interview numbers, like every other segment-level claim.

**Confidence propagation (compute it, show the math — no false decimals).** Each extraction carries its interview's confidence weight: **Clean = 1.0 · Directional = 0.66 · Weak = 0.33 · Not-usable = 0** (Not-usable contributes only Big-Job hypotheses, not segment evidence). For each segment:

- **Support weight** = the sum of the confidence weights of the interviews whose extractions land in the cluster.
- **Saturation** = did new interviews stop adding new Core Jobs / criteria to the cluster? (a qualitative yes/partial/no).
- **Coherence** = how tightly the criteria *and* the priority order agree inside the cluster. A split priority order is a signal to **split into two segments**, not to average.

Roll up to a plain-language segment confidence (tune the thresholds to the data, state them):
- **Solid** — support weight ≥ ~3, coherent, saturating.
- **Emerging** — support weight ~1.5–3, some coherence.
- **Hypothesis** — support weight < 1.5, a single supporting interview, or incoherent.

Always render the support transparently: *"Segment B — Emerging; stands on interview #2 (Clean), #5 (Directional), #9 (Directional)."*

**Inverse read (the data-quality honesty gate).** Report how many interviews were Weak / Not-usable, what that does to the overall trust, and — given the chosen business task — **which task questions the current data cannot answer.** That list becomes "what to interview next."

---

## STAGE 6 — Assemble the report

Build the single file in this order (top attribution → disclaimers once → the sections below). Compute the **"What your calls are telling you"** Layer-1 block and the data-quality summary **last**, from the finished work — the Layer-1 block is the one-screen verdict (can the data answer the task · the top 2–3 segments with an anchor quote each · the single biggest data risk); §1 is its fuller breakdown.

**Scale the confidence you claim to the input you actually got — compute this, never reuse boilerplate.** Count the usable interviews (Clean + Directional) and the support weight per segment:

- **Thin input** — fewer than ~5 usable interviews overall, or a segment standing on less than ~2 support weight, or files that are notes and sales pitches rather than Job interviews. Then: put a warning line at the very top of the report — *"Thin input: {N} usable interviews out of {total}. Everything below is a hypothesis; numbers are ranges, not points."* — write every number as a range (*"2–4 of the 7"*, *"somewhere between a week and a month"*), label every segment *Hypothesis*, and list the **top 3 things that would raise accuracy most** (e.g. *"5 more interviews with people who paid in the last 90 days," "your churn export," "the Q2 sales-call recordings"*) in §9.
- **Enough input** — usable interviews behind every segment, and saturation reached at least in the top segment. Point figures are allowed then, each with its count and interview numbers.

This is computed from the files at hand and sits *on top of* the fi

…(truncated)