For me, the viable part has always referred to required aspects of the product. For example, a forgot password feature might require two components, the webpag

For me, the viable part has always referred to required aspects of the product. For example, a forgot password feature might require two components, the webpage where users indicate that they've forgotten their password and the backend that sends them an email with a reset link. Without the V in MVP, you could implement just the webpage side of it and push it out to start learning about user behavior. But without the backend, users will be frustrated and the feature won't work. However sometimes a feature that has multiple components can be rolled out sequentially to increase the time that your users are using the feature and you're learning how to improve it. An example might be Amazon's product reviews. An MVP mindset could allow you to have a phase 1 that is simply collecting reviews without displaying them anywhere. The feature may be more compelling when all aspects implemented, but it's at least somewhat functional in a partially implemented state. And that's where the judgment comes in...when developing a product, you have to distill the eventual vision of what you want to build into the minimum thing that doesn't have holes that either make it unusable or compromise your ability to learn from the way that user's interact with your product.