I hate these discussions. Everybody argues over semantics or terminology, but this is what it boils down to at the end of the day:
Your first release looks very different than releases down the road a couple years
Your first release needs to effectively, and delightfully, solve the problem or provide the value that the product depends on
Your first release is not the end point, it's the starting point
The longer you build without validating solutions with end users, the higher your risk levels are. Your risk tolerance may be very different than mine, and that's ok.
I personally think that the lean startup method is good but only if you have spent a lot of time selecting the right market before you start your MVP.
There are great books like "Start small, stay small" by @robwalling and a new book called "Choose" by Ryan Levesque that focus on the critical things you need to do around market selection before even considering to start with the lean startup method.
For me this is quite simple. If you're in an established market with competitors, building an MVP it's far from being enough, you need to be much better, otherwise you might get away with an MVP.
I hate these discussions. Everybody argues over semantics or terminology, but this is what it boils down to at the end of the day:
I personally think that the lean startup method is good but only if you have spent a lot of time selecting the right market before you start your MVP.
There are great books like "Start small, stay small" by @robwalling and a new book called "Choose" by Ryan Levesque that focus on the critical things you need to do around market selection before even considering to start with the lean startup method.
For me this is quite simple. If you're in an established market with competitors, building an MVP it's far from being enough, you need to be much better, otherwise you might get away with an MVP.