Wow, I wasn't sure if that blog post was some sarcasm from some trolls or a real article.
I could quote lots of parts, but here's one of the funniest ones:
>> But intelligent iteration wasn’t possible because of our obese development costs, which left us without any funds to product iterations.
>> We wasted money democratically across developers, patents, e-mail platforms, and a sales pipeline tool
>> Hidden inside our minimum viable product was a separate mobile application to gather data on logic model performance.
The sad part in it is how they blame the process for their failure when they got it all wrong.
However, one thing I've got from this article is how hard it is to create a good mvp. The balance between Quality vs Learning vs Minimum is tricky and highly dependent of your customer. I.e. You create MVPs to learn fast so you can iterate faster.. but since you're still trying to validate your hypothesis, it's hard to decide what is really minimal or valuable.
I guess MVPs is an over-used word.. I prefer prototype: A first or preliminary model of something, esp. a machine, from which other forms are developed or copied. Basically, you use prototypes to iterate really fast and test your assumptions, and then, you build a mvp from what you've learned.
I prefer prototype because it's clear on both side that it's not the real product. It's a temporary phase to test the ideas. But again.. way easier to say than to do. I'm currently in that "prototype vs MVPs" phase and I'm struggling on determining the best next step. The fact that I'm working with health professionals with sensitive and highly important information clearly doesn't help.
That would be amazing if a lean expert reading this would feel generous enough with their time to help me with that "next important step" (phzbox at gmail).
Anyhow, thanks to Casca for sharing his experience.. Learning from failures is more often than not better than trying to copy a successful strategy.