Lesson 1 of 6

What Validation Really Means

Validation is not a vote of confidence. It is a loop of cheap experiments that kill bad assumptions fast.

7 min read

Validation has become a word people use to mean someone told me my idea was good. That is not validation. That is a compliment, and compliments are free. Real validation is a loop: you write down the riskiest thing you believe, you run the cheapest possible test of it, and you let the result change your mind. The founders who waste a year building the wrong thing are almost always the ones who skipped this loop because they were sure.

Your idea is a stack of assumptions

Every idea, no matter how obvious it feels, is really a stack of bets. That the problem is real. That enough people have it. That they want it solved badly enough to pay. That you can reach them. That they will pick you over the workaround they use today. Each of those is a guess until you test it, and the whole idea only works if most of them turn out true.

The danger is that the idea feels like one solid thing in your head, so you defend it as one thing. Breaking it into separate assumptions is the first useful move, because now you can see which bets are load-bearing. If the problem is not real, nothing else matters. If people have the problem but will never pay, nothing else matters. Find the assumptions that would sink the whole thing and test those first.

Problem: do the people you have in mind actually struggle with this, often?
Willingness: do they already spend money or real time working around it?
Reachability: can you find and talk to them without a marketing budget?
Switch: is your version enough better that they would leave what they use now?

Build, measure, learn, and keep the loop small

The Lean Startup gave this loop a name: build, measure, learn. You build the smallest thing that tests an assumption, you measure what real people do with it, and you learn enough to either keep going or change direction. The point people miss is the size of the loop. The first build is almost never software. It is a conversation, a landing page, a spreadsheet you run by hand. The smaller the loop, the more times you can go around it before your money or motivation runs out.

Speed matters more than polish here because each loop buys you information, and information is what kills bad ideas cheaply. A founder who runs ten loops in a month learns ten things. A founder who spends that month building learns one thing, late, after it is expensive to act on. You are not trying to be right on the first guess. You are trying to be wrong quickly and cheaply enough that it does not hurt.

A good test can prove you wrong

The test that only ever confirms you is not a test. If you ask a friend this is a good idea, right, there is no answer that would make you stop, so you have learned nothing. A real experiment has a result you would not want: a number you would be unhappy to see, a sentence from a customer that means you should quit. Decide that result in advance, before you run the test, or you will move the goalposts the moment the data is awkward.

This is also why your own enthusiasm is not evidence. You will always believe in your idea more on Tuesday than the market does. The job of validation is to find out what people do when you are not in the room asking leading questions. If you build the loop so it can fail, and it keeps not failing, that is when you have something.

Worked example

Dropbox tested demand with a video, not a product

Before Dropbox was a working product, file syncing that just worked was a hard engineering problem and a big bet. Instead of spending a year building it to find out if anyone cared, the founder made a short demo video showing how it would work, aimed at an audience of early adopters who would understand it. The riskiest assumption was not can we build this. It was do people want this enough to sign up.

The waitlist jumped from a few thousand to tens of thousands overnight. That was one loop: build a video (cheap), measure signups (real behavior), learn that demand was there (keep going). The product still had to be built, but now it was being built against proof instead of hope.

Learn by doing

Paste these into ChatGPT or Claude and run them against your own idea. The model will answer happily. Olune goes further and checks the answer against real Reddit threads, competitor maps, and keyword volume.

Tip: grab the downloadable playbook to run every play with fill-in worksheets →

Prompt 1 · Break your idea into its riskiest assumptions.

Here is my startup idea: [describe it in two sentences]. Act as a skeptical lean-startup coach. List the assumptions this idea depends on to be true, then rank them from most to least likely to kill the idea if it turns out false. For the top three, suggest the cheapest test I could run this week to find out, without building the product.

What a good output looks like

It surfaces bets like freelance designers lose real money to late invoices (test: ten interviews about their last late payment), they will switch from their current spreadsheet (test: ask what they tried before and why they stopped), and they will pay 19 a month (test: a pre-order page). Ranked by which one, if false, ends the idea.

Prompt 2 · Design a test that can actually fail.

I want to test this assumption: [assumption]. Design an experiment where I decide the pass or fail number before I run it. Tell me what to build (the smallest possible thing), what to measure, and the specific result that should make me stop or change direction.

What a good output looks like

For example: build a one-page site with a real Start free trial button, drive 100 visitors from a relevant subreddit, and call it a fail if fewer than 5 click through. The number is set in advance, so the result decides for you instead of your mood deciding.

Key terms in this lesson

Takeaways

Your idea is a stack of assumptions, not one solid thing. Test the load-bearing ones first.
Build, measure, learn. Keep the loop small enough to run ten times, not once.
If a test cannot produce a result you would hate, it is not a test.
Your enthusiasm is not evidence. Watch what people do when you are not selling them.

Now run your own idea through it.

You have the method. Olune does the legwork: an honest build-or-kill verdict on live Reddit signals, competitor maps, and keyword volume, in about eight minutes. Free to start.

Test your idea →

Common questions

Is validation just market research?

No. Market research tells you what people say. Validation watches what they do, usually by asking them to give up something real: their time, their email, or their money. A survey where 80 percent say they would buy is not validation. Ten pre-orders is.

How long should validating an idea take?

Less time than building it. The whole point is to run cheap loops over days and weeks, not months. If your validation plan takes three months, it has quietly turned into a build plan. Shrink the experiments until each one takes days.

What if I validate and the answer is no?

That is a win, not a loss. You just saved the months you would have spent building something nobody wanted. Most ideas should get a no. Finding it in a week is the cheapest no you will ever get.