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) — ../nmt-chat/references/producer-contract.md. Six 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. 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 primary 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 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 primary 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.

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:

• 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.

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)

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 a Client configuration directory):

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). 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) 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 a structured-input request (English / their language / Other). Hold the choice in context. All communication and the report use the chosen language; canon files and source URLs stay as-is.

STAGE 1 — Product idea + context + assets

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).

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/country/business-type basics) — 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 multi-batch 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

Collect in a short stream + (full interview) two batched structured-input requests (max 4 questions each).

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.
• Country / market — United States / United Kingdom / Russia-CIS / Global-English / Other.
• Business type — B2C / B2B / Both B2C and B2B / B2B2C (true channel-through-business only).

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

• 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 through the active Client's file-reading capability; Deep: also its web-retrieval capability.) 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 a structured-input request, 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 structured-input request: 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: 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.

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); levels named product-relative (Rules 8, 20). Never break a sentence of report prose with (b2b.md §7). Project-internal rule numbers never appear in any layer — they are for your reasoning, not the reader.

• Disclaimers once. The two-part disclaimer appears once (top of file), plus a one-line pointer in Layer 1. Do not repeat the full disclaimer block inside Layer 3. (Search the file before shipping — the disclaimer wording should hit at most twice.)
• Keep source links for external facts (Rule 2).

Enforcement gate (these kept getting skipped in real runs — check each before writing the file; full version in ../nmt-chat/references/readability-contract.md):

• Unique, resolving anchors. Every ▸ drill-down link points to its own unique <a id="…"> that exists exactly once in the file; no two links share a target. (The live failure was two Layer-1 links pointing at the same anchor.) Before shipping, list every ▸ target and confirm each resolves.
• Inline-gloss opaque Layer-3 table headers. A non-obvious column header carries a 3–6-word plain gloss right there — "Job budget (what one customer spends a year on this)," "Ready to switch (how many have hit a problem and would move)," "Reachability (how easily you can get in front of them)." Don't rely on the glossary file — a casual reader never opens it.
• Segment depth across layers (see Layer 2 / Layer 3 templates). The target segment is partially described in Layer 2 (who they are, what they're trying to get done, what they care about most, why they'll switch) with a brief strategic recommendation; the other top candidate segments get a light touch in Layer 2; the full Map of Segments at depth lives in Layer 3.
• Validation plan across layers (see templates). Layer 1 touches it (the make-or-break risk + the next action). Layer 2 carries the focused list — every risky assumption paired with how we'd check it. Layer 3 carries the detailed step-by-step validation plan per assumption, grounded in the canon (RAT).

Report structure — three layers in one file

Assemble the single output file as three reading depths, linked top-to-bottom:

• Layer 1 — The Answer (~1 page, zero methodology words): the verdict and the few things that matter, in plain product English, each linking down to its reasoning. Forwardable to a co-founder who's never heard of the methodology.
• Layer 2 — The Reasoning (2–4 pages, plain English, terms glossed once): how we got here for each Layer-1 claim. Where trust is built; each claim links down to the full work.
• Layer 3 — The Full Work (the detailed report + appendix): the complete methodology — Map of Segments at depth, selection screens, competitor tables, action-RAT, pivot table, sizing appendix. For readers who want the audit trail.

Order in the file: top-of-file attribution + disclaimers (once) → How to read this (the three levels) → Layer 1 → Layer 2 → Layer 3. Compute Layer 1 and Layer 2 LAST, from the finished Layer-3 analysis.

How to read this — the three levels

Emitted once, right after the disclaimers and before Layer 1, so the reader sees the structure and can jump to the depth they want. Keep the descriptions plain (no methodology words):

## How to read this
**Level 1 below is the whole answer — one page.** Levels 2 and 3 are optional, there only if you want to check the work:
- **Level 1 — The Answer** (1 page, plain words): the verdict, who to sell to first, why, the make-or-break risk, what to do next, how big. **This is the complete answer — most readers stop here.** [jump ▸](#layer-1)
- **Level 2 — The Reasoning** (optional, plain English): how we reached each answer — the buyer in more detail, where we win, and every assumption with how to check it. [jump ▸](#layer-2)
- **Level 3 — The Full Work** (optional, the audit trail): the full market sizing *with a do-it-yourself re-check*, all segments at depth, competitors, the strategy, and the step-by-step plan to test each assumption. [jump ▸](#layer-3)

Layer 1 — The Answer

<a id="layer-1"></a>
# {Product} — what the research says
{date · {plain one-phrase market} · stage}

> ⚠️ These are hypotheses, not facts — [full disclaimer ▸](#disclaimers)

## The answer: {GO (to validation) / aim narrower / pivot — in plain words, e.g. "promising, but aim narrower"}
{2–4 short sentences. Plain words, no jargon. The single most important conclusion and the one binding constraint. The first time the verdict is "GO (to validation)", add the half-line gloss: "— worth the next step, which is checking it in the field, not building it yet."} [why this, not a clean yes ▸](#l2-verdict)

> **Validation debt:** this stands on **{N}** unvalidated assumptions — **{M}** of them fatal (would sink it if wrong). The fatal ones are the first things to check. [see them ▸](#l2-risks)
> <sub>N = risky assumptions in the RAT table; M = those that kill it if wrong. A Quick run on thin input has high debt — say so honestly (`producer-contract.md §4`).</sub>

## Who to sell to
{The target segment in one plain sentence — who they are, not a methodology label.} [how we found this buyer ▸](#l2-buyer)

## Why they'd buy
{The value in one or two plain sentences — the concrete gain vs. their current way.} [the edge, in plain terms ▸](#l2-edge)

## The one thing that decides everything
{The single make-or-break risk, in plain words.} [the full risk list ▸](#l2-risks)

## Do this next
{One concrete next action.} [the action plan ▸](#l2-next)

## How big
{TAM/SAM/SOM in one plain line + whether size is the constraint.} [where these numbers come from ▸](#l3-sizing)

Layer 1 rule: minimal jargon, plain words lead — a methodology term may appear in parentheses as a plain gloss, but never opens a sentence; short, plain sentences ("explain it to a smart friend"). The make-or-break risk + the next action are Layer 1's light touch of the validation plan. Every line that a skeptic could doubt ends with a ▸ drill-down link.

Layer 2 — The Reasoning

Plain English, one gloss per methodology term, references/glossary.md linked once at the top of this layer. No big tables (prose + at most one small table); the full tables live in Layer 3. Each subsection carries an <a id="…"></a> anchor that Layer 1 links to, and links down to its Layer-3 section.

---

<a id="layer-2"></a>
# How we got here — the reasoning

*Plain-English walk-through of the logic behind the answer above. The full methodology, tables, and sources are in the next layer. Methodology terms are defined in the [glossary](references/glossary.md).*

<a id="l2-input-risks"></a>
## What you told me — and the risks I see in it
*Everything you gave me — your idea, your deck, your landing, your numbers — I treated as a hypothesis, not as fact. These are the inputs the analysis leans on, and what I'd check before trusting each. (`producer-contract.md §3`.)* (Omit this block only if the user provided no claims or materials at all.)

| What you provided / claimed | How I treated it | The risk I see in it | How to check it fast |
|---|---|---|---|
| {claim or material, tagged data / observation / hunch} | {used as hypothesis in {where — wedge / segment / sizing}} | {the specific risk — e.g., "this is your stated value, not customer-validated; the real Job may differ"} | {the cheapest falsifying test} |

{If any wedge / segment / verdict rests primarily on an unvalidated input, say so here in one bold sentence and point to the matching RAT row.}

<a id="l2-verdict"></a>
## Why "{verdict}", not a clean yes
{How an idea is tested by walking a chain — market → buyable customer → real value → working economics → reachable. Name where the chain holds and where it breaks, in plain words. Why the verdict is what it is.} [full chain walk-through ▸](#l3-verdict)

<a id="l2-buyer"></a>
## The buyer, in a bit more detail
{A **partial profile of the target segment** — not the full Layer-3 work, but enough to picture them: who they are, the situation they're in, what they're trying to get done, what they care about most (their dominant success criteria, in plain words), and why they'd switch from their current way. Then **a brief strategic recommendation** — in 1–2 sentences, what to do about this segment (focus here / how to enter / what to lead with).}

{Then one short paragraph or 3-row table on the **other top candidate segments** — name each, one line on who they are and why they rank lower (later / slower / not buyable yet). Full detail on all segments is in Layer 3.} [the full segment map, all segments at depth ▸](#l3-segments)

<a id="l2-edge"></a>
## The edge, in plain terms
{What every existing option forces the customer to give up, and why ours doesn't — where we win, in plain words.} [the criteria-by-competitor matrix ▸](#l3-differentiation)

<a id="l2-risks"></a>
## How we'd prove or kill this — every assumption and its check
{This is the heart of Layer 2. List **every risky assumption (hypothesis)** the whole case rests on — walked across the chain (market → buyer → value → economics → reach) — and pair each with **how we'd check it** in one plain sentence. Order by how-bad-if-wrong ÷ cost-to-check (riskiest, cheapest-to-falsify first). A compact two-column table is good here: *Assumption (in plain, falsifiable words) · How we'd find out fast.* This is the list the reader is meant to act on — the step-by-step "how" for each lives in Layer 3.} [the detailed step-by-step validation plan ▸](#l3-risks)

<a id="l2-next"></a>
## The plan, in order
{The nex

…(truncated)