> Now of course you can create a very stable solid product, properly tested with perfect data structure. But that's highely unlikely to happen with an MVP, due to the nature of the approach.
I think this is more to do with "move fast and break things" than MVP specifically.
> Now of course you can create a very stable solid product, properly tested with perfect data structure. But that's highely unlikely to happen with an MVP, due to the nature of the approach.
The interpretation I've always had is that an MVP is the smallest subset of useful features to take the product to market. How you reach that subset is entirely up to you, and in my opinion, you should take time and do a good job, not rush.
In my experience, if you solve only the problems you have, you'll be fine as far as long term maintenance goes. Hacks and corner cutting are inevitable but you'll be doing a lot less of it if you can stave off the desire to invent new abstractions.
an MVP is the smallest subset of useful features to take the product to market in order to prove or disprove its viability
and the reason you want to keep it to the minimum is to minimize the time and money invested in it so that you can throw it away if it doesn’t work and then try a different product. You’ll probably have to do this several times before succeeding so your budget for each should be about 1/10th of your available time and money.
Yeah but those ideas don't work well together, the whole idea of MVP is to move fast, since you don't know if it's worth investing time in those features yet. So it also doesn't make sense to fully develop it to maturity in that line of thought. So practically that's what happens.
I think this is more to do with "move fast and break things" than MVP specifically.
> Now of course you can create a very stable solid product, properly tested with perfect data structure. But that's highely unlikely to happen with an MVP, due to the nature of the approach.
The interpretation I've always had is that an MVP is the smallest subset of useful features to take the product to market. How you reach that subset is entirely up to you, and in my opinion, you should take time and do a good job, not rush.
In my experience, if you solve only the problems you have, you'll be fine as far as long term maintenance goes. Hacks and corner cutting are inevitable but you'll be doing a lot less of it if you can stave off the desire to invent new abstractions.