This wasn't what I got out of the article.

Too many people focus on the Minimum, and don't care about the Viable or the Product. There are table stakes. MVP doesn't mean half-assed and buggy. They misuse the concept and release any old crap.

As a result, MVP has become too much of a buzzword and the intention behind it got lost.

The author speaks as if 'minimum', 'viable', 'product' are a Venn diagram rather than 2 adjectives and a noun, which muddies their point a bit. The Venn diagram version that people use is often feasible (can it be built), viable (will it sell), desirable (do people want to use it), which would've made their point clearer.

I think the trouble with MVP is that what we consider the "minimum that's viable" has changed — if you look at early days of Twitter for example (both its UI and the frequent 'fail whale' outages), it wouldn't pass muster today but at the time was enough to become one of the main platforms of the web.

Nowadays, you'd need a much more polished MVP in order to compete because the standard of what end-users expect has risen a lot (both in terms of functionality & NFRs, like security, robustness, interop, etc.).

I agree that this is what I drew out of it. You can't hand wave away some pieces of the product as 'minimal' if they are directly applicable to the basic use case. I've been the audience that has to say 'great but the fact that this doesn't allow more than 20 things is a complete non-starter' constantly. You then wait for the next iteration and these critical changes aren't even talked about, and so you just give up on them and start working with the next vendor. Another variant I see often too is something that 'creates a job title' at the customer where their product is so much of a ongoing headache that you end up needing a FTE or department just to manage the thing. It is often quite apparent from the visible product where you ask about things like 'how does the system alert if there is a problem' or 'how do we know your agents are connecting' is a TODO item that says 'we defer to YOUR infrastructure' instead of having a plan that works through the whole system well.

I don't mind that people try to setup a minimal product or have people to be self-inserted to do the work that is planned to be automated later on the service company's side, but if your answer to the question 'if we use this product we'll have 1000 artifacts to configure, how do we do this efficiently' is 'you have to go one by one and we'll implement it later' on a product/service that clearly is going to have 1000's of things is just junky and not minimal at all.

EDIT: also don't be that person who says 'well you can do that with the API!' when you in fact can't do it through the API and/or it is the exact same level of clunkiness as the UI.

That doesn't mean the MVP is a bad idea, then. That means it's being poorly implemented.

If an idea is routinely implemented badly, then it is a bad idea to implement it at all.

I have an intuition that there are multiple classes of ideas: ideas that are linear interpolation of the present into the future: Those are intuitive, either for domain experts or the general public. A little voice that says "Next we do this..."

ideas that form a gravitational force: these are ideas that pull many, uncoordinated efforts. It is a bit hard to describe, but I think of this as ideas that are "necessary" in a grander emergence that needs the ideas to cement its existence.

Ideas that are not ready to be hatched: "the too early" class. Sometimes because a missing ingredient has not been identified or not sufficiently widely available. When those ideas fail, and a decade or so later new thinkers think them again and realise they failed, sometimes they go back and figure out the prerequisites weren't there and now they are or they build the prerequisites themselves.

Ideas that are non linear: those are the rarest to come by. I believe they require extreme tolerance for counter-factual thinking either naturally or otherwise-inhibition-reducing aids.

I don't think such an absolutism holds water: great ideas don't exist in vacuums. There is no magic bullet which makes startups successful: lots of things, big and small, need to come together to make it. I think the article touches on several failings which aren't actually the fault of mvps at all.

For reference, from the article

> An example of non-viability or non-productness is if you want to have a business, but you’re not quite positive what you should build or sell. This is no good as the product and the desire to help your customer, rather than to just “have a business”, should be your soul.

Reading that and your answer back to back, I think you have a better view than the author of what an MVP should be.

The piece is all over the place, and paradoxically might work better for people who already have a good idea of what it should be about, fill the gaps with their own wisdom and ignore the part that make no sense otherwise.

I also did not get this from the OP article. I would say he could have articulated things better.

It is imperative to note that what constitutes minimum and viable had generally changed since 2010.

We should also keep in mind that those terms are relative terms, depending on the domain.

For me, I think one should know a lot or experienced personally the problem(domain expertise) and be open to the form of the solution(the product). For practical reasons, if nothing else, learning any sufficiently complex domain while trying to build a business is expensive.

This article then serves to increase the misunderstanding, rather than just clarifying what it should mean. Conflating idea and implementation is not good.

"just have money" - this is my new mantra.

That was my takeaway too. MVPs help you understand what the product should be. Helps you escape chicken/egg situations.