Experiment Design Expert

Overview

Design fast, low-cost experiments to validate product hypotheses before committing to full development. This skill applies Alberto Savoia's pretotyping philosophy ("Make sure you are building The Right It before you build It right") alongside lean experimentation methods for both new and existing products.

Core Capabilities

• XYZ hypotheses — frame every test as "At least X% of Y will do Z" with a pre-set pass/fail threshold.
• SITG + YODA discipline — prefer skin-in-the-game signals (money, time, reputation) and Your Own Data over surveys and benchmarks.
• Method selection — landing page, explainer video, pre-order, concierge MVP (new products); fake door, feature stub, A/B test, Wizard of Oz, in-app survey (existing).
• 5-step process — hypothesis, method, metric/threshold, timeboxed run, evaluate (pass/fail/inconclusive).
• Automated design — experiment_designer.py suggests 2-3 experiments per hypothesis with metric, threshold, effort, and duration.

When to Use

• You have a product idea or feature hypothesis and need to validate it cheaply.
• You want to test willingness to pay or genuine user interest, not just stated preference.
• You need to choose the right experiment method for your context (new vs. existing product).

Clarify First

Before designing the experiment, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Hypothesis to test — the specific belief stated as "At least X% of Y will do Z" (drives hypothesis_text and the pass/fail threshold)
• Product type — new vs existing (selects the method catalog: landing page / pre-order / concierge vs fake door / feature stub / A-B test)
• Target segment — who "Y" is in the hypothesis (drives the metric and who you expose the test to)
• Available SITG signal — what skin-in-the-game you can capture (money, time, reputation) given budget/tooling (narrows realistic methods)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

Quick Start

python3 scripts/experiment_designer.py --demo            # built-in sample (3 hypotheses)
python3 scripts/experiment_designer.py input.json        # design experiments for your hypotheses
python3 scripts/experiment_designer.py input.json --format json

Each hypothesis needs hypothesis_text, target_segment, and product_type (new/existing). Document each experiment with assets/experiment_plan_template.md.

Prototype-First Experiments

AI app builders, AI design tools, and AI coding assistants can produce a clickable or working prototype in hours. Treat it as one more experiment method, with the same XYZ hypothesis and pre-set threshold:

• Use it when the riskiest assumption is usability or desirability of a specific interaction. For demand ("will anyone want this at all?"), a landing page, fake door, or pre-order is still cheaper and more honest.
• Test it with 5-8 target users on scripted tasks; measure task success and errors, not compliments. Say plainly that it is a prototype.
• Guard the data — use synthetic data; do not load customer PII into third-party tools without approval.
• Record the outcome in assets/experiment_plan_template.md, then carry validated results into execution/create-prd/ (Prototype-First Path) — the PRD still owns problem, metrics, constraints, non-goals, and risks.

References

Load the reference that matches the task — keep this file lean and pull detail on demand:

• references/methodology-and-tools.md — the XYZ/SITG/YODA principles, the experiment-type catalog for new and existing products, the 5-step process, experiment_designer.py usage and flags, output template, troubleshooting, success criteria, and bibliography. Read when designing or scripting an experiment.
• references/experiment-methods.md — Savoia's pretotyping manifesto and pretotype types, the full lean-experiment catalog (discovery and validation), metric selection guide, threshold-setting framework, sample-size rules of thumb, and 8 common pitfalls. Read for the deep method reference.
• references/red-flags.md — anti-patterns (confirmation-biased design, no pre-set threshold, vanity metrics, peeking) with bad/good experiment specs. Read before running an experiment.

Scope & Limitations

In Scope: XYZ hypothesis formulation and validation; experiment method selection for new products (landing page, pre-order, concierge, explainer video) and existing products (fake door, feature stub, A/B test, Wizard of Oz, in-app survey); automated experiment design from hypothesis keyword analysis; metric selection, success threshold definition, and effort/duration estimation.

Out of Scope: statistical power analysis or sample size calculation (use dedicated A/B test platforms); experiment infrastructure setup (feature flags, analytics instrumentation); running the actual experiment (this skill designs, not executes); long-term product strategy or roadmap decisions (execution/outcome-roadmap/).

Important Caveats: pretotyping validates demand and value, not usability or performance; in-app surveys are the weakest SITG signal — use only when behavioral experiments are impractical; the tool's keyword-to-signal matching is heuristic — override when domain knowledge dictates a better method.

Integration Points