There’s a conflation going on here. Pareto can be good engineering—a product that solves 80% of use cases at 20% of the cost is a great efficiency: tax prep software for simple tax returns only; a minimalist photo sharing site with few social features; a phone with a great UI and no user-installable apps.
This gets conflated with products that are 80% reliable across all their tasks (LLMs, brittle software). That makes it difficult for users to rely on the product, because occasionally a failure will happen, and the user can’t build a mental model of what works and doesn’t.
That's not pareto. That's just finding a niche of people who would prefer more focused products.
Tax prep software for simple returns only is an entire product. Adding support for the other 20% would lose your initial base's interest.
Tax software that aims to solve all problems whose MVP is it handles 80% of people's tax returns is the pareto the author is talking about. But the real complexity is the other 20%.
Pareto as a minimalism process for focused product development is not engineering (good or bad).
Forgetting pareto and believing (or lying) that you are truly 80% of the way there is a big problem in engineering and funding. The author is correct in that.
Comments
There’s a conflation going on here. Pareto can be good engineering—a product that solves 80% of use cases at 20% of the cost is a great efficiency: tax prep software for simple tax returns only; a minimalist photo sharing site with few social features; a phone with a great UI and no user-installable apps.
This gets conflated with products that are 80% reliable across all their tasks (LLMs, brittle software). That makes it difficult for users to rely on the product, because occasionally a failure will happen, and the user can’t build a mental model of what works and doesn’t.
That's not pareto. That's just finding a niche of people who would prefer more focused products.
Tax prep software for simple returns only is an entire product. Adding support for the other 20% would lose your initial base's interest.
Tax software that aims to solve all problems whose MVP is it handles 80% of people's tax returns is the pareto the author is talking about. But the real complexity is the other 20%.
Pareto as a minimalism process for focused product development is not engineering (good or bad).
Forgetting pareto and believing (or lying) that you are truly 80% of the way there is a big problem in engineering and funding. The author is correct in that.