Validating an Idea vs Validating a Product: What's the Difference?

A founder DM'd us last month with a single line: "my product validation came back at 4% CVR — should I kill?" Three follow-up questions in, the picture got sharper. He had not built a product. He had run a Reddit-ad smoke test on a landing page. The 4% number wasn't product validation. It was idea validation. He was confused about what he had measured, and he was about to walk away from a viable idea using the wrong rubric.

That confusion is the rule, not the exception. "Validation" gets thrown around as one umbrella word for two operations that test completely different things, and the conflation has cost real founders real money — sometimes hundreds of millions, as we'll see.

Idea validation answers do they want it?. Product validation answers does what we built actually work? Two questions, two phases, two toolkits, two failure modes. Treating them as one is how you end up with a $400 Wi-Fi-connected juice press nobody asked you to build.

This piece is the disambiguation guide. We'll define each one, give the side-by-side, walk five named cases — Buffer, Dropbox, Zappos, Juicero, Superhuman — and end with the case where the distinction doesn't matter. Read the validate or build an MVP first post for the order-of-operations argument; this one is about clearing the conceptual fog underneath it.

The one-line distinction (and the three-stage map)

The cleanest version of this lives in three stages, not two:

We'll use idea validation as shorthand for problem + solution validation throughout — they're the two pre-build halves and the same toolkit covers them. Product validation is the post-build operation. Marty Cagan calls these the four big risks — value, viability, usability, feasibility. Idea validation mostly attacks value and viability. Product validation mostly attacks usability and feasibility. Naming the four risks beats naming the two stages, and we'll come back to it.

What idea validation actually looks like

Idea validation is the demand-signal phase. The question is whether anyone outside your head wants the thing — measured by behaviour, not by stated intent.

Three textbook cases:

Joel Gascoigne / Buffer (2010). Two-page landing site. Page A explained the product. Page B added pricing. People who clicked through got a "we're not ready yet" message and a chance to leave their email. Joel's own framing: "I wasn't optimizing for the number of signups I could get with this landing page, I was instead trying to learn as much as I possibly could." Seven weeks in, he had 120 signups. Fifty of them activated when the product shipped. First paying customer landed three days after launch. He had validated the idea — that someone, somewhere, would pay for a Twitter scheduler. Whether the eventual product would retain users and survive a feature war was a different question, addressed differently, later.

Drew Houston / Dropbox (2007). No product. A four-minute screencast posted to Hacker News titled "My YC app: Dropbox — Throw away your USB drive". Waitlist went from roughly 5,000 to 75,000 in a single day. Sequoia led the seed round shortly after. The video was idea validation by analogy — it tested whether anyone wanted seamless cross-device sync at all. The actual sync engine, the kernel hooks, the conflict resolution — those were product-validation problems Drew's team fought for the next several years. Same company, two distinct validations, separated by years.

Nick Swinmurn / Zappos (1999). Photographed shoes at a local San Francisco store, posted them online, bought the pair retail when an order came in, shipped it himself. The question was whether anyone would buy shoes online without trying them on. The answer arrived as cash — $8.6M of revenue by 2001. The Zappos product (warehouse, returns engine, search, recommendations) didn't exist for years. The idea was validated long before the product was built.

The pattern across all three: zero product, real behavioural signal, single question answered. The artifact (page, video, hand-fulfilled order) was a probe, not a product. The team learned what they needed without paying the cost of the wrong build.

This is the half of validation LemonPage was built for. A landing page wired to Reddit, Meta, and Google ads with measurement in one workflow — the modern version of what Buffer hand-rolled in 2010. If you're at the do they want it? phase, that's what we do; the 48-hour validation sprint and the $100 Meta-ads test are the playbooks that use it.

What product validation actually looks like

Product validation kicks in once code is shipping. The question changes from will anyone want this? to does what we built actually work for the people using it? — and it's a question only post-launch behaviour can answer.

The canonical case is Rahul Vohra and Superhuman. The idea — "people want a faster email client" — was idea-level obvious; nobody needed a smoke test to confirm demand for better email. The whole Superhuman story is product validation, dressed up as a measurable program.

Vohra ran the Sean Ellis 40% test — a single survey question to active users: how would you feel if you could no longer use this product? The threshold: 40%+ answering very disappointed indicates product-market fit. Below 40%, you don't have it.

Superhuman's first run came back at 22%. Vohra's framing: "With only 22% opting for the ‘very disappointed’ answer, it was clear that Superhuman had not reached product-market fit." Notice what the test was answering. Not does email matter? — it answered does our specific product, as built, hit the bar?

Three quarters of work later — segmenting to power users, doubling down on features they cited, cutting ones they didn't — the score reached 33%, then 58%. They crossed the threshold not by changing the idea but by changing the product. Same idea, three different products, three different measurements.

That's the texture of product validation. The toolkit is different too:

• PostHog, Mixpanel, Amplitude for behaviour (activation, feature use, retention curves).
• Sean Ellis 40% surveys and CES/CSAT measurements for declared satisfaction once you have actual users.
• Maze, UserTesting for usability tests on real flows.
• Linear, Sentry, Datadog for the delivery side — does it actually work, technically.

LemonPage doesn't pretend to do this half. We're the demand-signal slot. Once you've shipped, you're in PostHog territory and a different conversation. Pretending one tool covers both halves is what muddies the rubric in the first place.

The two failure modes — and what each one looks like

Treating idea validation and product validation as a linear waterfall ("first idea, then product, all is well") hides two failure modes that look nothing alike.

Failure mode A: idea validated, product wasn't — Juicero

The cold-pressed-juice market is real. People buy expensive juice. That much was true and confirmable in five minutes.

What Juicero didn't validate was the product. They built a $400 Wi-Fi-connected press that required proprietary packets — and never tested whether the appliance solved a real pain or whether customers would tolerate the lock-in. Bloomberg reporters demonstrated in April 2017 that you could squeeze the packets by hand and get the same juice. The product was unnecessary infrastructure on top of a validated demand. Juicero raised $120M and shut down roughly 17 months after launch.

The autopsy reads cleanly under our two-question split: idea passed (people want premium juice subscriptions), product failed (the appliance didn't earn its place). A founder who had separated the two questions would have run a usability and willingness-to-pay test on the appliance before raising $120M to manufacture it.

Failure mode B: product worked, idea wasn't there — Quibi

Quibi spent roughly $1.75–2B and shut down six months after launch with about 500K subscribers. The technical product worked — the streaming platform, the encoding, the talent pipeline. Founder Jeffrey Katzenberg's own retrospective blamed "timing" and conceded "the idea wasn't viable enough."

What Quibi skipped was the demand half. Did consumers want to pay for short-form video when YouTube and TikTok are free? That's an idea-validation question, answerable for under €1,000 with a paid-traffic test on the value proposition. Quibi launched without that test and discovered the answer was no, in public, with billions of dollars on the line.

A reverse-Juicero. Product validation cleared (the thing worked). Idea validation never happened.

Why this matters

The two cases would look identical to anyone using "validation" as a single word. Both companies "validated" something. Both still failed. The disambiguation is what tells you which validation step was missing — and therefore what kind of test would have caught it.

The CB Insights post-mortem analysis of failed startups found 42% cite "no market need" as a top reason — that number is the cost of skipping idea validation. It's the single most common cause of death across the 110+ founder post-mortems they tracked.

"I'm validating my idea" usually means something else

A lot of founders saying "I'm validating my idea" are doing post-build product validation in disguise. They built the MVP three months ago. They're now running surveys on the people using it, calling it validation. That's product-validation work, and the more honest framing surfaces the question that should have been asked twelve weeks earlier: did anyone want this thing?

We see it constantly. Founders who already shipped the MVP and are now scrambling to justify the build by re-labelling user research as "validation". It's not wrong — they should absolutely measure activation and retention. But the language obscures what's happening. Cagan's four risks help: pre-build, you're testing value and viability. Post-build, you're testing usability and feasibility. If your "validation" is happening on a built product, you're in the second column. The first column was your chance and you spent it shipping code.

The cleanest mental upgrade: when you say "I'm validating my idea", name the risk you're attacking. "I'm testing value risk via a $200 Reddit ad campaign." That sentence won't be confused for a Sean Ellis test, and a Sean Ellis test won't be confused for an ad CTR.

Surveys and "would you pay?" answers aren't validation either

Rob Fitzpatrick's The Mom Test puts this most sharply: "Opinions at the ‘idea’ level are useless; what really matters are facts." People lie to be polite. Stated intent is not validation. Behaviour is.

This applies equally to both halves:

• Idea validation: "Would you pay for this?" said over coffee is folklore. "Did this stranger click the ad and put their card in the form?" is data. The stranger doesn't owe you politeness.
• Product validation: "I love your product" said in a feedback session is folklore. "Did this user come back in week 4?" is data. Retention doesn't flatter.

Stated-intent surveys are confirmation theatre dressed as validation. Whether you're pre- or post-build, demand the behavioural artifact: a click, a payment, a return visit. Stated answers are signals about politeness, not product.

When the disambiguation doesn't matter — Alexander Chen's case

We won't pretend this distinction matters in every situation.

Alexander Chen argued explicitly against idea validation for one specific scenario: the founder is the user, the build cost is near-zero, and the build time is under a month. He shipped a keyboard-layout side project in one night without validation, picked up organic traffic over years, and built an audience. His framing: "When you follow passion, unexpected things can happen."

He's not wrong — and he's not arguing product validation is unnecessary. He's arguing that idea validation is over-applied when the cost of building the artifact is lower than the cost of testing the demand for it. If you can ship in a weekend and you are the user, the build is its own validation.

Two sanity checks before invoking this exemption:

• Is the build genuinely a weekend? Not "I think it's a weekend." Most founders underestimate by 5x.
• Are you actually the user? Or is it more accurate to say you'd like to be the user once you have time?

Both of those go yes, and the build is the test. The two of us would estimate that's true for maybe 5% of pre-MVP situations we see — the rest fall back into the standard rubric.

How to use this rubric on your next test

Before you start any validation work, write down on a single line:

1. Which risk am I testing? (Value / viability / usability / feasibility.)
2. What's the artifact? (Landing page, pre-sale, demo video, in-product survey, retention dashboard.)
3. What's the kill criterion? (Pre-committed number, written down, no permission to rationalize past it.)

If the answer to (1) is value or viability and you haven't shipped yet, you're doing idea validation. The toolkit is paid traffic + landing page + behavioural CTAs (deposits, pre-sales, waitlist). LemonPage handles the demand-signal slot — page, ads, measurement in one workflow. The internal links above point to the playbooks.

If the answer to (1) is usability or feasibility and you've shipped, you're doing product validation. The toolkit is PostHog/Mixpanel + a Sean Ellis survey + Maze/UserTesting. We don't recommend LemonPage for that — different problem, different tools.

If you're not sure which one you're doing, you're probably about to confuse them. Stop, name the risk, pick the artifact, write the kill criterion. Then run.

FAQ

What's the actual difference between idea validation and product validation?

Idea validation tests demand: will anyone want the thing? It happens pre-build, with artifacts like landing pages, paid ads, pre-sales, and deposit waitlists. Product validation tests delivery: does what we built actually work, retain, and earn back? It happens post-build, with cohort retention, the Sean Ellis 40% test, usability sessions, and behavioural analytics. Buffer's 2010 landing page was idea validation; Superhuman's 22% → 58% climb was product validation. Same word, two operations.

Is problem validation the same as idea validation?

We treat problem validation as part of idea validation — both happen pre-build, and the same toolkit (interviews, ads, landing pages) covers both. Some frameworks split them out: problem validation tests does the pain exist?, solution validation tests does our proposed shape sound right?. Useful split for fundraising decks. For practical purposes, they're the same phase against the same risks (value, viability), just with different artifacts.

Can a startup fail because they only did one half?

Yes — and the two failure modes look nothing alike. Juicero validated the idea (premium juice subscriptions sell) and skipped the product validation (does the $400 appliance earn its place?) — they raised $120M and shut down in 17 months. Quibi validated the product (the streaming worked) and skipped the idea validation (will consumers pay for short-form video when YouTube is free?) — $1.75B raised, six months live. Skip either half, and the post-mortem is brutal.

Where does product-market fit (PMF) sit in this?

PMF is the outcome of successful product validation, not a separate phase. The Sean Ellis 40% threshold — 40% of users answering very disappointed if they could no longer use the product — is the canonical PMF measurement. Reaching it means the built product retains, satisfies, and grows organically; it says nothing about whether the original idea was right (Quibi probably had decent product satisfaction in its tiny user base before it shut down). PMF is a product-validation milestone, not an idea-validation one.

What about the founder who insists "validation is overrated"?

There's a defensible version of that argument — Alexander Chen's case, where the founder is the user, build time is under a month, and the build cost is near zero. In that scenario, the artifact is the test, and a separate validation step is wasted motion. Outside that scenario — most founders, most products — validation is what separates the 42% of failures CB Insights pins on "no market need" from the 58% that found a market and failed for other reasons. The argument is real for a small slice. It's not a general license.

Should I use the same tool for both kinds of validation?

No. Idea validation needs a landing page wired to paid traffic with conversion measurement (LemonPage, Carrd + Meta Ads, Webflow + Google Ads). Product validation needs behavioural analytics, retention dashboards, and survey infrastructure (PostHog, Mixpanel, Amplitude, Sean Ellis surveys via Typeform or Refiner). The toolkits don't overlap, because the questions don't. A single "validation tool" is usually a marketing claim, not a useful product.

Idea validation answers do they want it?. Product validation answers does what we built actually work?. Mix them up, and you'll either ship a Juicero or launch a Quibi — and the post-mortem will read the same regardless.

Name the risk. Pick the artifact. Write the kill criterion. Then test the right thing.