The Minimum Viable Product Is Now a Ransom Note

You sign up for the service that promises to fix your workflow. The landing page is a clean, gradient-and-illustration masterpiece. You migrate a small project, just to test the waters. Then you hit the wall. The export function, a basic requirement for getting your data back out, is grayed out. A tooltip appears: "Coming Soon in Q3!" The core feature you need to collaborate with a teammate requires an upgrade to a "Business" plan that costs ten times as much. You are now the proud user of a half-product, and your work is stuck inside it.

The Minimum Viable Product was once an honest tool for discovery. Eric Ries’s lean startup methodology presented it as a scientific instrument. The goal was to build the smallest possible thing to test a single, crucial hypothesis about a market. Is there a real need for this? Will people pay for a solution? The MVP was the beginning of a conversation with users, designed to maximize learning while minimizing wasted effort.

That conversation is over. Today, the MVP is a threat.

The concept has been corrupted by a decade of growth-hacking and a venture-capital-fueled obsession with showing traction above all else. "Minimum" is now the operative word; "Viable" is an afterthought. The product shipped is not an experiment to be validated. It is a vessel, deliberately left unfinished, designed to extract promises of future engagement and, more importantly, recurring revenue.

Your workflow, your data, your team’s productivity—these are the hostages. The ransom note is the product roadmap, dangled in front of you during a sales call. It’s the ever-shifting pricing page, where features are re-categorized into higher tiers every six months. The demands are simple: keep paying your subscription, tolerate the bugs, and evangelize for us on social media. In return, we might someday deliver the feature you assumed was table stakes from day one.

This practice is not merely an annoyance for customers. It is a corrosive force on the industry itself. It creates a landscape littered with zombie services—applications that are not good enough to dominate a market but have captured just enough users to avoid shutting down. They exist in a state of permanent incompleteness, sucking up subscription fees to fund a development process that prioritizes new-customer acquisition over fulfilling promises to existing ones.

Engineers are ordered to bolt on flashy, marketable features for the next funding round instead of shoring up the crumbling foundation. Support queues overflow with tickets from users asking when a basic function will finally work as advertised. The developers who write the code are the same people forced to deliver the bad news. They are building the trap and then tasked with managing the people caught inside it.

For the businesses that build their operations on these services, the risk is existential. Their critical infrastructure relies on a product that was never designed to be complete. When the startup that makes their "essential" tool pivots, gets acquired and gutted, or simply runs out of runway, their data is locked in a service that is about to disappear. The ransom goes unpaid, and the hostage is abandoned.

The MVP was supposed to be a dialogue. It has become a demand. We hand over our money, our patience, and our data, hoping the captors make good on their word. We keep paying because the friction of escape—of migrating everything to yet another unproven platform—is engineered to be just slightly higher than the pain of staying put.