Run an experiment
A single trip around the Build-Measure-Learn loop. This skill turns a risky assumption into a falsifiable hypothesis, designs the smallest test that produces real learning, and logs the result. You work as the Analyst guide role (../../reference/roles.md). Read references/build-measure-learn.md before designing.
When to use
The user wants to test an assumption (usually the top one from prioritize-risks), needs help making it testable, or wants to record what an experiment taught them. Customer interviews are a kind of experiment but have their own skill (customer-interview); use this skill for landing-page / smoke / concierge / pricing / channel tests and for the general framing and logging of any experiment.
Core stance
- Maximize speed, learning, and focus together. Drop any one and you get a failure mode: no learning → chasing your tail; no speed → run out of resources; no focus → premature optimization.
- One key metric per experiment. Decide the single number you're moving and ignore the rest for this experiment.
- Smallest thing possible to learn. You rarely need code. Mock-ups, a landing page, a concierge ("Wizard of Oz") MVP, a manual back end, a fake-door button — pick the cheapest artifact that yields a real signal.
- Bold before product/market fit. Pre-fit, you learn most when the outcome is ~50/50, so prefer bold experiments (a different UVP, a different segment) over incremental tweaks. Save micro-optimization for after fit.
Procedure
- Load context. Read
.lean/risks.md (what's riskiest), .lean/PROGRESS.md (stage), and the canvas. Confirm which assumption this experiment attacks.
- Write a falsifiable hypothesis. Form:
[specific repeatable action] will [expected measurable outcome] — a statement that can be clearly proven wrong. Make the outcome a concrete number and threshold ("at least 20% of landing-page visitors will enter their email"), not "people will like it."
- Pick the single key metric and the success/fail threshold up front (pre-commit, so you can't rationalize a fuzzy result into a "yes").
- Design the smallest build. Choose the cheapest artifact that tests it (see the menu in
references/build-measure-learn.md). Define how you'll measure and the minimum sample/time to trust the signal.
- Run / record. When results are in, record the measurement, then the learning: did it validate or refute the hypothesis, and what decision follows (proceed / pivot / iterate / kill)? Capture surprising side-learning loosely as insights to fold into the canvas later.
- Write
.lean/experiments/<id>.md from assets/experiment-template.md (<id> like E1, E2). Update .lean/PROGRESS.md (a dated Journal line). If the result retires or moves a risk, update .lean/risks.md.
- Close the loop. Name the next experiment the result implies, and route (back to
prioritize-risks if the riskiest assumption changed, lean-canvas to fold in learning, measure-fit if you're accumulating fit signal).
Output
.lean/experiments/<id>.md — a falsifiable hypothesis, one key metric + threshold, the build, the measurement, and the learning/decision. A clear next action.
Related
prioritize-risks — supplies the assumption to test.customer-interview — the qualitative experiment type (its own skill).measure-fit — when experiments are about overall product/market-fit signal.references/build-measure-learn.md — the loop, the smallest-build menu, hypothesis examples.
1---2name: run-experiment3description: This skill should be used when the user wants to design or log an experiment to test a business-model assumption — "design an experiment to test X", "how do I validate this assumption?", "turn this into a falsifiable hypothesis", "what's the smallest test for this?", "set up a landing-page / concierge / smoke test", or "log the results of my experiment". It frames the assumption as a falsifiable hypothesis, picks a single key metric and the smallest build, and records the Build-Measure-Learn cycle to .lean/experiments/. Use it for the "systematically test your plan" step. For interviews specifically, use customer-interview; for judging product/market fit, use measure-fit.4---56# Run an experiment78A single trip around the Build-Measure-Learn loop. This skill turns a risky assumption into a falsifiable hypothesis, designs the smallest test that produces real learning, and logs the result. You work as the **Analyst** guide role (`../../reference/roles.md`). Read `references/build-measure-learn.md` before designing.910## When to use1112The user wants to test an assumption (usually the top one from `prioritize-risks`), needs help making it testable, or wants to record what an experiment taught them. Customer interviews are a *kind* of experiment but have their own skill (`customer-interview`); use this skill for landing-page / smoke / concierge / pricing / channel tests and for the general framing and logging of any experiment.1314## Core stance1516- **Maximize speed, learning, and focus together.** Drop any one and you get a failure mode: no learning → chasing your tail; no speed → run out of resources; no focus → premature optimization.17- **One key metric per experiment.** Decide the single number you're moving and ignore the rest for this experiment.18- **Smallest thing possible to learn.** You rarely need code. Mock-ups, a landing page, a concierge ("Wizard of Oz") MVP, a manual back end, a fake-door button — pick the cheapest artifact that yields a real signal.19- **Bold before product/market fit.** Pre-fit, you learn most when the outcome is ~50/50, so prefer bold experiments (a different UVP, a different segment) over incremental tweaks. Save micro-optimization for after fit.2021## Procedure22231. **Load context.** Read `.lean/risks.md` (what's riskiest), `.lean/PROGRESS.md` (stage), and the canvas. Confirm which assumption this experiment attacks.242. **Write a falsifiable hypothesis.** Form: **`[specific repeatable action] will [expected measurable outcome]`** — a statement that can be clearly proven wrong. Make the outcome a concrete number and threshold ("at least 20% of landing-page visitors will enter their email"), not "people will like it."253. **Pick the single key metric** and the success/fail threshold up front (pre-commit, so you can't rationalize a fuzzy result into a "yes").264. **Design the smallest build.** Choose the cheapest artifact that tests it (see the menu in `references/build-measure-learn.md`). Define how you'll measure and the minimum sample/time to trust the signal.275. **Run / record.** When results are in, record the measurement, then the **learning**: did it validate or refute the hypothesis, and what *decision* follows (proceed / pivot / iterate / kill)? Capture surprising side-learning loosely as insights to fold into the canvas later.286. **Write** `.lean/experiments/<id>.md` from `assets/experiment-template.md` (`<id>` like `E1`, `E2`). Update `.lean/PROGRESS.md` (a dated Journal line). If the result retires or moves a risk, update `.lean/risks.md`.297. **Close the loop.** Name the next experiment the result implies, and route (back to `prioritize-risks` if the riskiest assumption changed, `lean-canvas` to fold in learning, `measure-fit` if you're accumulating fit signal).3031## Output3233`.lean/experiments/<id>.md` — a falsifiable hypothesis, one key metric + threshold, the build, the measurement, and the learning/decision. A clear next action.3435## Related3637- `prioritize-risks` — supplies the assumption to test.38- `customer-interview` — the qualitative experiment type (its own skill).39- `measure-fit` — when experiments are about overall product/market-fit signal.40- `references/build-measure-learn.md` — the loop, the smallest-build menu, hypothesis examples.
TimboGP