Run experiment

Skill TimboGP/timbogp-marketplace/plugin/lean-coach/skills/run-experiment

A Claude Code plugin that turns the agent into a structured tutor over your own materials — per-topic sub-projects, curricula, and bracketed study sessions, with domain overlays. Domain-agnostic.

Install

npx -y skills add TimboGP/timbogp-marketplace --skill run-experiment

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

4.2 KB, as published. Nobody here has run it

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.

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.