MVP : A Guide
For an artist, a drawing usually starts with a rough sketch; an outline with minimal details showing the general idea of what the piece of art will eventually be; Maybe a rhino, or a countryside landscape. The rough sketch will very unlikely have the hair, hooves and eyes of the rhino or the leaves and water droplets of a scenery, but it forms the fundamental 'foundation' for the entire piece of art.
In the world of startups, an MVP can be thought of in the same way as an artist's rough sketch. It is the very basic wireframe, a stripped down version of a founder's vision, with only the core functionalities. As a proof-of-concept, it's main function is to test a hypothesis; will it solve a particular problem in a radically more efficient way as compared to existing alternatives?
One reason why MVPs need to be lean is to minimise engineering costs of building a complex product that might not satisfy the users the way you envisioned in the first place, or which might turn out to be unneeded by anyone - a white elephant. A lean MVP is an easy way to get the product to early customers as quickly as possible for them to use and give you valuable feedback. It's an accelerated learning opportunity.
When Airbnb started, their MVP consisted of a very basic website, 3 airbeds & Breakfast. They were targetting attendees of a conference, and wanted to offer an alternative accomodation to the hotels. It was far from what Airbnb is today. The website didn't have a map or multiple dates selection. They only needed to prove that total strangers were were willing to rent what they were offering - which they did. Now its a 87B dollar company.
After having an idea and doing the necessary preliminary research, it's prudent to get something going, quickly. Launching a not-so-elegant product as soon as possible, and then talking to customers and iterating, is much better than waiting to build the “perfect” product with all the future customer categories.
You do not have to account for every use case in an MVP. Focus on a subset of users with only their highest order pain points which form the core functionality. This way, you ensure that you do a few things great instead of doing a wide set of things and ending up falling short.
The increase in popularity and function of no-code and low-code means that it's much more easier to get an MVP going, even for founders without a technical skill-set. Most basic softwares can be actualized with a myriad of no-code tools, with little or no coding skills. You could, for instance, make a graphical user interface for a web-app using Webflow or Bubble, a configurable database using Airtable, use Typeform or Google Forms as user input forms and so on.
You should not be too attached to the technology; be attached to the problem. That way, you'll be more open to changing the solution to meet customers' needs, as opposed to trying to change the problem to satisfy your product. MVPs typically go through several iterations before they may be considered as efficiently solving the intended customer problems. Talk to your users to see if it serves their needs, and then take their feedback and iterate. An iteration may be as simple as changing a few features but they may also involve an overhaul of the entire business model altogether.
Lean, quick MVPs of course do not work for all Industries. Hard tech for instance requires finer MVPs. Also Biotech - for example a bionic eye can't be ready for human testing in a week.