Back to Basics
Frank Robinson was the first person to coin the phrase ‘Minimum Viable Product’ (MVP) back in 2001. It came out of the synchronous customer and product development (‘SyncDev’) movement and was rapidly adopted and popularised by Steve Blank and Eric Ries. 
You can build a library out of the books written about MVP, criticism of MVP and proposed new models for MVP. However, at its heart the concept is simple: 
A minimum viable product is the lowest cost / fastest way to engage with customers, to learn and to move innovation forward.
In no way does that definition mention software development. Some of the most successful MVP were delivered without a single line of code (Groupon and Dropbox spring to mind). Yet somehow, with the advent of no-code, the term MVP has been bent to mean ‘a cheap and fast version of my application’ and that’s bad…
Bad Practice
Let’s try a thought experiment: I’ll pay for the first version of your application for you. It will be completely free, but I wont promise to pay for any more iterations. Should you try to get the biggest scope possible built in that first development cycle?The answer, of course, is no. Launching an overweight minimum viable product is like pouring concrete in your speedos and going swimming. It does a number of things that make you sink: 
It overcomplicates messaging to potential customers making it harder to drive growth.It wastes development time on features that wont be used, reducing the quality of those that will.It muddies any experimental data you collect making it harder to learn and move forward. 
Right now most no-code founders are making it through one iteration of their product and giving up. By definition that’s not an MVP. They learned nothing, changed nothing and failed to move forward. In every sense, they are failures, but they need not be. The average no-code application budget is $9,500 and that’s more than enough for a number of MVP iterations. By iterating through multiple proper minimum viable products we learn and we create innovation metrics: data that can be used to attract investment and to grow a business.  
We know, from painful experience, that it’s hard to cut the scope of an MVP down. The correct method is as follows: 
Define one key assumption about your idea that you need to testWork out what data might prove your assumption to be correctDesign a test that will allow you to capture that data
The scope of your test is your minimum viable product. Until you have the results of your test, don’t build anything else. The learning gathered in each iteration should help you to design your next test. Slowly you will be able to build a more and more complete product as assumptions become facts and risk diminishes. 

The Four Horsemen of a Bad MVP
There are some features that we can immediately identify as out of scope for a minimum viable product. They all have the same characteristics: 
They can be easily replaced with manual processes or existing systemsThey are not mentioned in your value propositionThey undermine the efficacy of testing though needless complication
So what are they?
Messaging and Social Tools
Messaging and social tools both fall into the category of (1) requiring a volume of customers to make them worthwhile; and (2) being amply provided for by existing tools. Inevitably the people you ask to use your in app messages will simply use email instead. Getting someone to use your product is a high hurdle, why add another and try to change the way they communicate?
As for social tools, there is nothing sadder than an empty forum or social wall. Far from driving people back to your application to share thoughts and experiences the MVP social space is likely to look a little like a party that no-one came to, and that can only look bad. If you want social, bring the party to your users: Go to Facebook, Reddit, Linkedin, Discourse or one of the many other platforms that might be home to people that might like what you do.
Basically, unless your startup is specifically building new social or messaging tools cut this weight from your scope and use existing communication channels instead.
Multiple Users Types
I cut two founders dead this week after they told me that they wanted to build partner tools into their MVP. Why? Well they told me that “when they had tens of thousands of users partners would want access to them”. Oh boy. 
An MVP is a targeted test. A scientific experiment. The more variables I add into the experiment the less reliable the data it produces will be. When we define our MVP test we need to think in this way. A good test will be focussed on seeing what a single, clearly defined, user does. 
For example: a startup has a hypothesis that students will pay for access to online lessons. They build an MVP with a scope that tests different sales messages to see which attracts the most purchases from their target customers. They don’t need to build a video conferencing platform for teachers (they use zoom and get some friends to cover lessons). They don’t need teacher tools at all. Their test provides quantitative results data that helps them to understand what students want and qualitative data from the teachers and students experiences of lessons and the manual operational process required to administer bookings, collecting and distributing money and handling absences. That’s a good test.
If your MVP scope has multiple users ask yourself why and what you can do to change that. 
Operational Efficiency
If you are trying to integrate your MVP with your accounting software you’ve lost the plot completely. 
As a startup grows there are numerous operational processes that become so onerous to handle manually that it’s worth building (or buying) something to automate the process. The same is true for managing risk. These are not things to think about in the first version of your software. Some good examples: 
Raising invoices? Use word and email. Sending reports? Use excel and email. Ordering from suppliers? Do it manually yourself. Mailing list? Mailchimp is right there for you. Want some way to handle comms with clients? Slack, Miro, Trello, Email, WhatsApp? Want to survey your customers? TypeForm, Google Forms? 
The time to build an operational process into your application is when you find someone in your team is spending a day a week on handling the problem manually. At that point the investment in development becomes worthwhile. 
Complex Pricing and Bonus Schemes
Ah the curse of corporate founders! If your MVP comes with the requirement for Gold, Silver and Bronze pricing tiers (plus some add on packages) you’re in the weeds. 
When you first meet customers the barrier to getting them to use your product is enormous. Simplicity is key. While there is merit in testing different pricing to see what’s most attractive to users this should be done on an AB testing basis. Complex pricing: 
Baffles the customer and reduces salesAdds unnecessary variables to test dataAdds complexity and cost to MVP development
Once you start to grow you will learn more about your customers. This will help you to deign effective pricing strategies. As there is no possible way to know this at idea stage keep pricing in your MVP simple. 

MVP Rules
So to recap, how should you scope a minimum viable product? 
Step One: Write a list of assumptions that you need to prove to work out if your startup is going to work or not. 
Step Two: Take one assumption and ask yourself: “What data do I need to prove to myself that this assumption is true?” 
Step Three: Design a test that collects that data. This is your MVP scope. 
Step Four: Review your scope. Write out each feature and ask yourself: 
Does this feature form a part of my value proposition or is it a ‘nice to have'?Can I do this manually or with an existing product or service? Does delivering this feature complicate my test and make my data less reliable?
Remember your goal with an MVP is to produce data that you can use to prove your assumption and continue to collect in future as a measure of progress. If testing and collecting data is nowhere in your scope… go back to square one.