Guides · Client education
How to validate an MVP.
An MVP is not a smaller product; it is a larger question with software attached. Validation means designing the question before spending the budget - here is the sequence we run with founders in MVP Sprints.
Before any code
- State the bet. “We believe [user] will [action] because [problem].” If the sentence has two audiences or three actions, you have two or three MVPs - pick one.
- Choose the kill metric. One number, one horizon: what result within 90 days makes this worth continuing - and, harder, what result makes you stop? Deciding the second one after launch is how zombie products happen.
- Test demand cheaply first. Twenty real conversations, a landing page with a genuine sign-up, a concierge version done by hand - a week of this routinely reshapes (or cancels) a quarter of engineering. We say this as the people who sell the engineering.
Scoping the build
- One workflow. The single path that proves the bet: sign in, do the thing, see the value. Everything else - roles, settings, integrations, the admin plane - waits.
- Real from week one. Real authentication, real deployment, real data by week three. A prototype that must be rebuilt for launch is a validation tax paid twice.
- Instrument the funnel before launch. If sign-up → first-value → return isn’t measured on day one, month two’s decisions will be vibes with charts.
Reading the result honestly
Ten paying strangers beat a thousand free sign-ups from friends. Retention beats acquisition. And a clear no is the second-best outcome an MVP can produce - it refunds the rest of the roadmap. The failure mode is not a failed test; it is a mushy one that justifies continuing by default (pattern two).
Have a bet worth testing?
A strategy call turns it into a one-workflow scope with a kill metric - free, and we will tell you if a landing page should come before us.
Related: MVP planning guide · Why projects fail · Shipped MVPs