Excluding your rant (which is totally on point, BTW) Every feature you drop is time saved. You can choose to invest that time into improving your remaining fea

Excluding your rant (which is totally on point, BTW) Every feature you drop is time saved. You can choose to invest that time into improving your remaining features; or you can simply save it for later and ship your release sooner. Product release management is a balancing game. Your goal as a product owner is to determine the ideal balance between: 1) Shipping as soon as possible i.e. the "velocity" of the feedback loops. 2) Shipping something different enough than what you shipped before that there is valuable feedback to be gained from shipping ie. the "size" of the loop. In one extreme, you wait until the product is "1.0" and ship one time and you have one huuuuuuuuuge feedback loop with a ton to process. In another extreme, you ship every single (nano!) second of the day and you have a billion tiny feedback loops, most of which have no delta at all. What most people have compromised on is some kind of fixed duration loop (aka "the sprint") that the resulting loop is, Goldilocks style, not too big or not too small, but juuust right to address within the fixed duration. By fixing the duration, we now have a clear focus from a product development side: generate enough delta between what was shipped last time and shipped this time to ensure the size of the feedback loop is what we need to gain enough information on what's needed for the next shipping cycle. And the hypothesis is that if we could compare the product built using the 3 choices - extreme size, extreme velocity, Goldilocks - over some long enough period of time, that the Goldilocks product would be the most valuable. MVPs themselves are tricky because they are the "first release" so they don't have a delta nor feedback. They can technically be shipped any time! But it's still important to choose a fixed duration for your MVP release, for three reasons: 1) It falls in line with the general principles of "fail fast", "ready, fire, aim", "you are not the customer", "avoid analysis paralysis", "perfect is the enemy of good", etc. You will always struggle to get a "polish"/feature-based MVP out the door - there's one more thing to do, you're more critical than your customers ... One is way more "negotiable" (in a negative sense) than the other. 2) By choosing a specific date you're going to ship on no matter what features are there, you've already guaranteed an M and a P. All that's left to negotiate is the V. So now your point about the tradeoff between number of features vs. the polish of those features is valid, which leads to .. 3) There is no right answer to #2. If I saw a lot of polish on someone's MVP I might ask what features they're missing entirely. If I saw a lot of half-baked features I might ask why they didn't drop features X and Y to add polish to "core" feature Z. Amazingly, the answers to those questions only matter if you're a user of the product! So ship fast and get answers.