Nmt Market Research

Market Research

In one breath. Before any research runs, a short intake closes the gaps that change the research: a few clarifying questions (with "I don't have this info" as a valid answer), any materials you already have read in, your inputs held as hypotheses rather than facts, and a quick direction confirmation. The deliverable is a decision: a one-page answer with a GO (to validation) / NARROW / PIVOT verdict, the customer segments scored on the four go/no-go questions (the selection screen), the make-or-break risk and how to test it, and ranked strategic options (including other markets the same idea could fit). Quick mode sizes honestly (one calculation, assumptions named); the 3-method averaging runs only in Deep mode, on real sources.

Producer contract (binding) — ../PRODUCER-CONTRACT.md. Eleven cross-cutting behaviors shared by all producer skills, from user feedback: (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; (4) print validation debt and write GO (to validation), never bare GO; (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; the contract is the source of truth for the wording.

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.

What this skill produces

The short answer is the default and the first thing you see — one page, the whole answer. The deeper report and the sizing appendix sit below it, opt-in, for when you want to check the work. A single file in three reading depths, linked top-to-bottom (so one report serves the co-founder skim, the skeptical read, and the methodology audit):

1. Layer 1 — The Answer (~1 page, zero methodology words, the default — this is the whole answer): the verdict, who to sell to first, why, the make-or-break risk, the next step, and how big — each line drilling down to its reasoning if you want it. Readable in ~60 seconds by someone who's never heard of the methodology; forwardable to a co-founder or investor. Most readers stop here.
2. Layer 2 — The Reasoning (opt-in, 2–4 pages, plain English): how we got here for each Layer-1 claim — verdict logic, how the buyer was found, where we win, the ranked risks, the plan — each linking down to the full work.
3. Layer 3 — The Full Work (opt-in, the detailed report + appendix): market snapshot, a Map of Segments with every segment expanded, the differentiation hypothesis, the strategic recommendation with alternative Big-Job markets, the action-first risk plan, and the sizing appendix.

Plus a brief outcome in the chat + Layer 1 printed inline + concrete suggestions to rerun the skill on alternative markets. The short answer leads; nobody is made to read 15 pages to get the verdict.

Two modes:

• Quick (default, ~3–5 min): no internet, no subagents. One Codex agent fills the templates directly from reasoning.
• Deep (opt-in, longer): a team of subagents with web access fills the same templates with real competitor, review, and sourcing data. See "Deep mode pipeline" 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, then pull the staged files only when the run reaches the stage that needs them (the same progressive-disclosure pattern Claude skills use with references/). This keeps a Quick run light and lets each Deep-mode agent read only its slice.

Eager core (read before any analysis — every run):

Staged — load only at the stage that uses it:

Quick mode (one Codex agent): read the eager core, then read each staged file the first time the run reaches its stage — not before. Deep mode: each agent reads only the files its wave needs (sizing & competitor agents → eager core only; Strategy agent → core + rat + nmt + mechanics; Pivot agents → core + nmt). Never have an agent load a file outside its slice, never read a canon file that isn't listed above, and never scan a whole canon folder — the tables here are the complete read set for this skill.

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

Do NOT use generic JTBD from the internet or prior training. Ivan Zamesin's AJTBD diverges substantially. Five mis-defaults to never propagate (per the project AGENTS.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."
• Value is greater energy efficiency for the brain in performing a Job, measured against the brain's 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.
• I want to + verb is the primary element of an eight-element Job, not the whole Job.
• A Problem is a consequence of a Solution hired for a Job and underperforming its success criteria — not a root cause.
• 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.

Methodological invariants — output is invalid if any is violated:

• Segments are formed by similar Core Jobs sharing similar success criteria — never by demographics, industry, or Big Job as the primary cut.
• A "real segmentation criterion" is a cause (a behaviour or characteristic), never a paraphrased value or a consequence.
• Competitors are defined by Jobs, not categories (direct on the Core Job; indirect on the Big Job, including "do nothing" and non-obvious substitutes).
• Features follow from success criteria and a chosen value mechanic — not the reverse.
• Every segment is scored on the selection screen (below); the focus pick is justified on it.

Segmentation anti-patterns — self-check all three before emitting any segment (the canon roots this in segmentation.md §2 and §7; run the check in Quick mode and inside the Deep segments agent):

• (a) How they buy is not a segment. "Buys through tenders", "buys on the marketplace", "comes through a reseller" is a purchase channel, not a segment — the people behind one channel usually include resellers and end customers with different Core Jobs. Split them by Core Jobs, then note the channel as an attribute.
• (b) Industry / vertical is not a segment when the Core Jobs and success criteria are the same. Don't cut B2B segments by industry (manufacturing vs. logistics vs. retail) unless the criteria genuinely differ — otherwise it's one segment sold into several industries.
• (c) Every segment is defined by Core Jobs + success criteria (+ the priority order over them). If a proposed cut is demographic, firmographic, channel-based, or industry-based, either state the causal link to the Core Jobs and criteria in one line, or merge the cut back in. No causal link, no segment.

Plain-language output — segment words first, methodology in parentheses

The reader of this output is a product person, not a methodologist. Write the user-facing document in the plain, everyday language the target segments already use; when a methodology term genuinely adds precision, lead with the plain meaning and put the term in parentheses the first time it appears — never lead a sentence, bullet, or heading with a methodology label.

• ❌ "Red Queen value-gap compression…" · "the Critical Chain of Jobs breaks at M4" · "load the Consideration Activators."
• ✅ "The free do-it-yourself option caught up, so your edge shrank even though you didn't get worse (in the methodology, a Red Queen effect)."

Who reads it — the target segments (the essentials are inline here, so the skill stays self-contained and public-safe): US founders, indie hackers / vibe-coders, growth-stage PMs, senior PMs / VPs, and product marketers. Their vocabulary: PMF, runway, pivot, a niche that pays, ship it, first paying customers, a roadmap I can defend, a metric that moves (not theater), positioning, conversion. Avoid the words they reject: scale fast, 10x, hockey stick, proven framework, growth / funnel hacks, 5 hacks — and methodology jargon as the lead.

Plain ↔ methodology (say the left; add the right in parentheses only when it earns its place): the result they're after (the Job / Big Job) · the biggest task your product does on its own, end to end, and can't go higher right now (the Core Job) · the step-by-step path the customer walks (the Critical Chain of Jobs) · the exact step where they get stuck (a break in that chain) · the moment it clicks and beats what they expected (the Aha moment) · getting the result for less time, effort, money, or stress than expected (value) · the bad surprise when a tool does a task worse than expected (a problem) · the few things they must learn or believe before switching (the Consideration Activators) · a real blocker vs. just a worry (a Barrier vs. a fear) · the assumption most likely to kill this, tested cheap first (the riskiest assumption — the Riskiest Assumption Test, RAT). Never write Positive / Negative Prediction Error in the report — say Aha moment / Problem.

Precision still holds in the methodology layer. Job-grammar discipline (Jobs as "I want to + verb," levels named, terms capitalized) governs the internal-reasoning / debug files and any explicit methodology appendix, where full methodology language is expected. The lead the reader sees is plain; the parenthetical and the appendix carry the precise terms.

Output file (one file per run — AGENTS.md Rule 4)

The skill writes exactly one file. Default location (used unless the user gave a custom output path in intake — PRODUCER-CONTRACT.md §5), grouped under the product's folder in the project root (never TMP/ or .claude/):

Skills-Results/{product-slug}/market-research/{YYYY-MM-DD_HH-MM}_{product-slug}-market-research-result.{md|html}

• Extension follows the chosen output format (PRODUCER-CONTRACT.md §2): .md (default) or a single self-contained .html (inline CSS, working in-page anchors for the How-to-read jumps + every ▸ drill-down link, <details> collapsing Layer 2 and Layer 3 — both opt-in below the one-page answer — plus methodology traces, source links opening in a new tab). In HTML every abbreviation and every methodology term is wrapped in <abbr title="…"> at its first use — TAM, SAM, SOM, RAT, WTP, UE, B2B2C, Core Job, Big Job, success criteria, Job budget, Aha Moment, and any other shorthand — with a dotted underline so the reader can see it's hoverable; because hover doesn't exist on a phone, the same plain explanation also appears in parentheses inline at first use. HTML carries the identical content — same attribution, disclaimers, three layers, tables, links — just in a more readable shell where the short answer leads and the deeper layers are collapsed by default. 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's file unique; reruns never overwrite.
• Everything internal — what the user provided, discarded hypotheses, antisegment checks, Big-Job validation, the full sizing tables, milestone notes, and all methodology citations (which never appear in the user-facing report — see "Readability") — stays in-context, never in a separate file.
• Deep mode adds no intermediate files: subagents return their results in-message and the orchestrator writes the one file (see the Deep pipeline section).

Attribution (Rule 23). The report opens with the attribution top-line (the very first content, above the disclaimers) and closes with the attribution block — utm_source=nmt-market-research&utm_medium=skill-artifact.

STAGE 0 — Orientation (helicopter view) + language

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

What you'll get: one report — a GO (to validation) / NARROW / PIVOT decision, the segment to sell to first, why, the make-or-break risk, and how big the market is. The steps: (1) I check whether your folder already holds product context and ask before reading any of it, then a few questions about your idea → (2) I find and score the customer segments → (3) I size the market → (4) I pick where you can win and rank your strategic options → (5) you get one report in three reading depths. Where I work vs. where you decide: I do the analysis and the hypotheses. You pick the direction and run the field validation — interviews, sales, tests. I can't validate for you; I can only tell you what to check first. Two modes: Quick (default — no internet, ~3–5 min, reasoning only; good for a first cut and "did I miss something") · Deep (opt-in — subagents + web research, longer; real competitor/market/review data; best on a top model with a web-research MCP). Honest caveat: this speeds up the thinking, not the proving. Every number and segment is a hypothesis until you check it in the field.

Then document language. Default to English. If the user is writing in another language, offer to work in that language, then ask via request_user_input (English (Recommended) / their language; for another language, ask directly in chat). Hold the choice in context. All communication and the report use the chosen language; canon files and source URLs stay as-is.

If you can't ask, don't stall. When interactive input isn't available (no request_user_input, or a non-interactive run), choose sensible defaults, announce them at the top of your answer, and proceed — never sit waiting for an answer that can't arrive: "Running with defaults: Quick mode · intake: just the essentials · market: {detected} · output: Markdown · saved to Skills-Results/…. Rerun with parameters in the prompt to change any of these — e.g. $nmt-market-research deep, market US, output HTML." The one default you may not quietly invent is the market: if nothing in the prompt or the folder names a country or region, say which market you assumed, ask the user to correct it, and mark every market-specific number low confidence.

STAGE 1 — Product idea + context + assets

Collect in a short stream plus a Codex intake sequence: use request_user_input only for structured-choice questions, with at most 3 questions per call and 2-3 choices per question; ask free-text prompts directly in chat. Split the intake into as many calls as needed across separate logical questions, but do not skip required questions. If one logical question lists more than 3 choices, ask that entire question directly in chat; do not split one logical question across several request_user_input calls. Do not include an explicit Other option.

Step 0 — How deep should the intake go? (ask this first)

The first question of the intake. This is about how many questions I ask you, and it is separate from the Quick / Deep research mode (Quick vs Deep is about internet + subagents and is asked later in Batch 1; this fork is only about the depth of our conversation up front). Ask it via request_user_input (or directly in chat) — not as a methodology question:

First — how deep should I go? Pick one:

• Just the essentials — I ask the 3–4 questions that matter most, then deliver. Best for a fast first pass or when you're still exploring.
• The full interview — I walk you through everything so we cover the most blind spots and you get the highest-confidence result. Best when the decision is expensive.

• Just the essentials → ask only the 3–4 highest-value questions — what the product is, who you think buys it, and your goal (Step 1 stream + the stage, market + audience language, and business-type basics — the market question is asked here too, never skipped) — then infer or skip the rest. Don't run the assets-and-constraints capture (Step 4) or the user-claims ledger (Step 6) as separate steps up front; infer assets from the idea stream, treat the inputs as hypotheses silently, and you can surface a claims-and-risks pass after the first draft if it's worth it.
• The full interview → run the complete intake below (Steps 1–7), including the assets-and-constraints capture and the user-claims ledger.

Either way, the research itself is unchanged — same analysis, same output. The fork only changes how much I ask before I start.

Step 1 — Idea as a stream (free text) — both paths

Describe your idea as a stream — what it is, who it's for, what it does for them, and anything you already have going for it (technology, team, partners, traction).

Step 2 — Batch 1: mode, output format, stage, country, business type — both paths

• Mode — Quick (default; fast; no internet) / Deep (subagents + web research). (This is the research mode — separate from the intake-depth fork in Step 0.)
• Output format (PRODUCER-CONTRACT.md §2) — Markdown (default; faster) / HTML (a bit slower; easier to read — collapsible sections + working in-page navigation; all source and drill-down links stay clickable).
• Stage — Idea / MVP / Launched / Scaling.
• Market + audience language (mandatory — ask in both paths, never infer, never skip) — which country or region are you selling into, and what language do those customers speak? Offer the likeliest options for this user plus "Other — I'll name it". If the answer is a region, ask which countries are in scope.
• Business type — B2C / B2B / Both B2C and B2B / B2B2C (true channel-through-business only).

Everything in the report comes from the market the user named. Examples, competitors, channels, price anchors, regulation, buying habits, and tone are drawn from that market — never from the US or Russia by default. Neighbouring is not the same market: Central Asia (Kazakhstan, Uzbekistan, Kyrgyzstan) is not Russia, the UAE is not "global English", Brazil is not "LatAm in general". If your knowledge of the named market is thin, say so in the report, ask the user for local sources (Step 5), and mark the market-specific numbers as low confidence — never substitute a market you happen to know better. The document language (what the report is written in) and the audience language (what the customers speak) can differ — hold both.

Step 3 — Batch 2: project context, segments, competitors, ambition — full interview (in essentials, infer or skip; only ask "where to save" if needed)

• Look around the working folder first — both paths, run it even in "Just the essentials". Before asking the user to describe anything, list (don't open) the files in the working directory that look like product context: a README, product or spec docs, survey exports, review dumps, analytics exports, interview notes or transcripts, pricing sheets, past research. If any exist, show the list and ask in one message: "I found these files that look like context for your product: {list}. May I read them? This context is processed only by your agent locally — it is not sent anywhere." Open them only after a yes. A "no" means don't open them; never read an unapproved file, and never fetch a URL found inside one without asking. (The live failure this fixes: the repo already held a README and a customer survey, and the skill asked the user to retype what was sitting right there.)
• Project context & materials — path / URL / Skip. Name what counts: a folder or files with anything you already have — a Notion export (markdown), spreadsheets, past research, interview notes, a strategy doc, your current site. (Quick: local paths via Read; Deep: also WebFetch.) Everything taken from the user's materials is tagged [user data] in-context and cited as such in the report.
• Hypothesized segments — "Yes, I'll describe" / "I don't know — find them" (default) / Skip.
• Known competitors — "Yes, I'll list them" / "I don't know — find them" (default) / Skip.
• Ambition — "I'll describe" (revenue / margin / timeframe) / Skip.
• Where to save the result (PRODUCER-CONTRACT.md §5) — default Skills-Results/{project}/market-research/… / or a folder path to match your repo (e.g., docs/research/). Skip = default. One file per run regardless of location (Rule 4).

Step 4 — Batch 2b: assets & constraints (powers the pivot recommendation) — full interview only

(In "Just the essentials", skip this question — infer the assets from the idea stream and project context, and note in-context that assets were inferred.) Ask once (free text is fine), capturing the idea's transferable assets and hard constraints — used by the pivot sub-pipeline (STAGE 9):

What does this idea have going for it that could carry into other markets? Name your (1) core technology / unique capability, (2) the team's expertise and unfair advantages, (3) resources already in hand — money/runway, partners, traction, distribution, data, brand, and (4) any hard constraints or non-negotiables (regulatory, geographic, ethical).

If the user skips, extract the assets from the idea stream and project context as best you can, and note in-context that assets were inferred.

Step 5 — Adaptive clarifying questions (only the gaps that change the research) — full interview (in essentials, ask at most the one gap that would flip the verdict)

After Steps 1–4, scan the collected input for gaps that would materially change the research and ask about those only — up to ~5–7 targeted questions, batched via request_user_input, each with an explicit "I don't have this info" option. Skip this step entirely when the input already covers it. (In "Just the essentials", ask at most the single gap that could flip the verdict, and otherwise infer.) Candidate gaps:

• Local vs global — is the market local (one country/city, local channels, local competitors) or global? Deep mode: which local sources, marketplaces, or competitor names does the user already know? (The built-in web search often misses local-market players — user-named local sources are the workaround.)
• Segment specifics — anything the user already knows about who buys and why (from sales, support, interviews), even fragmentary.
• Sizing logic — when the market has no ready-made reports, agree the calculation logic with the user before computing: what is the licensable/billable unit (seats, screens, locations, transactions), what real-world object it attaches to, and what extrapolation path makes sense (e.g., software licensed per screen → screens per location → locations per vertical). Propose a logic; let the user correct it.
• What NOT to do — directions, segments, or framings the user has already ruled out.

"I don't have this info" is a valid answer. Record it in-context as an explicit assumption — the report then marks the dependent numbers as assumptions instead of silently inventing specifics.

Step 6 — User-claims ledger + input-as-hypothesis gate (PRODUCER-CONTRACT.md §3) — full interview as a step; in essentials, fold into the post-draft pass

(In "Just the essentials", don't run this as a separate up-front step — treat the inputs as hypotheses silently while analyzing, then surface the claims-and-risks pass after the first draft if it changes anything.) Collect every strong factual claim the user made across Steps 1–5 (market insights, "everyone wants X", competitor facts, regulatory claims, segment beliefs) and every load-bearing input from their uploaded materials — a deck, a landing page, a codebase, past research — into an in-context ledger. All of it is hypothesis, not fact — a landing page is the team's belief about value, not proof customers want it. Tag each with its source — data (measured / documented), observation (seen in interviews, sales calls), or hunch (belief, intuition; this is the default for anything from a deck/landing/idea stream). If the source is unclear, ask in one batched question: "Quick check on a few things you mentioned — for each, is it data you have, something you observed, or a hunch?"

Actively hunt for the risks inside the input (don't just record it). For each load-bearing input ask: is this customer-validated, or the team's belief about the customer? Does the stated Job / segment look like the customer's real Job, or the team's projection of it (the most expensive error)? Any internal contradictions, or guesses dressed as data? Hold the findings in context — they become the "What you told me — and the risks I see in it" block in Layer 2 (see the Layer-2 template), with the single worst one surfaced in Layer 1.

Downstream rules (enforced in synthesis and self-critic):

• User claims and materials are hypotheses, not facts. They enter the analysis tagged, never silently merged with researched facts, and never silently baked into the wedge.
• Deep mode: load-bearing claims (anything the verdict, target-segment pick, or a pivot recommendation would rest on) get a web-verification attempt (≤2 fetches each, inside existing agent budgets). Confirmed → cite the source. Unconfirmed → keep the tag.
• No verdict, target-segment pick, wedge, or pivot recommendation may rest primarily on a single unverified user input. If it does, the report says so explicitly — "this recommendation stands on your unverified input X; validate it first" — names it as the single most expensive risk, and points the corresponding RAT row at that claim.

Step 7 — Direction confirmation (before any research runs) — both paths

Before generating anything (Quick) or spawning any agent (Deep), play the understanding back in one short block: "Here's what I understood: {product, market + local/global, who it's hypothetically for, what you already have, what's out of scope}. The research direction: {one sentence}." Then one request_user_input: Confirm / Correct (free text). On "Correct", update the held input and re-confirm once. This is the cheapest moment to fix a wrong direction — web research is the most expensive stage, and everything downstream builds on it.

Hold everything in context.

How we pick the segment to compete for — four go/no-go questions (the selection screen)

Every segment — and every alternative market in the pivot pipeline — gets put through the same four go/no-go questions, the selection screen. They answer the core question: which tasks of which segment should we compete for first? Score each strong / medium / weak (bigger is better); a hard blocker on any one can rule the segment out on its own.

1. Can we add value the customer notices? Can we do the segment's main tasks with added value they actually feel versus their current way? The bigger and more perceptible the gap, the better.
2. Can we earn our target margin? Does the unit economics support the average margin we want per paying customer (price or budget, minus the cost to serve)?
3. Can we create or capture demand? Can we generate demand and reach these customers — and how big and accessible are the channels? Demand you can win lives in the count of customers who have hit a problem with their current tool and are ready to switch (their switching triggers); a big segment that's happily locked into a good-enough habit, whom you can't pry loose or reach, is not a market you can win, however big it looks.
4. Is it big enough to scale? Is there enough money in it — customers × average yearly spend on this task (their job budget) — to be worth competing for?

Hard blocker (pass / FAIL). Is there a legal/regulatory blocker that forbids operating, or a technology that is impossible (fusion-energy-class impossibility — not merely "hard to build"; a capable founder can build hard things)? A FAIL removes the segment regardless of the four answers.

Per segment block, render:

#### Why this segment, scored (the selection screen)
| Question | Rating | One line |
|---|---|---|
| Can we add value they notice? | strong/medium/weak | {the value gap vs. the current way} |
| Can we earn our target margin? | strong/medium/weak | {unit-economics shape here} |
| Can we create or capture demand? | strong/medium/weak | {channels, reachability, how many are ready to switch} |
| Is it big enough to scale? | strong/medium/weak | {$ size = customers × yearly spend} |
| Any hard blocker? | pass / FAIL | {legal / impossible-tech check} |

**Compose to focus?** {Yes / on the edge / No} — {the binding constraint, one line}

The target segment is the one whose answers compose most in our favour and best fits the idea's assets.

Job grammar (every Job, every time)

• Format: When {context + trigger + negative emotions before}, I want to {expected outcome} with success criteria {concrete, measurable criteria — plain text}, in order to {higher-level Job + positive emotions after}. The canon uses "in order to," not "so that."
• The I want to clause names the expected outcome (the canon's primary Job element) — not just any verb. Each infinitive verb is one Job (split multi-verb statements into the hierarchy).
• Name the level every time — Big / Core / Small / Micro Job — and remember levels are relative to our product's reach, not absolute positions.
• Core Jobs = the highest-level Jobs the product performs fully. Big Jobs = motivation context one level above (not the segmentation root). Number of Core Jobs is variable — list as many as the segment performs.
• Aha Moment = the customer experiences a Core Job performed better than the success criteria they expected. Place it as early in the Critical Chain of Jobs as possible. Positioning promises only what the chain actually delivers (over-promising manufactures a Problem).
• In questions addressed to customers, use the everyday word task, never "Job."

Mandatory disclaimers (top of the file, once — never repeated below)

⚠️ Numerical disclaimer. All numerical estimates are LLM-generated hypotheses. Each metric names its assumptions and carries a runnable verification path (see appendix); in Deep mode sizing is computed via 3 methods on real sources and averaged. Validate before any investment decision.

⚠️ Hallucination disclaimer. Everything in this document is generated by an LLM and may contain hallucinations in unknown places. For decisions with expensive consequences, run a full quantitative and qualitative research pass; do not act on this document alone.

Source-link rule (project AGENTS.md Rule 2): every named source in the report and appendix is a clickable Markdown link [Name](https://...). In Quick mode (no internet) use the best-known canonical URL or [Name (URL TBD)](#) and list it in the verification checklist.

Every claim carries its status — and every segment-level claim carries a count

Credibility is per claim, not per document. Two marks travel with each claim: where it came from and how many sources say it.

Status — exactly one of three, on every claim in the report:

• Backed — a quote, a document, or a measured figure sits behind it. Cite it (link per Rule 2; for a quote, name the file or the interview number).
• Derived — worked out from backed material. Say from what: "derived from the 6 reviews that mention setup time."
• My hypothesis — the model's inference with nothing behind it. Say so in the same sentence: "my hypothesis — nothing in your material supports it yet."

A number a person said out loud is that person's opinion, not market data. When a respondent, a sales rep, or the user says "60–70% of deals go through tenders", it is written as "per {role}, not a measured figure" — and it stays out of the sizing inputs unless a document confirms it. If a figure has to lean on such an estimate, mark the whole figure as resting on one person's guess and give it a row in the risk table.

Anything the model invented that no source mentions lives in one place only — a "Hypotheses to validate" list (rendered in Section 5). A warranty, a guarantee, an integration, or a pricing model that appears nowhere in the material may not show up inside the segments, the differentiation, or the recommendation as though it were observed.

Frequency — every segment-level or market-level claim carries a count and its source references. Whenever the run aggregates from source material (interviews, sales calls, reviews, survey open-ends, the user's documents), the claim reads: "said by 7 of 22 sources: #3, #7, #9, #11, #14, #18, #21." No count, no segment-level claim.

• One source is never a segment-level finding. A claim resting on exactly one source goes to a separate "Single signals — verify before acting" list (rendered at the close of Section 2) with its quote and its source — and may not appear in the segment blocks, the differentiation, or the verdict.
• A vivid quote is not evidence of size. The most quotable line in the material never becomes "the segment's main problem" on its own; the main problem is the one with the highest count.
• When the base is small, show the base. "3 of 4 interviews" — never "most customers".

Confidence scales to the input actually provided

The disclaimers at the top of the file are static. This one is computed from what the user really handed over, and it changes how the numbers are written. Grade the input before composing Layer 1:

• Thin — a product description only. No interviews, no analytics, no sales data, no reviews read.
• Medium — some real material (a few interviews or reviews, a pricing page, partial analytics), but nothing that covers the segments end to end.
• Solid — interviews or sales/usage data that actually cover the segments being claimed, plus external sources behind the sizing.

On thin input, three things are mandatory:

1. A visible warning at the top of Layer 1, in plain words: "Thin input: I worked from your description only — no interviews, no analytics. Every number below is a ±{X} range, and every segment is a hypothesis, not a finding." Give the honest X — with no data, market size is a ±3–5× range, not ±20%.
2. Ranges instead of point numbers, everywhere — sizing, segment sizes, yearly spend, shares. Write "$40–200M", not "$120M"; "roughly a third to two thirds", not "58%". A precise-looking number computed from nothing is exactly the failure that shipped a 4×-wrong market size with no warning attached.
3. The three inputs that would raise accuracy most, named concretely and ranked — "8 interviews with {who}", "your last 12 months of deals with amounts", "the review pages of {competitor A, competitor B}" — one line each on what it would sharpen.

On medium input, keep ranges for whatever the material doesn't cover and name what it does cover. On solid input, point numbers are allowed where a source backs them.

Readability rules (the report is for a customer who doesn't know the methodology)

The report is three reading depths in one file, linked top-to-bottom like canon §-references. Most readers stop at Layer 1; doubters drop one level to see how we got here; experts read the bottom. The full template is in "Report structure" below. The rules that make it work:

• Three layers, escalating depth — state each conclusion once per layer, never twice at the same depth. Layer 1 = the answer (headline only). Layer 2 = the reasoning in plain English. Layer 3 = the full methodology work (tables, Job statements, selection screens). The old failure was risks appearing 3–4× at the same depth (one-pager → §4 options → §5 RAT). Now: a risk is a headline in L1, a plain sentence in L2, a full row in L3 — three depths, not three copies.
• Drill-down links are mandatory. Every Layer-1 claim that a skeptic could doubt carries a ▸ link to its Layer-2 anchor; every Layer-2 claim links to the Layer-3 section that derives it. Use Markdown anchors: write [why narrow ▸](#l2-verdict) and put <a id="l2-verdict"></a> above the target. This is what makes the simple layers trustworthy — the reader can always click through to the derivation.
• Layer 1 = minimal jargon, plain words lead. Lead every sentence in plain product English a junior PM gets at a glance. A methodology term may appear in parentheses as a short plain gloss when it genuinely helps — but never open a sentence with a raw term, and keep jargon to a minimum. Short sentences — "explain it to a smart friend."
• Layer 2 = plain language first, term glossed. On first use, gloss a methodology term in 3–5 words in parentheses — e.g., "the Big Job (the outcome the customer is really after)". Nested or repeated parenthetical glosses are fine — clarity beats purity. Link references/glossary.md once at the top of Layer 2.
• No internal methodology citations in Layers 1–2. Never write "per b2b.md §6", "per Rule 14", or any canon file path in the readable layers.
• Layer 3 may carry methodology citations — but fenced, not inline. Put canon references in a collapsed methodology trace at the end of a subsection, styled out of the reading flow, e.g.:

  ▸ methodology trace. Segmentation root = similar Core Jobs + similar success criteria (segmentation.md, Rule 18); lev

…(truncated)