When to use it
Use when you have a promising idea and want to validate before investing, when about to build on an untested assumption, or when the team is debating something that could simply be tested in days.
Core tool in The Test when you need evidence, not opinions.
How it works in The Studio
Here's how a session works with WAiDE:
Sample output
Here's what a Rapid Experiment design looks like in practice:
What you get
Clear experiment design: hypothesis, minimum viable test method, metric, and decision criteria (what counts as pass or fail). Designed to run in days, not months.
Foundation
Developed by Eric Ries in "The Lean Startup" (2011), building on Steve Blank's Customer Development methodology. Used by Y Combinator, Dropbox, Zappos, Airbnb, GE, P&G, and Microsoft innovation labs.
Why it works
Rapid Experiment works because the biggest enemy of innovation isn't failure — it's expensive, slow, late failure. The traditional product development model collects assumptions, bundles them into a full build, and discovers which ones were wrong after significant resources have been committed. The Lean Startup's core contribution was resequencing this: surface your riskiest assumption, design the cheapest possible test, learn, then decide whether to continue.
The scientific method has always known this. A hypothesis is only useful if it's falsifiable — if you can design a test whose result could, in principle, prove you wrong. Most business planning fails this test. Business plans are typically arguments, not hypotheses. They're structured to persuade rather than to learn. Rapid Experiment applies the discipline of scientific falsifiability to commercial questions: what would have to be true for this to work, and what's the cheapest way to find out if it is?
Dropbox's famous explainer video tested demand before a line of code was written. Zappos tested willingness to buy shoes online by manually fulfilling orders from a local shop before building any infrastructure. These aren't lucky hacks — they're applications of a principle: the unit of progress is validated learning, not features shipped. Every assumption that survives a cheap test becomes a foundation you can build on confidently.
The mechanism: The experiment discipline forces clarity before action. Most teams are fuzzy on what they actually believe and what they're actually testing. Articulating a hypothesis, a method, a metric, and a pass/fail criterion — before running anything — is itself valuable. It reveals disagreements, surfaces hidden assumptions, and creates shared language for evaluating the result.
Frequently asked questions
How small does the experiment need to be?
Small enough to run in days, not weeks. The test should be designed to answer one question — not validate the entire concept, just the single riskiest assumption underneath it. If your experiment takes more than a week to run, it's almost certainly trying to answer too many questions at once. WAiDE will help you find the version you can run by Friday.
What if the experiment fails?
A failed experiment is only a failure if you haven't defined in advance what "fail" means and what you'll do when it happens. WAiDE asks you to set decision criteria before running the test — if the result is X, we pivot; if it's Y, we continue; if it's Z, we stop. A result that triggers a pivot or a stop is exactly what the experiment was designed to produce. That's learning, not failure.
How do I know which assumption to test first?
Test the assumption whose failure would kill the entire idea. Not the assumption you're most curious about, or the one that's easiest to test — the one that, if wrong, makes everything else irrelevant. This is usually the demand assumption (will anyone actually want this?) rather than the technical or operational assumptions that teams tend to reach for first because they feel more controllable.
Isn't a small experiment too artificial to produce valid results?
The question isn't whether the experiment is perfect — it's whether it's more informative than not running it. A concierge test, a landing page, a wizard-of-oz prototype, or five customer conversations will always surface something you didn't know. The alternative is building more and learning later, which is almost always more expensive and more misleading, because by then you're too committed to change course.