M.V.P., not M.V.P.O.S.

75 点作者 robertnealan超过 11 年前

20 条评论

MVP is also popular because it has an element of laziness and "get rich quick" attached to it subconsciously. It sounds easy to just build the smallest possible thing you can charge money for, then just throwing out a landing page, submitting to Show HN, and you're an instant millionaire right?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.

评论 #6755619 未加载

jrochkind1超过 11 年前

MVP should always be about minimizing the number of features or things it does -- but never about delivering features that are broken or buggy.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.

评论 #6756462 未加载

jph超过 11 年前

Think of MVP as your current Most Valuable Player.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.

eggbrain超过 11 年前

I feel like many people miss out on the V part of MVP -- the minimum _viable_ product that can be released.Jon Radoff explains it better than me: <a href="http://radoff.com/blog/2010/05/04/minimum-viable-product-rant/" rel="nofollow">http://radoff.com/blog/2010/05/04/minimum-viable-product-ran...</a>

评论 #6755479 未加载

评论 #6755470 未加载

callmeed超过 11 年前

I smell a little bit of design snobbery along with a false premise or two.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.

评论 #6755620 未加载

logicallee超过 11 年前

>Short of some weekend hackathon you did with your buddies or an internal tool your company uses that took off unexpectedly, every feature of any product you intend to sell or monetize should strive to be as polished as reasonably possible and function just as your end-user expects it should.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.

rexreed超过 11 年前

I think the OP might be missing the point of what an MVP is for. It's about trying to achieve the maximal amount of learning and validation with the smallest amount of work. It's an efficiency equation, not one about perfecting a small bit of functionality. As such, an MVP could be a presentation, a landing page, a video... those are all valid MVPs.Here's a great article on the subject: <a href="http://blog.bizelo.com/blog/2010/09/27/minimum-viable-product-or-minimum-valuable-product/" rel="nofollow">http://blog.bizelo.com/blog/2010/09/27/minimum-viable-produc...</a>(I just submitted the link on HN a few minutes ago here: <a href="https://news.ycombinator.com/item?id=6756166" rel="nofollow">https://news.ycombinator.com/item?id=6756166</a> if you want to discuss that blog post)

评论 #6756225 未加载

kristiandupont超过 11 年前

Well right, if the features that you need to validate aren't working, you won't be able to validate them.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.

评论 #6756413 未加载

morganb180超过 11 年前

Totally agree with this. If you're shipping something not remotely close to the product that actually solves the user's problem, then you're not shipping something that's viable.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.

thetrumanshow超过 11 年前

There seems to be a giant gap of perceptions and understanding on this topic.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.

enos_feedler超过 11 年前

When I am trying to decide how much time I should spend on product 'quality' (robustness, bug free, elegant design) I always think of it in the context of experiments. The product is actually a byproduct of a sequence of experiments where the true focus is 'learning outcomes'. I consider the best experiments those which you learn the most at the cheapest cost. For a given experiment, if a poorly designed product gives you "outs" and makes your experiment less conclusive ie) well the users _might_ think this, but it also might be because my product looks like a POS. Well that isn't a very good experiment to execute. There are definitely high quality experiments you can perform where the product quality itself is poor but the learning outcome is high. This is especially true if you can filter your data set (only consider early adopters for example)

评论 #6755678 未加载

vojant超过 11 年前

"However, that is no excuse for it to look and function terribly (or not function at all)""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.

franstereo超过 11 年前

Mostly agree with your post, however I think you misunderstand the scalability argument. If you are wasting any time on making an MVP scalable it probably means you are taking time from more important activities such as sales and acquiring users.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.

评论 #6755661 未加载

beat超过 11 年前

Yes, yes, yes.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.

评论 #6755566 未加载

mbesto超过 11 年前

> Otherwise, you're missing the entire point of the M.V.P. in the first place - to iterate quickly on small features based on customer feedback and measurable data.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).

评论 #6755535 未加载

jiggy2011超过 11 年前

Depends on your product I guess. If it's something truly different and novel then maybe it doesn't matter if the UI is kinda sucky because I have nothing to compare it to.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.

rmoriz超过 11 年前

I disagree. Developers, like me, tend to build the entire thing before the customer validation. This is so wrong if you go the lean approach.Excellent blog posts about this issue: "Why only fools write code first" <a href="http://blog.reemer.com/why-only-fools-write-code-first" rel="nofollow">http://blog.reemer.com/why-only-fools-write-code-first</a>

cyberqat超过 11 年前

My thoughts having done a number of "lean" projects...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.

jbrains超过 11 年前

"V" means "viable". The profit motive encourages businesses to race to the bottom of "viability" just as with quality. So it will always be.

dsugarman超过 11 年前

if you aren't embarrassed about your first release to any potential user (beta or v1.0), you are not doing it right. the reasoning: if you have the most basic function that someone would use your product for, and any amount of people using your product, it will always be painfully obvious what to build next.