The HBR says it is. What say you, Indie Hackers?
It's not saving the link field, so here's the link: https://hbr.org/2019/01/the-era-of-move-fast-and-break-things-is-over
I didn't read the entire article, but it doesn't appear to be talking about level of product completeness at all. It's talking about what software means in the wider business world and how it affects the world.
Your title makes sense after reading the article, but before, it sounds like it's talking about how to build an app or business, rather than the impact it has.
And I'd say:
This comment was deleted 7 years ago
Don't forget the "Viable" in Minimum Viable Product. The point of an MVP is to launch a very focused product that does one thing well.
Ideally, you orchestrate existing services together to achieve that task with the minimum amount of work and only work on the exact thing that makes your product unique.
If you can't sell it yet, then you either have a product no one wants or you haven't yet met the bar for "Viable". That's my opinion and what I think the spirit of MVP is.
I've heard some people refer to it as a Minimum "Sellable" Product or MSP instead for that reason.
Actually, it is not. But unfortunately, this seems to be what the maker community has turned it into.
As originally explained and proposed by Reis; MVP is a process by which to test assumptions. It, by no means, has to be a product that does one thing very well. In fact, in that not have to be a product at all, period. The word "product" in the acronym refers to the product as in the result of putting in effort, not a watered down version of the final product you have in mind. Rather, it takes shape dictated by the assumption you're looking to test. To that end, an MVP can be as simple as a landing page, a survey, or even a couple of phone calls.
Well said!
THIS is the only right answer in this whole discussion
I do agree with @AntCas, an MVP is not just a landing page, the landing page is only a tool to test your assumptions on what an MVP is. A classical example is Dropbox. They started out just saying hey, we are going to synchronize files between devices. And they saw there was interest, but by no means that was an MVP. The MVP came as a closed beta launch that they used to test the reaction of real people.
An MVP is what you market on Kickstarter, like the Oculus. It works, it just doesn't have many features, but still can be interesting for a group of customers.
The concept of MVP has been misinterpreted and changed over the years in such a HUGE way, and I think it sometimes makes people think in the wrong way and do the wrong things when they have an idea.
So many things I want to say so I'm just going to ramble haha:
To me, Eric Ries' definition still holds up:
"A Minimum Viable Product (MVP) is that version of a new product which allows a team to collect the maximum amount of validated learning about customers, with the least effort."
With a small addition: "While delivering the perceived / intended value of the product."
Sidestep:
When you want to build an maintain a business there are 3 equally important elements you have to tackle:
Here, "Viability" means “the ability to deliver the value successfully, in business terms”.
What you are investigating with an MVP = DESIRABILITY. THE #1 reason startups fail = NO MARKET NEED. When you know what people want, you can build something Feasible for that and it also becomes more clear (to figure out) how you can (possibly) earn money.
The word "Product" in MVP is also confusing. Like @chillyorange mentioned:" The word "product" in the acronym refers to the product as in the result of putting in effort, not a watered down version of the final product you have in mind."
In my mind, an MVP is combined of 6 things:
When you look at these elements BEFORE you build something, there will be some things you're sure off and definitely things you're not sure off.
Too many times I see people ask: "I've build a thing, now what?" - which basically means you skipped a few of the elements above: knowing who you're target customer is, where to find and reach team, how to talk to them, gather feedback for your product etc.
Building is the most fun but there's a lot of things you can (and must) do if you don't want to waste your time. So "MVP" is more a process than a Product, which is a HUGE difference in approach".
It's not "can you build it?" (answer is probably YES), but "Should you build it?" --> answering that question requires investigation and effort, and most of the times does not involve building a half-assed version whatsoever.
Ok that's enough for now I think 😅sorry for the rant!
1/ Today's best practices are not tomorrow's
2/ I've never thought MVP was a good practice, rather than "viable" the product, although minimal, has to be "loveable" :-) ... MLP!
I was actually just talking to my friends about this topic! The bar has risen for what's acceptable as "MVP." Even drawing from my personal experience, I deleted apps off my phone because their UX & UI were horrible. There are so many competing apps anyway.
'Viable' is the key term in my mind. You don't have an MVP until the product is actually minimally viable. Meaning, you have something that customers are actually paying for and has a viability level that is sustainable for the business.
I agree with many of the comments below. MVP, MMP, etc, all seek one goal in "Lean" methodology - build and validate your hypothesis in an iterative manner. In the evolution of IT, there are always movements - hype cycles , to borrow from Gartner.
Perhaps, MVP is behind us now and MMP is the new lingo...I'm going to bet you that a new term will be used in the next 3-5 years; the meaning/intent, however, will most likely be the same.
Here is what I have experienced as I am in the idea/solution validation phase and what I think the MVP means. In order to test our riskiest assumption, I have talked so far with almost 30 businesses. The problem was clear from the beginning to me as I had suffered from it and that's why I decided to start my own startup.
MVP could be as simple as an idea/solution, of course, depending on who you're talking to.
If you are talking to an innovator, your idea/solution will be enough for them to jump on board.
If you are talking to an early adopter, they would like to see at least a web version of your app making sure that you are reliable or at least you have something close to concrete.
But if you are talking to the 70% (the majority), your so-called MVP will need to be something they can see and visualize, if not they are not interested to test it, something that has an attractive UX, something they can play with.
No need to mention the laggards. They don't deal with MVPs at all.
So validate first and try to find those who suffer/need it the most and fit the right category (innovators).
But do not delay taking your solution to your potential customers because you were not able to find the innovators. Having said that, if you think, you will not get people attention because your MVP is not fully functional, I would question the severity of the problem you are trying to solve. If the problem is real, people do not care whether you solve it via an app that looks killer or present an excel sheet. Of course, what you present depends on your product or service...
what is your idea and how are you approaching MVP now?
We are building an app to manage and schedule part-time workforce for restaurant and bars by building and sharing a dedicated roster of employees. Our MVP will be a webpage to begin with where we will process all back end staff manually. Hope that helps!
The SaaS space is getting crowded generally. Many of the best SaaS have already been built and a big chunk of them are now monopolies. There can only be so many Ubers and Airbnbs before we run out of human activities which can be majorly disrupted in the foreseeable future. Often times, companies of that magnitude are the competition of a new product. Not much room for error.
Building an entirely new product that nobody has ever seen yet everybody needs it desperately in their lives is getting harder.
Which means that newly built products are either useless or have already established competitors with similar or identical features. On top of all of that, users' expectations of software have exploded, and their tolerance for buggy products is low.
That doesn't leave much room for the MVP model, at least in the way it's understood by many people, meaning bugs and bad UI. Solving a problem overlooked by everyone else will always have value though, so as long as the MVP does that it has a shot.
I don't think so, but it's greatly reduced, mainly because it's so easy to build a startup today, on every field there's competition - you can't win with a crappy MVP when you have better competitors, even if they are not necessary direct competitors and users usually expect a lot more these days from startups - great UI/UX, strong set of basic features, great support, etc
I agree here. A MVP was designed for validating product to market fit. If other companies in your space did that, then a MVP is a wasted step.
Not necessarily - Analogs are great and can help form the concept of your product's MVP. But, that doesn't mean a product with competitors will itself ever be minimally viable just because it offers "similar" features.
This comment was deleted 4 years ago
I just read this the other day too.. it really helped me in understanding the idea of MVP and how to look at my idea(s) and slim them down.
This comment was deleted 8 years ago
This comment was deleted 7 years ago
I think it's just a little reddit syndrome creeping in - assuming the point being made without reading. The poster probably could've explained what it was actually about to get rid of the assumptions.
The "what is an MVP" discussion is useful, but I don't see a lot of people on IH making absolute garbage and trying to make millions of dollars off of it :-P
I agree. I purposely didn't answer my question one way or the other, because I wanted to see what people said. But I definitely agree and appreciate how you've articulated it here.
This comment was deleted 8 years ago
This comment was deleted 7 years ago
My favorite summary of this is from Jason Fried: "Build half a product, not a half-assed product."
It should have good (looking) design, good UX, and be free of bugs. It should delight customers with the 1 thing it does.
Haha! I've always liked that guy. I love that quote! Pretty much sums it up.
This comment was deleted 7 years ago
Manuel knocked it out of the park. A thousand times this.
This comment was deleted 7 years ago
I agree that there should not be defects. If the point of an MVP is to test a particular hypothesis, any results are going to be tainted by the effects of the defect therefore rendering them useless. I like the idea of simple prototyping and testing with customers pre-development, along the lines of the Google sprint approach. That way, when you do start to build something you are doing some with at least some initial validation, and you can comfortably invest time and effort in making the initial product.