The reality of building things is there is no such thing as a trivial app. There are edge cases, features you didn't think about, hidden costs, difficulty marketing, personal problems, etc. Even if your app does one incredibly simple thing, there are probably hundreds or thousands of hours of development between that initial hacked together demo you did in a few hours and a profitable product, even a very small one.
Everybody wants a shortcut, everybody wants a free lunch. There are a few cases where people have got lucky and hit the startup lottery so to speak, but for the other 99%, it's a lot of work to build something good and to make money doing it, especially something small.
If you think that you're different/special and these rules don't apply to you, then you're probably in the 80% of people who believe they have above average intelligence/skill/beauty/whatever.
MVP does not mean easy.
If you get people saying - hey cool! - and then not returning, is your product simply unfinished/unusable, or is it a neat idea that's just not practical?
Jon Radoff explains it better than me: http://radoff.com/blog/2010/05/04/minimum-viable-product-ran...
... and rightfully so. Unlike "minimum" or "product", people's interpretation of "viable" is so subjective, it will end up being influenced by the founders' experience, personality and so forth.
prints and tapes to wall
I'm writing software to automate a painfully manual, error-prone process. Suggesting that I continue to do it manually, only charge people money for it, isn't viable.
Which gets to the author's point.
Everything you _do_ deliver needs to be polished and robust, or people are going to write you off.
It's really hard to pare down the feature set and figure out what features are really needed.
On the other hand, it's really easy to throw in a bunch of features, but have them all be half-broken crap with a poor UI.
The hard one is the one you actually need to do to be successful. You do need to pare down features to an MVP, because otherwise you're never going to finish, or are going to deliver crap. You need to pare down to the MVP, so that you have the resources to make every feature that remains high quality.
Or deliver something beautiful to your team that no one actually wants, or will purchase
I've never seen anyone advocate that an MVP can/should be "broken". Only that it should have very few features ("minimum"). That it should help solve a core problem better than the current way of doing things.
This entire post is conflating "doesn't work" with "doesn't look pretty to me". No one is advocating an MVP shouldn't do what it claims. BUT an MVP should not have tons of visual polish. That is what Bootstrap is for, sorry.
If you show me an MVP that saves me 1 hour a day but looks like Craigslist, I will still open my wallet immediately.
Craigslist may look like 1995 but it still does a better job than any direct competitor out there.
Here's a great article on the subject: http://blog.bizelo.com/blog/2010/09/27/minimum-viable-produc...
(I just submitted the link on HN a few minutes ago here: https://news.ycombinator.com/item?id=6756166 if you want to discuss that blog post)
But I have lost count over the number of times I or people I know have hesitated with releasing something out of perfectionism. This is fear--fear that you will look bad in the eyes of others because you made something that is of low quality. And if I was having a discussion with cofounders over whether to get something out and one person made the argument that we shouldn't because it's a MVPOS, that would be a huge indicator that said person was stalling out of perfectionism, not a rationale about whether we will be able to validate our hypothesis or not.
I find it usually strikes a good balance between shipping early and perfectionism. Perfectionism is a actually a great thing in doses since its proves you care about quality to your users. But shipping early allows you to course correct sooner. Both have their merits and should be balanced.
You can have the best automated workflow that scales perfectly, but it will not beat the manual workaround if you have 5 users. You get the users, you build, automate and optimize. For a lot of things the initial users won't be able to tell the difference so no UX impact.
The entire point of an MVP is validation. In my opinion validation is attained when someone (i.e. a user/customer) has enough energy to respond or give feedback. Customer development comes next (feedback, measure, iterate, etc).
I've found that people have a hard time separating the two in interviews.
You want the MVP to prove (or disprove) your #1 experiment toward your sustainable business model.
You're validating your understanding of your customers, market, channels, partners, and the like.
This means the MVP is not necessarily what you envision for your product. Your first MVP could be a simple splash sign up page, or a short-term concierge service, or quick-and-dirty spreadsheet macros instead of a fancy iOS app.
The goal is to get feedback from real customers, and prove that your ideas work-- or get early advice so you know to adjust your ideas. The cycle is rapid: build, measure, learn.
Steve Blank, Eric Ries, and many others write about these ideas very well in the Startup Owner's Manual.
The very point of the M.V.P. is that you are setting out to create an "internal tool your company uses that took off unexpectedly".
You can polish the one that won't take off all you want, but the one you should be building will take off regardless. When it does, you polish it.
If more people built "tools" we'd have a lot better world. Anyone can pay for a tool. It does something. So make one that works internally and solves your need, then let other people see it and let them solve theirs. That beats the hell out of polishing something that doesn't meet a need.
The danger is shipping a non-viable product, get feedback that it's not needed because in it's MVP state doesn't solve a need, and pivot based on bad data, because you didn't deliver the thing that you believe people want.
For some, an MVP seems to simply be a tool used to verify a concept in a marketplace. Some MVPs in this category are landing pages, mock-ups, or a shoddy app that you can hold up to someone and say "This isn't done by any stretch, but does this solve your problem?". For others, as may or may not be the case of what the author is imagining, the MVP represents the minimum useful product that you can deliver to the end-user to create value for them in exchange for money. The hair-splitting is then around the value exchange and the expectations between the creator and the end-user. And, there are probably still more permutations of the concept that I haven't even begun to imagine yet.
However, I would say that using this MVP concept is more about learning what works while setting expectations with the end-users than it is about delivering the ugliest piece of non-functioning tripe you can fool the customer into paying for.
"Don’t be one of those startups that delivers broken features with the excuse, "It's just the M.V.P., we'll fix it later."
I agree, to many projects released now are in beta (or even alpha) stage.
If it's a twist on something more common like say an email client then I probably won't even bother trying it if it's ugly , slow, clunky or crash prone even if you have added features that might be useful.
Excellent blog posts about this issue: "Why only fools write code first" http://blog.reemer.com/why-only-fools-write-code-first
In the hands of non technical management MVP inevitably means MVPOS. And actually, by "lean' methodology thats correct. Lean says "ship it as soon as you can market test it", quality is not required.
Which is why I believe the entire lean nonsenses is due to die in the near future.
