It can be hard to draw the line between which features need to be in your MVP and which can be put off for future releases. Let's look at a few ways you can determine which ones should make it in.
First, think about the problem your product is solving for your users. For each feature, ask yourself: is this feature necessary for the product to solve the user's problem? Only include features that are needed for solving that problem and bringing value to the user.
If you're entering a competitive market, you should include the features you need to set yourself apart. If your bet is that you can grab market share with a few differentiated features, your MVP needs to validate the value of those features with real users.
Aiming for feature parity with competitors in your MVP is not the best use of your time, because if your differentiating feature(s) aren't a success you won't have anything else to compete on but price.
Snapchat are a great example. Their MVP didn't include features such as captions or filters which competing products like Instagram had. They just had one feature: send disappearing photos. Once they proved users loved it, then they looked at other features they could add to delight users.
Yes, if you've done your MVP right you will probably have some unimpressed early users. You may even lose some. So what? Either:
A) your MVP validates your assumptions. In which case you can make improvements and achieve better retention with your next cohort of users.
B) your MVP isn't solving the problem for users. You pivot or scrap the idea and move on to something else.
You'll either fast-track to a real opportunity you can monetise, or you avoid months of wasted effort. Win-win.
"If you're not embarrassed by the first version of your product, you've launched too late." - Reid Hoffman, Co-Founder of LinkedIn
If you're spending a lot of time debating whether or not a particular feature should be in your MVP, it probably doesn't need to be in there.
Your MVP should have the smallest useful feature set it needs to deliver value to your customers and differentiate it from competitors. Remember, most of your learning will happen once you get your MVP into the hands of real users. Limit the feature set so you can release sooner and get straight to that learning!
There is an alternative approach. Don't build anything, talk to potential users about their problems...
I don't think of that so much as an alternative approach, more as something that needs to happen earlier in the process (before you even decide to build an MVP). But yes an important point for sure!