4 ms·

> Or, to put it a bit more optimistically - usable now is better than perfect later. This is the same principle of Minimum Viable Product. In MVP you launch th

> Or, to put it a bit more optimistically - usable now is better than perfect later. This is the same principle of Minimum Viable Product. In MVP you launch the first version of your product with sufficient features, but not all, to early adopters so that you can get feedback from them. MVP and the "Build Measure Learn" feedback loop, gives you important tools to leverage your product.

bunderbunder 8y ago
Yes, absolutely. The language around MVPs tends to be couched in terms that pretty directly implies designing a product for external customers, though, so it tends to be harder to internalize for people who are doing in-house work, and even people who are somewhat removed from the product design process, such as many junior developers. What I've seen in is that it's common for people who are eager to impress their clients or teammates to want to say "yes" to everything. So, even if they like the idea of building MVPs in principle, in practice, their MVPs end up being pretty maximal. Which is why I think there's value in framing the principle in terms of human-human relationships, and not just in terms of stuff like finding product-market fit. It's a more personal, relatable way of thinking about it. The magic insight for me was when I finally realized that I could give people less than what they asked for, and they'd actually be happier than if I tried to give them everything they wanted.
- bitfhacker 8y ago
  > The magic insight for me was when I finally realized that I could give people less than what they asked for, and they'd actually be happier than if I tried to give them everything they wanted. I consider that a form of art/skill that we learn through multiple experiences (and errors too). I work closely with developers and I observed that the majority try to implement always the perfect solution that normally comes with a high cost and time to develop. Clients normally prefer a solution that is quicker to implement but that responds to 80% of what he wants.

bunderbunder 8y ago

Yes, absolutely. The language around MVPs tends to be couched in terms that pretty directly implies designing a product for external customers, though, so it tends to be harder to internalize for people who are doing in-house work, and even people who are somewhat removed from the product design process, such as many junior developers. What I've seen in is that it's common for people who are eager to impress their clients or teammates to want to say "yes" to everything. So, even if they like the idea of building MVPs in principle, in practice, their MVPs end up being pretty maximal. Which is why I think there's value in framing the principle in terms of human-human relationships, and not just in terms of stuff like finding product-market fit. It's a more personal, relatable way of thinking about it. The magic insight for me was when I finally realized that I could give people less than what they asked for, and they'd actually be happier than if I tried to give them everything they wanted.

bitfhacker 8y ago
> The magic insight for me was when I finally realized that I could give people less than what they asked for, and they'd actually be happier than if I tried to give them everything they wanted. I consider that a form of art/skill that we learn through multiple experiences (and errors too). I work closely with developers and I observed that the majority try to implement always the perfect solution that normally comes with a high cost and time to develop. Clients normally prefer a solution that is quicker to implement but that responds to 80% of what he wants.