4 ms·

One big problem is that you often don't know yet what you actually need, you only find that out when your software is in front of real users. So the later versi

One big problem is that you often don't know yet what you actually need, you only find that out when your software is in front of real users. So the later versions might be substantially different than your MVP. Building a very robust first version might be entirely useless if you have to throw away most of it after discovering it doesn't actually solve the user's needs.

haswell 2y ago
The issue is that what often happens next is the thing that got cobbled together as a customer POC ends up in production. Most hardware goes through extensive validation and revision before tooling to manufacture and ship at scale. The software space hasn’t always (often has not) found the correct balance between low cost early iterations and a properly hardened customer-ready product. The temptation is strong to just call it ready because it’s always possible to patch it later. While I agree that finding this balance is a challenge, I don’t think that lowers the criticality of productionizing the code or the risk of using these early stage products that haven’t “grown up”.
rekabis 2y ago
> So the later versions might be substantially different than your MVP. Building a very robust first version might be entirely useless if you have to throw away most of it after discovering it doesn't actually solve the user's needs. IME, the core foundation of the product should be built such that no more than ≈20% or so of the MVP is ejectable in this manner. Not that it can’t, but more importantly: that it doesn’t have to. An MVP should be so basic that the majority of it would be foundational to anything being built, and so would remain in part or in whole no matter what redirection is taken. This is not always possible, but for most ideas there is a core element that you can start with, even if usefulness won’t really be there without a lot more functionality. > you often don't know yet what you actually need, you only find that out when your software is in front of real users. Which is why an MVP should only ever be the absolute minimum viable product - so that as soon as it ends up in front of users, you can lurk in whatever user forum you stand up and advertise for the product (subreddit, etc.) and listen to what the users are saying. Some of them may inadvertently drop ideas that can make or break your product, and it’ll be things you never thought of. Being able to pivot on a dime is why an MVP is so vital to begin with.

haswell 2y ago

The issue is that what often happens next is the thing that got cobbled together as a customer POC ends up in production. Most hardware goes through extensive validation and revision before tooling to manufacture and ship at scale. The software space hasn’t always (often has not) found the correct balance between low cost early iterations and a properly hardened customer-ready product. The temptation is strong to just call it ready because it’s always possible to patch it later. While I agree that finding this balance is a challenge, I don’t think that lowers the criticality of productionizing the code or the risk of using these early stage products that haven’t “grown up”.

rekabis 2y ago

> So the later versions might be substantially different than your MVP. Building a very robust first version might be entirely useless if you have to throw away most of it after discovering it doesn't actually solve the user's needs. IME, the core foundation of the product should be built such that no more than ≈20% or so of the MVP is ejectable in this manner. Not that it can’t, but more importantly: that it doesn’t have to. An MVP should be so basic that the majority of it would be foundational to anything being built, and so would remain in part or in whole no matter what redirection is taken. This is not always possible, but for most ideas there is a core element that you can start with, even if usefulness won’t really be there without a lot more functionality. > you often don't know yet what you actually need, you only find that out when your software is in front of real users. Which is why an MVP should only ever be the absolute minimum viable product - so that as soon as it ends up in front of users, you can lurk in whatever user forum you stand up and advertise for the product (subreddit, etc.) and listen to what the users are saying. Some of them may inadvertently drop ideas that can make or break your product, and it’ll be things you never thought of. Being able to pivot on a dime is why an MVP is so vital to begin with.