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. The way to shorten isn't coding faster but stepping down the ladder: if the software MVP takes 4 months, can the same hypothesis be tested with a 2-week Wizard of Oz setup? Timelines usually stretch because there's more than one hypothesis reduce to one, and the scope shrinks by itself.
Users criticize the MVP as "incomplete" should I add features?
First check who the criticism comes from: an "it'd be great if" request from someone actively using the core flow is valuable (a roadmap signal); a "this is missing, that is missing" critique from someone who never activated is usually segment mismatch the product isn't for them anyway. The second filter is the hypothesis link: does the requested feature strengthen the core value, or open a new problem area? Adding new territory onto a core with unproven retention produces two half-products. The combination of "incomplete" complaints + strong retention is actually ideal: the value is real, and expansion is yours to schedule.
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 "they loved it while free, left when it wasn't" scenario. Legitimate early softeners: founder pricing (a lifetime discount), long trials, unconditional refunds. Launching free is defensible in network-effect products (a crowd is required for liquidity) and where usage data itself is the hypothesis. Even then, willingness to pay should be tested in parallel with a separate experiment (pre-sales, a fake-door pricing page).
The MVP looks like it's failing do I change the product or the segment?
Separate the diagnostic layers first: if activation is low (signups never see the value), the problem is usually onboarding or value communication fixable without changing the product. If activation is good but retention is weak, question the core value hypothesis: run exit interviews ("why didn't you come back?"). If one sub-segment retains strongly (check the cohort breakdown), change the focus, not the product: narrow to that segment. If no layer shows a signal, the MVP has done its job you make the pivot with data in hand.