METHODOLOGY

MVP

Minimum Viable Product

The smallest version of a product that lets you learn whether the idea is wrong. Not the smallest version that ships, the smallest version that teaches.

Last reviewed: 2026-05-24 byKevin Riedl wiki β†—

The word "viable" does the work in MVP, and almost everyone gets it wrong. Viable does not mean "a stripped-down version of the eventual product". Viable means "sufficient to test the hypothesis that this product is worth building". A landing page with a waitlist can be an MVP. A working product with three features can be a worse MVP than the landing page.

The most common failure: building the MVP you imagined six months ago instead of the MVP that tests this week’s most uncertain assumption. Every week the assumption you should be testing changes. Most MVPs are obsolete before they ship.

Wavect’s discovery phase exists in part to fix this. Before scoping the MVP build, we name the hypothesis it needs to test. If the hypothesis is "users want feature X", the MVP is not a polished feature X; it is the cheapest possible way to find out.

// FAQ

FAQs

FAQs

Confusing ‘minimum’ with ‘small version of the final product’. The right MVP tests this week’s riskiest assumption with the cheapest possible artifact. A landing page, a Wizard-of-Oz demo, or a Figma click-through often beats a real working build for the same learning.
If the build phase is over 8 to 12 weeks, you are probably not building an MVP, you are building V1 under a different name. The point of an MVP is fast learning, not feature-complete launch. If discovery says you need six months of build before you can test the hypothesis, the hypothesis is wrong-sized.
Polished enough that users do not bounce on aesthetics, ugly enough that you do not get attached to it. For B2C the bar is higher; for B2B you can ship behind a Loom video and a Calendly link and still learn what you need.