- Technical debt /migration costs when mvp matures / more bugs
- High support costs, since MVP often doesn't solve everything lot of manual work needs to be done.
- Often making promises of future features to close sales
- This leads to high emotional costs, continue asking of clients when promises are fullfilled.
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.
Also very hard to get exact feature set right.
These things are solvable, but I don't think they are always properly adressed by the advocates of the approach.
To me, an MVP is about reducing functional and non-functional scope: which requirements (functional and non-functional) can I take away from my solution, while still having built something people want?
Maybe your MVP doesn't require full HIPAA compliance, or nine nines availability, or the ability to manage users via a front-end, or...
Typically people do want software that's intuitive to use and doesn't crash, so you don't want to ignore those requirements, but most of the others are for grabs.
This implies your MVP is tightly coupled to your ideal customer profile, your GTM strategy etc:
Which audience will want to pay for this specific piece of functionality, despite all of its flaws (why opt for a non-established supplier? What's the out of of the ordinary part of the service that makes me willing to buy this? ...)
An MVP is built to validate a business hypothesis, and you should try to do the minimum to do this. Technical debt is unavoidable, as you usually don't know upfront what all the requirements will be within 5 years from now. Trying to architect upfront for this will usually fail, as most of your assumptions will be wrong anyway.
My #1 tip is to try to build a composable system where you assume the majority of the components will have to be replaced multiple times over a cycle of n years, so make them easy to throw away and start over...
> 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.
- Technical debt /migration costs when mvp matures / more bugs - High support costs, since MVP often doesn't solve everything lot of manual work needs to be done. - Often making promises of future features to close sales - This leads to high emotional costs, continue asking of clients when promises are fullfilled.
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.
Also very hard to get exact feature set right.
These things are solvable, but I don't think they are always properly adressed by the advocates of the approach.