4 ms·
I can tell you absolutely, without question, that when it comes to security and people's funds, there is nothing courageous about a hacked MVP in production. Th
by mrcwinn 13y ago
I can tell you absolutely, without question, that when it comes to security and people's funds, there is nothing courageous about a hacked MVP in production. There's a difference between someone's to-do app one weekend, and this case. If you are handling people's money directly or indirectly, you need to care about that and take it seriously. Or don't ship.
- eli 13y agoWell I would argue that the "M" in MVP would necessitate never losing anyone's money. If I were going to create a trading platform, I'd probably start with one that only accepted Play Money.
- wadetandy 13y agoHe did. It was called Bitcoin
- eli 13y agoCute, but they also traded and held USD.
- wpietri 13y agoPutting on my Lean Startup hat for a sec, I would even say that the M could allow for losing money. If it's early on and your customers are all in the 2 1/2% of innovators, they will put up with a little of that. Certainly if you make them whole, but probably even without. That said, "flawless accounting" would be very high up on my feature list. I think the failure here isn't launching without perfection; it's operating at scale without perfection.
- eldavido 13y agoI've been wondering whether the "M" in "MVP" is for minimum quality, or minimum feature scope. I think minimum feature scope doesn't necessitate poor-quality software, just solutions that don't do everything for everybody. It's much better to ship a small feature set with very high quality, IMO, than a big feature set with low quality.
- spacehome 13y agoMinimum viability?
- wpietri 13y agoGreat thing to wonder about! In the Lean Startup sense, the M is about minimum effort, and the V is about viability with customers. You're basically playing Battleship trying to discover where those two Venn circles overlap. Different aspects of quality map to both those circles. There's build quality, which relates to the sustainability of the code base. There, you have to consider both short- and long-term quality. [1] There's also quality as users perceive it. That varies widely by domain by market, and by how far you are along the adopter curve. My general answer is the same as yours: minimal features with highly sustainable code. But for experiments, I think you can get away with terrible code as long as you a) throw it away quickly, and b) you are on it so even if you have a bad MTBF, your MTTR is really good. I also think that you can tactically discard certain kinds of user-side quality. E.g., if I'm making a product for early-adopter financial traders, I'm not going to worry about quality of visual design, and I might inflict hard-to-learn interfaces on them. But I'd be rigorous about accounting and about UI issues that might lead to mistaken trades. [1] I wrote some about that here: http://agilefocus.com/2009/06/22/the-3-kinds-of-code/ http://agilefocus.com/2009/06/22/the-3-kinds-of-code/
- celticninja 13y agoWell when mtgox started off btc was play money, it was always play money until perhaps 12 months ago when it became serious money. And I base play and serious on the value, at $10 a coin it was still fun, at $100 a coin I had to seriously consider how much I should keep on my phone or any other single place.