You have an idea. You're excited. You want to build it. Stop. Before you invest weeks or months, ask: what's the fastest, cheapest way to test whether this core assumption is even true?
The goal isn't to prove you're right. The goal is to fail fast if you're wrong.
A good test is designed to disprove, not confirm.
Designing The Test
Identify The Core Assumption
Every plan rests on assumptions. Which one, if wrong, kills the whole thing? That's the assumption to test first. Don't test the easy stuff.
Define The Failure Criterion
Before running the test, decide: what result would mean "stop"? If you don't define failure upfront, you'll rationalize any result as success.
Minimize Investment
What's the cheapest version that still gives a real answer? Mockups before code. Landing pages before products. Conversations before surveys. Spend hours, not weeks.
Maximize Learning
The test should teach you something either way. "It didn't work" isn't enough. Why didn't it work? What did you learn that changes the next attempt?
Test Types By Cost
Talk to 5 potential users. Don't pitch - ask questions. Would they pay for this? Have they tried to solve this before? What did they do?
Put up a button for a feature that doesn't exist. Count the clicks. Demand is easy to claim, hard to fake. Let behavior reveal interest.
Deliver the service manually before you automate it. Do the work by hand. Learn what users actually need, not what you imagine they need.
Can you get people to pay before it exists? Money is the ultimate validation. Interest is cheap. Wallets don't lie.
It looks automated. It's actually you behind the curtain. Test the experience without building the engine. Reveal the magic only after validating the trick.
Run ads to a landing page. Measure signups before you build. If you can't get attention and interest, the product won't matter.
Before You Test
What's The Assumption?
State it explicitly. "People will pay $50/month for X" is testable. "People might like this" is not.
What Would Disprove It?
Define the bar. "If fewer than 5% of visitors sign up, we stop." Commit before you have data.
How Fast Can We Know?
Speed matters. A 48-hour test that's directionally right beats a 3-week test that's precise. Optimize for learning velocity.
What's The Cheapest Version?
Don't build the product. Build the test. Spreadsheets. Mockups. Manual processes. The test is disposable - invest accordingly.
Common Mistakes
Testing The Wrong Assumption
You tested whether people click buttons. You should have tested whether people pay. Test the riskiest assumption, not the easiest.
Moving The Goalposts
The test "failed," so you redefine success. This is rationalization, not learning. If you didn't hit your bar, admit it.
Over-Building The Test
The test became a mini-product. You spent a month on something meant to take a week. The test is disposable - treat it that way.
Ignoring Negative Results
"It didn't work because..." and then excuses. Maybe it just doesn't work. The test gave you information. Use it.
Most ideas fail. That's fine - if you fail fast and cheap. The tragedy isn't the failed idea. It's the years wasted on an idea that could have been disproven in a week.
Design the test. Define failure. Run it fast. Then decide whether to build.
Test before you build. Falsify before you invest.
