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": <tentative type>, "hypothesis": <draft statement>, "problem_text": <founder's words> }. 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 (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.