MVP Without the Perfectionism — Ship the Test, Not the Polish

Short answer: define the single signal you're testing, ship the ugliest version that produces that signal

Eric Ries's The Lean Startup (source) defines MVP as the smallest thing you can build that produces validated learning about a real customer behaviour. Not 'the v1 of the eventual product, simplified.' Different category. An MVP exists to settle a specific question: will people pay, click, sign up, return. If your MVP doesn't have a specific question and a way to read the answer, it isn't an MVP — it's a small product you'll polish forever. The perfectionism trap isn't about quality standards; it's about the absence of an experiment frame. The cure isn't lowering standards. The cure is naming the question.

Why perfectionism wins when the experiment is undefined

If you don't know what signal you're reading, there's no way to know what's enough. Every polishable element is a possible reason something didn't work; you can never stop polishing because there's no version of done. The MVP gets postponed indefinitely, and the build becomes the perfectionist's natural habitat — a place where shipping is always one more iteration away. Naming the signal collapses this. 'I am testing whether people pay for X' makes every other element marginal: if the signal can be read without it, it's not required to ship.

Six MVP shapes that ship in days, not months

• Landing page + paid traffic. Build no product. Build a page describing the product, add a 'sign up' or 'buy' button. Drive 200-500 visitors via cheap ads. Conversion rate is the signal. Cost: days, not months.

• Concierge MVP. Deliver the service manually, by hand, to 5 customers. No software. You're the algorithm. The question is whether the outcome is valuable enough that people pay; the software exists to scale a thing that works, not to discover whether it would.

• Wizard of Oz. Frontend looks real and automated; backend is humans hidden behind the curtain processing requests manually. User experience is the product; the engine doesn't need to exist yet to test the experience.

• Pre-order with deadline. Sell first, build only if you reach N pre-orders by a public deadline. If you don't reach the threshold, you found out cheaply. If you do, you have funded validation. Either way you stopped wasting months on what nobody would pay for.

• Borrowed audience demo. Post a working demo to one community where your potential customers actually are (subreddit, Slack group, forum). Honest 'I'm testing X' framing. Specific signal: how many people DM you, comment, click. Cheap, fast, real.

• Single-feature product. Build exactly one feature that solves exactly one problem. No settings, no onboarding, no roadmap. Question: do people return? Single-feature MVPs are the slowest of these six to build but still 10× faster than the multi-feature product you'd otherwise prototype.

How to pre-decide what 'good enough' looks like

Before you start building, write down: the question, the success criterion, the kill criterion, and the deadline. 'I am testing whether B2B teams will pay $X/month for feature Y. Success: 5 paid signups in 14 days. Kill: under 100 visitors converting at under 1% in 14 days. Deadline: 14 days from launch.' This four-line document is what makes shipping possible. Perfectionism feeds on ambiguity; pre-decided criteria starve it. When you hit the success or kill criterion, the experiment ends. You don't keep polishing past it.

Why ADHD founders are especially served by this

ADHD founders often have a specific failure mode: build for the dopamine of building, postpone the validation because it triggers RSD (what if no one signs up?). The MVP frame inverts this — the only point of building is the validation read. The four-line document also externalizes the decision, removing the in-the-moment 'is this done?' judgement that ADHD brains find exhausting and avoid. Build less, learn faster, recover the energy that polishing consumed for no return.

FAQ

But my product needs more than one feature to work

Probably true for the final product. Not true for the validation. The MVP isn't the eventual product — it's the smallest test of the riskiest assumption. Pick the assumption that, if false, kills everything else. Test that. If that one passes, the multi-feature build becomes worth doing. If it fails, the multi-feature build was going to fail anyway and you saved months.

Won't an ugly version damage my brand?

At MVP stage you don't have a brand to damage. The number of strangers who will form a lasting opinion of your business based on the rough early version is statistically zero. The version that polished customers will see months from now is far from your current build anyway. Brand damage is a stage-of-business question; you're not at that stage yet.

What if I get to the deadline with no clear signal?

Then your test was poorly designed — not enough traffic, ambiguous conversion, criterion too vague. The lesson is mostly about test design, not product. Tighten the test (more traffic, clearer call-to-action, more specific signal) and run it again with a shorter cycle. Most first MVPs teach more about how to MVP than about the product.

What if I love building and hate testing?

Common. The fix is to put the test before the build, not after. Pre-decide and pre-launch the experiment with friends or a community. The launch is then unavoidable: people are waiting for the thing. Building becomes a constraint on shipping, not a way to avoid it. The discipline isn't 'force yourself to test' — it's 'engineer the situation where you must.'

Smallest move today?

Write the four-line document: question, success criterion, kill criterion, deadline. Don't open the editor. Don't write code. Just the four lines. Then pick which of the six MVP shapes the four lines actually need. Most often it's the landing-page or concierge version — not the build you were planning. The document re-points you at the experiment.