Minimum Viable Product (MVP) thinking is common in product work. Start small. Ship fast. Learn. Improve. Used in the right way, this is useful.
But there is a downside.
When we think “MVP” all the time, it can spread to everything we do. It stops being a way to test ideas and becomes our main way of building. Then the focus often shifts from “What is a good solution?” to “What is the least we can do?”
This is the curse of MVP thinking.
It starts with good intent: build the smallest version that still works. But then it leaks into other areas. Internal tools. Design. Code. Team habits. We begin to ask the same question everywhere: “What is the minimum we can get away with?” And we stop asking: “What would be a good product here?” or “What is a solid solution to this problem?”
“Viable” slowly turns into “barely acceptable.”
The idea of MVP changes from “small but good” to “small and just enough.”
The result is often weak products. Features are shipped in a first, rough form and then left as they are. The “MVP” becomes the final version. The product turns into a mix of things that work, but not well. Users feel this. The product may do the job, but it does not feel like a good product.
The same thing happens in the experience. Flows work, but they are hard to use. The design looks and feels cheap or messy. The details are not cared for. People using the product can sense when the goal was “minimum” instead of “good.”
On the technical side, quick fixes become the norm. “We will clean this up later” is said often. But later never comes. Shortcuts stay. The system gets harder to change. Bugs appear more often. Simple changes take more time. The cost of “minimum” shows up over time.
This way of thinking also affects the team. Pride in good work can go down. Why polish something if “just enough” is always fine? People stop aiming high. They push for the fastest path, not the right path. Over time, “minimum” becomes the standard.
You can spot this curse in your own work by listening to how you and your team talk. Do you mostly ask “Is this shippable?” instead of “Is this good?” Are better ideas often stopped because “it’s too much”? Is feedback mostly about how fast and how small, not how good? If the word “minimum” shows up more than the word “good,” it is a warning sign.
The problem is not the idea of MVP itself. The problem is using MVP as a way to lower effort instead of a way to lower risk. MVP should be a tool, not a rule for all work. It should be a small start on the path to a better solution, not the end point.
A healthier way to use MVP is simple. Make sure “viable” still means “good enough to use with trust,” not “barely works.” Plan for at least one round of real improvement after you ship. Be clear when you decide, “Here we accept minimum,” and when you say, “Here we must build something good.”
The key is balance. It is fine to start small. It is good to learn early. But we should not let MVP thinking remove care, craft, and ambition. We should keep asking: “What is a good solution?” not only “What is the smallest solution?”
Use MVP as a tool to begin. Do not let it define how you do everything.
