zamesin/next-move-theory-canon-and-skills/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.