# Gtm Next Experiment > Design the next GTM experiment for this product — inspect the repo, ask the founder three questions, select the single riskiest go-to-market assumption, design one executable experiment with locked continue/iterate/kill criteria, and write it into gtm/exp-NNN/. Use when the user runs /gtm-next-experiment or asks what GTM move to make next. - Skill: `llmjp/gtm-next-experiment` (Agent Skill) - Install (CLI): `npx skillmds@latest add llmjp/gtm-next-experiment` - Raw SKILL.md: https://api.skillmd.com/api/skills/llmjp/gtm-next-experiment/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: llmjp (https://skillmd.com/u/llmjp) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/llmjp/gtm-next-experiment --- # Next GTM Experiment You are closing the gap between "I built it" and "I know how to grow it". You will do the reasoning yourself, in this session. Be honest at every step: never invent data, never send secrets anywhere, never widen scope. **Mode:** if `USECASEIFY_API_KEY` is set (environment or gitignored `.env`), you are in **connected mode** — the lock step is notarized by the server and the experiment gets a public registry page. Without a key, **local mode** — everything below works fully offline and nothing is sent anywhere. API base: `$USECASEIFY_API_BASE` or `https://gtm.usecaseify.com`. ## Step 1 — Inspect the repository Identify by reading the codebase (bounded — do not dump whole files into context): framework/stack, analytics tooling and existing event names, key user-facing routes, signup flow shape, pricing/payment integration, feature-flag mechanism if any. **Privacy rules (hard):** never copy secrets, tokens, connection strings, or customer data into any file or request. Semantic summaries only. ## Step 2 — Ask the founder three things (one concise message) 1. **What's your biggest GTM problem right now?** Keep their own words. Classify as one of: `who_to_sell_to`, `few_paying_users`, `low_signup_conversion`, `which_value_to_emphasize`, `validate_new_feature`, `enter_new_market`, `other`. 2. **Product stage and current users?** (optional, skip gracefully) 3. **Current pricing?** (optional) If the founder communicates in Japanese, produce all human-facing text in natural Japanese (keep metric names, JSON keys, and event names in English). ## Step 3 — Select the ONE assumption Internally generate 5–7 candidate assumptions across: target segment, pain, trigger, value proposition, pricing, activation, and channel — grounded in the product context. Rank them by: **business impact, current uncertainty, cost of being wrong, testability, experiment cost, time to evidence.** Choose exactly one. Record the top 3 rejected candidates with one-line reasons. The chosen assumption must fit: > We believe that **[specific segment]** is more likely to **[specific behavior]** > because **[specific problem, trigger, or value]**. It must be falsifiable through observable behavior within 1–4 weeks by one builder plus their coding agent. Forbidden: vague goals ("improve brand awareness", "understand users better"), anything needing budgets or teams this founder does not have. **Evidence honesty:** every supporting/contradicting evidence item is typed `user_provided`, `repo_observed`, or `model_inference`. You have no external research — general market knowledge is always `model_inference`, phrased as reasoning, never as a verified fact or statistic. No invented numbers, studies, or benchmarks. Ever. ## Step 4 — Design the experiment **Connected mode, before designing:** `POST {base}/api/v1/enrich` with `{ "experiment_type": , "hypothesis": , "problem_text": }`. The response contains up to 3 REAL public experiments (locked criteria, reported outcomes) similar to this one. Read them: they carry honest sample sizes, durations, and failure modes. Let them ground the design's realism, and cite them in BRIEF.md under "Related public experiments" with their URLs. A `409 outcome_owed` means a previous experiment has no reported outcome yet — tell the founder plainly: publishing the last outcome is what unlocks enrichment (close it with /gtm-decision, or report it abandoned). Local mode: skip this step. Pick the best-fitting type: `user_motivation_segmentation` (users exist, unclear who pays), `landing_page_message_test` (value proposition unclear), `concierge_demand_test` (feature doesn't exist yet), `feature_adoption_test` (feature live, adoption unknown), `paid_intent_test` (love but no payment — real payment behavior beats stated intent), or `custom`. Produce the experiment object exactly in the shape defined by [docs/format.md](https://github.com/llmjp/usecaseify-gtm/blob/main/docs/format.md) (the `experiment.json` schema), then **self-check every rule on this list** and fix violations before showing the founder: - [ ] Exactly ONE `primary_metric` (snake_case name + precise computation definition), measurable with the analytics this repo actually has - [ ] `secondary_metrics` ≤ 5; `guardrail_metrics` ≥ 1 (protects the existing business) - [ ] `duration_days` between 7 and 28 - [ ] `continue_rule` / `iterate_rule` / `kill_rule`: concrete, checkable, pairwise distinct; thresholds relative to the founder's own baseline or between experiment groups — NEVER absolute industry benchmarks stated as facts - [ ] `user_experience.blocking` = false — the experiment never blocks the main flow - [ ] No banned vague phrases anywhere: "brand awareness", "improve positioning", "raise awareness", "understand users better", "market validated" - [ ] `human_tasks` ≥ 1; `agent_tasks` ≥ 1 (except concierge tests) - [ ] `results_template.quantitative_fields` covers everything the primary metric needs - [ ] `risks` ≥ 1, specific to this design; `minimum_evidence` realistic for their traffic (prefer "15 responses" honesty over statistical-significance theater) ## Step 5 — Write the files Determine the next number from existing `gtm/exp-*` directories (zero-padded to 3 digits). Write, following the section structures in `docs/format.md`: - `gtm/exp-NNN/experiment.json` — the structured spec (source of truth) - `gtm/exp-NNN/BRIEF.md` — for humans: assumption, why it ranked first, evidence for and against (with type labels), design, tasks split, metrics, the three rules, risks - `gtm/exp-NNN/TASKS.md` — for the implementing agent: inspection checklist, in/out of scope, exact UX, semantic data requirements, feature flag + rollback, tests, acceptance criteria, and the **"Results to report"** block listing exactly what to collect at the end ## Step 6 — Present, then let the human decide Summarize faithfully (no embellishment): the assumption and why it won, the experiment in two sentences, the three rules, and the exact user-facing copy. Then offer: - **Edit** — copy/options freely; rules and metrics only before starting. - **Start** — lock the criteria: - *Connected mode:* `POST {base}/api/v1/lock` with the experiment JSON — the server timestamps the lock (provably before any results existed), returns the lock hash, the public registry page URL, and `reminder_ics`. Write `criteria.lock.json` from the response and save `reminder.ics`. Free-tier experiments are **public** — tell the founder plainly, with the page URL. *(If the server is unreachable, fall back to local locking below and note it.)* - *Local mode:* write `criteria.lock.json` with `{rules, primary_metric, minimum_evidence, duration_days, locked_at, sha256}` where sha256 covers those fields. Note honestly: a local lock has no third-party timestamp; committing it to git is the integrity anchor. Generate `reminder.ics` (end date = start + duration). - Either way: suggest committing `gtm/`, and tell the founder to double-click `reminder.ics` to put the results day on their calendar. - **Implement** — execute TASKS.md exactly: post the before-implementation plan, respect in/out of scope strictly, use a feature flag, add tests, report the after-implementation summary. Never reword founder-approved copy silently. ## Honesty rules (always) - Present inferences as inferences; keep evidence type labels when quoting. - "Will this work?" — the honest answer is: that is what the experiment finds out. - Do not promise outcomes. Do not soften the kill rule.