alt Hacker NewsIn the story they spend months to build the MVP and people don't like it. This clearly is first point where they could "fail fast", but they believe they can improve and they do.
I guess I'm thinking where is the "fail fast" that is fast enough, but also not quitting too early?
> In the story they spend months to build the MVP and people don't like it.
Oh, that was another problem! The story says:
>> In practice it doesn’t work very well, but it’s good enough for an MVP.
No, that's quite clearly not good enough for an MVP! If your product's core functionality—baking stuff, in this case—only works one third of the time, then your product is not viable! It is maybe a proof of concept, but certainly not a product.†
So the company never should have released an MVP, they should have kept working on their reliability problems. Which is when the engineer should have realized "alright, this isn't going to work," and the whole company needs to pivot or close up shop.
Alternately, if they ship a real MVP that can produce perfect cakes with reasonable reliability, and the customers don't like it, that would also be time to change plans.
What happened in the story is they shipped a product that obviously doesn't work, customers dislike the fact that it doesn't work, and the obvious conclusion is "well, they didn't like it because it doesn't work yet," which is true but also obvious. You didn't learn anything.
This doesn't really answer your question and I don't think a definitive answer exists (and I've never worked in this space). But, obviously, this company should have stopped sooner than they did.
---
† The only exception I can see is if you can come up with a potential customer for which "an oven that bakes correctly one third of the time" would still meet their needs. Under the scenario in the story, I don't think this exists. For, say, an AI coding agent that can run automated tests and throw away bad results, a one third success rate may still be useful in some scenarios.