MVP

An MVP — a minimum viable product — is the smallest thing you can put in front of real users that produces a real answer to the question you are actually unsure about. The definition people remember is "the smallest version of the product". The definition that is useful is "the smallest experiment that can change your mind".

That difference decides what you build. If your open question is whether anyone will pay, a landing page and a payment link answer it in a week. If your open question is whether the thing can be delivered at all, a landing page answers nothing and you need working software. Teams routinely build the second when their real doubt is the first, then spend four months learning something they could have learned in five days.

The word carrying the most weight is "viable", and it does not mean unfinished. A version that is genuinely too rough to use produces a false negative: people do not reject the idea, they reject the experience, and you cannot tell the two apart afterwards. Narrow the scope, not the quality. One workflow that works properly beats six that half-work.

A concrete case: a scheduling tool for clinics could ship as a full booking system in five months, or as one form plus a shared calendar in three weeks, run manually behind the scenes for the first ten customers. The second version answers "will clinics change how they book?" — which is the question everything else depends on.