The emphasis belongs on viable, not minimum. An MVP is not a broken product or a landing page with a waiting list — it is the least you can build that lets a real person get a real result and decide whether to pay. Everything not required for that result is deferred. The output of an MVP is not revenue; it is evidence, and the evidence is only trustworthy if someone genuinely used the thing.
For founders the discipline is protective. Building the full vision before contact with customers means spending your entire runway on assumptions, and the features people actually ask for are almost never the ones you agonised over. An MVP is also the cheapest way to discover that the problem is real but your solution is not — an answer worth far more at week six than at month nine. Write down the single assumption you are testing before you build, or you will end up shipping a small version of everything instead of a complete version of one thing.
A concrete example: you want to build scheduling software for dog groomers. The full vision has payments, reminders, staff rotas and reporting. The MVP is a booking page and an SMS confirmation, used by three real salons for a month. If they keep using it and ask about payments, the assumption held. If they use it twice and go back to a paper diary, you have learned in four weeks what a full build would have taught you in nine months.