M.V.P., not M.V.P.O.S. | Hacker News Reader

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

robertnealan.com

75 pointsrobertnealan36 comments

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.

MVP is about risk reduction. If your MVP fails because you didn't hit the right spot, it's a success: You saved a lot of time and money and can look for better opportunities.

I don't think it's easy to distinguish an MVP that failed because there was too much usability friction that discouraged usage from an MVP that didn't hit the right spot.

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?

A good presentation does improve sales but imho the value is more important. E.g. if it solves a problem and looks like crap, it's a good enough MVP. A business is not sustainable because of its design, UX or fancy code but because of its value to the customer. A good UX/design/fancy new technology increases the conversion, user experience and what not but it's usually not the key criteria if a business fails or not.

We all see the fancy bleeding edge presentations of successful ventures today but we also forgot or never saw the initial MVP that evaluated the idea/customer and served as a foundation for everything later on.

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.

> You do need to pare down features to an MVP, because otherwise you're never going to finish, or are going to deliver crap.

Or deliver something beautiful to your team that no one actually wants, or will purchase

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.

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: http://radoff.com/blog/2010/05/04/minimum-viable-product-ran...

That Venn Diagram alone is worth its weight in gold.

prints and tapes to wall

> I feel like many people miss out on the V part of MVP

... 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.

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.

While I naturally want the UI to look nice as a designer, I'd personally have no issues shipping a prototype/MVP using a framework like Bootstrap. What I won't stand for is when a product being an "MVP" is an excuse for shipping code that hasn't been tested properly and/or has no thought to the UX.

Craigslist may look like 1995 but it still does a better job than any direct competitor out there.

>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.

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: 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)

Agreed entirely. The main point I was trying to make is that while testing MVP fashion is an incredibly useful way of collecting feedback, it's often misappropriate as a way to ship half-baked or poorly thought out products/features. At the end of the day though it's important to note that the people who misappropriate the "MVP" name would likely fail in one way or another regardless.

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.

Yep. I usually ask: what features can we cut? And then do the remaining features well.

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.

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.

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.

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)

The opposite can be true, too. Imagine you build something like a paid 4chan in AngularJS (e.g. not really new business idea combined with rather new technology). You might get false positives because some people just subscribe because of the new technology. They are not really interested in the product but just to watch the execution/implementation to learn for themselves. This is not sustainable because those customers will quit as soon as they got their findings out of your experiment.

My main point was to be experiment driven and let the requirements flow from that. The idea of filtering by early adopters is just a suggestion on how to think "experimental results first" and that you don't need to run your experiment across 'everybody' in order to get the results you need (as there are surely some people in this set who demand polish/perfection). In regards to what you are saying about early adopters giving you false positives, it depends on what assumptions you are testing in your experiment. What is your hypothesis in this experiment?

"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.

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.

This is actually what I was trying to say, I just think my sentence came out a bit convoluted. If you can manually process something that doesn't degrade the end-user's experience, then do so for now and focus on more important features until it's either necessary or has been validated as a valuable feature you'll be keeping around.

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.

Mabye there are not enough customers to automate it? A MVP is about customer validation, just like the kickstarter principle. No money, no product. Never build something nobody wants. Doing it manually is perfectly fine for a MVP.

It started with scratching my own itch, and I've done a lot of customer validation since then (not as much as I'd like, but enough). So in this case, the MVP is about limiting scope, not doing things that don't scale. Doing it manually is not "perfectly fine", because the problem is that it's already being done manually, and needs to be automated. "Manual" and "viable" are incompatible in my case.

Which gets to the author's point.

There are many things that can be automated and we developers believe this is some kind of value, however a MVP is about customer validation: If you have not validated your product, it's harmful to automate it. If you have customers and they pay for automation, you don't have a MVP anymore. You're already playing in the next level.

> 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).

Tough to get valid validation when the product your shipping doesn't solve the need for the end user due to its MVP-ness. If you deliver crap, it's hard to separate the feedback of "this is crap because it's missing xyz feature or looks ugly" vs. "this is crap because it doesn't solve a need."

I've found that people have a hard time separating the two in interviews.

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.

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" http://blog.reemer.com/why-only-fools-write-code-first

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.

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

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.

Reply on news.ycombinator.com