> if your product is a wedding cake, your MVP is a single layer
I rather prefer the analogy put forward by Intercom: try to cupcake it instead[0], have a finished mini-version of the product instead of just one layer of the full version.
I believe the idea is the same as Nikki’s, just the analogy possibly more apt.
I don't personally think any of this is right. A good synonym for "MVP" should be "experiment": you're trying to test something.
So a cupcake might be a suitable MVP, but you're either trying to confirm the basic flavour is fine (so single layer is OK), or maybe the combination of flavours is fine (multiple layers plus icing?) or maybe the overall look/design of the cake (in which case a cupcake is wrong, you need at least one large layer, but maybe's it's a sponge rather than fruitcake because that's easier/cheaper)
If you already know in some detail what the "final product" will be, then there's not a lot of point doing an MVP. The MVP is there to learn about what the final product should be. It's not supposed to be a go/no-go test on whether the final product is correct.
You are focusing solely on the M and forgetting VP.
If something isn’t a Viable Product then it isn’t a Minimal Viable Product.
You could create an MVP as an “experiment”, but it can’t be synonyms because not every experiment is even a product or a viable product and thus not at all a MVP.
But the "viable product" bit is the hypothesis you're testing.
If you're saying "before you release it, it has to be believable as a product" - I think I basically agree with that, and for sure, that's a subset of the total things that might be "experiments" (because you can experiment with individual features, and stuff like that).
I suppose there are two ways of reading the word "viable", either "does this look sufficiently like a product?" or "is a product with this basic concept likely to thrive in the marketplace?". I think too many people focus on the former and not the latter.
As someone who kept throwing out MVPs every few weeks to painfully discouraging indifference, the term "experiment" finally started to make sense - each attempt kept missing a leap-of-faith assumption being tested, so each failure was discouraging instead of enlightening/iterative.
I think first time startup founders incorrectly assume building an MVP is like logically assembling a lego set (one best practice feature + research + user feedback guarantees people using your MVP more than once). When that logic fails, it's a heavy hit mentally.
For example, sure you know that people pay for babysitters - but can YOU get people to pay for babysitters? Pretty sure that breaks all viability if false no matter how fancy the product, so might be a good starting point designing the "minimal" part of your experiment. Educational literature might benefit from less semantics about definitions, and more teachings about what a good MVP attempt #1 looks like.
No, I don't think so. JKM's definition of "prototype" is that it's internally-facing and similar to a demo, to answer questions about feasibility. That's fine, and I agree with that.
An MVP is about answering questions about end-user value. "I can make a thing, but is it valuable in the way I think it will be?". Absolutely that needs to be working software being used by customers, but crucially it needs to be the smallest increment you can get away with to confirm that the bigger "version" is worth developing.
This is where I disagree with the post: months, or years, to develop an MVP is just too long. That's an actual product cycle. If you factor in the cost of a couple of engineers or something, that means an MVP is a minimum 6-figure dollar investment.
Where I do agree is that an MVP should probably be morphed into the full product, rather than things be thrown away. But the whole idea of "MVP" as a singular rather than plural concept I think is wrong too; that's a lot longer argument though.
I've found it useful to dereference words when they sound ambiguous. In the case of MVP, "minimum" is clear, "viable" is also fairly clear, "product" has been a candidate to get stuck on. I usually replace it with "something someone (a user) is willing to pay money for".
I rather prefer the analogy put forward by Intercom: try to cupcake it instead[0], have a finished mini-version of the product instead of just one layer of the full version.
I believe the idea is the same as Nikki’s, just the analogy possibly more apt.
[0] https://www.intercom.com/blog/start-with-a-cupcake/