> This article is more about "how to find out what an MVP might be".
This sounds a bit tautological. An MVP is the smallest possible experiment to test your assumptions. To find out what that experiment should be, you have to do an experiment to test assumptions...
Also, one of the key ideas in the article is this is not something you do once to build a single MVP. It's a process you use over and over again to develop every aspect of your business, including the product, marketing strategy, software architecture, etc. For example, to build a large software system, you don't write 100,000 lines of code, then hit compile, and hope it works. Instead, you do it incrementally. Write a few lines of code, test them, make sure they work; write a few more lines of code, test them, make sure they work, and so on. Or to quote John Gall, "A complex system that works is invariably found to have evolved from a simple system that worked."
> Adding an extra feature nobody needs means you've not built a minimum product.
This reminds me of the No true Scotsman fallacy [1].
"No MVP should have unnecessary features."
"But that successful company's MVP had all sorts of unnecessary features."
"Yes, but no true MVP should have unnecessary features."
This sort of critique isn't wrong, but it's not useful. How do you figure out which features are necessary and which ones aren't? The best way I've found to do that is to pick your riskiest assumption and to test it. And to do that over and over again, incrementally building up your product as you go. If you don't like the term MVP for that, I suppose that's fair, but then please suggest a better term to replace it.