The MVP Guide: Maximum Learning from a Minimum Product
An MVP (minimum viable product) is not your product's first version it is the smallest experiment that tests your solution hypothesis with real usage. "Minimum" is measured in learning, not engineering effort: the smallest thing that can answer "do people actually use this and come back?" The real mistake in most MVPs isn't being too small it's being too big.
The Single-Flow Rule: Setting the Scope
The practical formula for MVP scope: one segment, one problem, one end-to-end flow a single path that works completely beats five features that half-work. The scope test for every feature: "If this is removed, does the core hypothesis become untestable?" If no, it's outside the MVP. The shift-planning example: creating a plan + sharing it + change notifications = the core flow; reporting, leave management, payroll integration = later. Even "hygiene" features settings pages, profile editing, password reset can be manual/hand-assisted in the first round.
MVP Types: A Ladder by Code Intensity
The "MVP = a small piece of software" assumption is needlessly expensive; the ladder by code intensity:
| Type | Setup | When |
|---|---|---|
| Concierge | Delivering the service fully by hand, visibly human | While the value proposition is uncertain; while learning the process |
| Wizard of Oz | The front end looks automated, humans behind it | Before proving automation is worth building |
| Single-feature MVP | Real software for the core flow only | After the concept is validated in prototypes |
| No-code MVP | A flow assembled from off-the-shelf tools | When speed is critical; when there's no technical team |
The ladder's logic: each rung validates the investment decision of the rung above. Writing software before serving 10 customers by hand via concierge means automating a process you never learned.
MVP Metrics: Usage > Signups
An MVP's success measure isn't downloads/signups but reaching the value moment and coming back:
- Activation: The share experiencing the core value in their first session ("created their first shift plan") count those who saw value, not those who registered
- Retention: The week 1-2-4 return curve; the MVP's most honest metric. If the curve flattens somewhere (not everyone leaves), the core value works for some group
- Usage depth: The core flow's repeat frequency (for a weekly planning tool, once a week is "good" interpret the metric against the product's natural frequency)
- Qualitative signal: User complaints are actually positive the complainer cares. Silence is the worst signal
Hypothesis discipline applies here too: before building, write "which metric, at which threshold, validates the hypothesis?" (e.g., "25% retention at week 4").
The Forgotten Half: "Viable"
Founders fixated on minimum forget "viable": the MVP can be small, but it must actually do the core job. A half-working core flow tests nothing you can't tell whether users left because "there's no value" or because "there are bugs." The practical line: narrow scope, high quality bar on the core flow. Edge cases can be handled manually ("message us on WhatsApp if anything breaks" is a legitimate early support channel), but the main path must be reliable.
FAQ
How fast should I ship the MVP?
The calendar target depends on context, but the direction never changes: weeks, not months. An MVP plan longer than 6 months is almost certainly a scoping error it's a v1.0 wearing the "MVP" name. Shorten by stepping down the ladder instead of coding faster: if software takes 4 months, can a 2-week Wizard of Oz test the same hypothesis?
Users criticize the MVP as "incomplete" should I add features?
Check who the criticism comes from first: an "it'd be great if" request from an active core-flow user is a roadmap signal; a "this is missing" critique from someone who never activated is usually segment mismatch. Then check the hypothesis link does the feature strengthen core value, or open new territory? "Incomplete" complaints plus strong retention is actually ideal.
Should I charge for the MVP or launch free?
Charge from day one if you can: payment is the strongest validation signal, and it pre-empts the "loved it free, left when it wasn't" scenario. Legitimate softeners include founder pricing, long trials, and unconditional refunds. Launching free is defensible in network-effect products or where usage data is the hypothesis itself, but test willingness to pay separately either way.
The MVP looks like it's failing do I change the product or the segment?
Separate the layers first: low activation usually means an onboarding or communication problem, fixable without touching the product. Good activation but weak retention means the core value hypothesis is wrong run exit interviews to find out why. If one sub-segment retains strongly, narrow to that segment instead of changing the product itself.