Skip to content
Back to Idea Validation

Lean Validation

Apply the Build-Measure-Learn loop to validate ideas with minimal effort.

Why

Most ideas fail not because the technology is wrong, but because nobody wants the result. Lean validation forces you to test the riskiest assumption first — usually "will anyone care?" — before sinking weeks into building. Teams that skip this step routinely ship products that get 50 signups and then go flat. The loop is cheap: a landing page costs an afternoon, a week of measurement costs nothing, and the learning either kills the idea fast or de-risks it for the next step.

When

Day 1 of a new idea, before any code. Run 2-3 loops (1-2 weeks total). Stop when you have either a clear "kill" signal or 3+ validated assumptions in a row.

How

1. Identify the riskiest assumption
   - Write down all assumptions, rank by "if this is wrong, everything fails"
   - The top one is usually about demand: "people will pay / switch / use"

2. Build the smallest test for that assumption
   - Demand test: landing page with email capture + a "how it works" section
   - Usability test: clickable Figma prototype shown to 5 target users
   - Value test: concierge MVP where you manually deliver the service

3. Measure with real numbers
   - Landing page: conversion rate of visitors → email signups (aim > 5%)
   - Prototype: task completion rate + qualitative reactions
   - Concierge: how many ask to continue / pay after the first delivery

4. Learn and decide
   - Validated → move to next riskiest assumption, repeat
   - Invalidated → kill or pivot, do NOT rationalize weak signals
   - Ambiguous → tighten the test (better audience, clearer value prop)

Example

Idea: "A tool that auto-generates release notes from git commits."
Riskiest assumption: devs will switch from manually writing release notes.

Loop 1 — Landing page (2 days):
  - Built on Carrd, headline "Stop writing release notes by hand"
  - Posted to r/programming and 2 Discord dev servers
  - Result: 340 visitors, 28 emails (8.2% conversion) ✓

Loop 2 — Concierge MVP (1 week):
  - Emailed the 28: "send me your repo, I'll write your next release notes free"
  - 6 replied. Manually wrote excellent notes for each.
  - 4 of 6 asked "can you do this every release? I'd pay $20/mo" ✓

Decision: validated demand + willingness to pay → proceed to MVP.

Common Problems

  • ⚠Testing the easiest assumption instead of the riskiest one — you validate something that was never in doubt and ignore the real threat.
  • ⚠Measuring vanity metrics (page views, likes) instead of action metrics (signups, pre-orders, retention intent).
  • ⚠Rationalizing weak signals: 2 signups from friends is not validation, it is politeness.
  • ⚠Running the loop too slowly — 3 weeks per cycle means you learn 3x slower than a competitor doing it in 1 week.

Best Practices

  • ✓Write your kill criteria before you start the test: "if conversion < 3%, I kill the idea" — pre-commitment prevents post-hoc rationalization.
  • ✓Test with strangers, not your network — friends and colleagues are biased toward encouragement.
  • ✓Time-box every loop to 1 week max; if you can't test in a week, your test is too complex.
  • ✓Keep a validation log: assumption, test, result, decision — patterns emerge across loops that single tests miss.