Every now and again you get to see glimpses of how people think in the way they formulate and frame up a discussion, that tells you they obviously adopted language from someone who did not think as they did. Such is the case with the term "Minimal Viable Product".
The term is remarkably similar to euphemisms for unborn babies [er, "fetuses"]. It invokes a metaphor of a gestating product, which might be aborted should it fail to exhibit a minimal feature set. I personally find the term to be in poor taste, and more than slightly stupid in assuming requirements form a static set over which you can assess a minimum.
Nevertheless, it is commonly used in Agile/Lean circles. Transitively and reflexively, one might ask the question of why there is then no "Minimal Viable Specification". It is not a foregone conclusion that a system must be over-specified before building can proceed, but neither is it an obvious truism that a stream-of-consciousness approach to coding gives the best value proposition to the client.
A minimum viable product implies that a set of coherent requirements could have been envisioned at some scale, while some who use the term often advocate explicitly against just such specifications. I understand why: as programmers, we get paid to code, not to specify. Well, sort of. Maybe, maybe not.
I've also heard it said that the code _is_ the specification. Or that the tests in TDD/BDD are the specifications. While these arguments have merit from the programmer's perspective, they are arcane and continue to sound weak from a customer's viewpoint -- at least as far as the tests or code don't rise to the level of abstraction that the customer's brain is at.
Einstein is widely credited with saying that things should be as simple as possible but no simpler; yet it was Newton hundreds of years before who was able to practically refract white light and recompose them again... thereby demonstrating that the most apparently simple of colors is also a composite and the most complex colors of all. The trouble with scientists is that sooner or later a few of them will make inconvenient things like facts get in the way of conveniently wrong abstractions. The trouble with reality is that it doesn't respect Agile ad-hoc abstractions and just keeps on behaving the same whether you believe in it or not.
So I posit that there is some minimal specification that really does need, in effect, to be professionally drafted and validated, else someone is taking too much risk, paying too much money, and/or just getting suckered into a co-dependent relationship with coders. Not that I pretend to know what that minimum is, I am just suggesting that it must exist, and the tangible artifacts representing it should consist of more than just a few notes taken while schmoozing with a client.