If it’s truly minimal, it won’t be viable.
In the pursuit of “minimum,” we sometimes remove the very thing that makes it work.
Minimum is a constraint. Viable is a threshold.
The Moment of Inspiration
The roadmap said MVP.
The team said, “Let’s keep it lean.”
Features were trimmed. Edge cases removed. Safeguards postponed. Onboarding deferred. Reporting moved to “phase two.”
“It’s only the minimum,” someone said.
“We can iterate.”
What shipped technically worked.
It satisfied the requirement.
It demonstrated the concept.
Users tried it once.
Then they stopped.
The Paradox
The Minimum Viable Product was never meant to be the smallest possible version.
It was meant to be the smallest version that could survive contact with reality.
The paradox is that teams chase minimum more aggressively than viability.
We remove friction by removing features.
We remove complexity by removing support.
We remove risk by removing resilience.
Each cut feels disciplined.
Until the product collapses under real use.
Minimum is easy to measure.
Viable is not.
The Reflection
An MVP must prove something.
It must prove value.
It must prove behavior.
It must prove that the idea holds under pressure.
If it cannot sustain use, it is not viable. It is a prototype disguised as a strategy.
Viability often requires things that feel inconvenient to include.
Error handling.
Guardrails.
Onboarding.
Clarity.
Not because they are luxurious, but because they allow the product to stand on its own.
The boat in the field is minimal.
But without water, it is not viable.
The Teaching
Minimum is a number.
Viable is a condition.
Do not optimize one at the expense of the other.