I liked that this included the question "What is the minimum viable product?". It reminds me of a game design article I read a long time ago, which mentioned that the best way to figure out if you have a game that will be fun when it's finished is to "start with the stupidest thing that could possibly work." In other words, starting small and focusing on the core mechanic, and building on that only once you've "found the fun," is a reliable way to produce fun games. This is in stark contrast to the way many projects are run (game or otherwise), in which thousands of features are planned out right from the start and presumably developed in parallel, like a hundred people simultaneously trying to stuff themselves through a single doorway.
I tried to get this ideology through to my boss at my last job, I said "Which features are the most important and must be done before we can release?" His reply was "All of them, somebody out there needs each of those features!" It was very frustrating not being able to make him see the benefit of less.
Perhaps a better question is, "Which features are going to pay for themselves, both for the the initial development and the long-term maintenance?"
When working on JotBot at Happy Camper we had numerous discussion about features. In retrospect there are things that were added that may have been worth the initial effort but because of bugs or quirks are now more of a drain.
There was little argument that there were people who could use the features, but the potential revenue gain did not match the cost of adding + the cost of maintaining.
There's also the opportunity cost of delaying release while adding things. If you want a manager to drop features you need to spell out the financial cost.
(Also, if someone tells you that someone needs feature X, ask them how exactly do they know that? And ask how they determined that the desires of one person (or N people) justify the cost.)
