The gaming industry has become a masterclass in how to misunderstand MVP. Just not in the way you’d expect.

Two failure modes dominate the landscape. AAA studios ship products so incomplete that day-one patches routinely exceed 50GB. Meanwhile, crowdfunded indie projects spend years in “early access,” accumulating millions in funding without ever reaching 1.0.

Both extremes violate the same principle. They’ve forgotten what the V stands for.

When Minimum Means Broken

Somewhere around the mid-2000s, the ability to patch games after release became standard. What started as a safety net became a crutch, then a business model.

The pattern is predictable now. Publisher sets an immovable release date tied to holiday sales or fiscal quarter. Development team flags that the game isn’t ready. Marketing has already committed millions to the launch window. Game ships anyway. Day-one patch arrives to make it playable.

Cyberpunk 2077 became the poster child for this approach. CD Projekt Red’s December 2020 launch hit an inflexible corporate timeline regardless of development state. The result was a game so broken on last-gen consoles that Sony pulled it from the PlayStation Store entirely. The studio spent years rebuilding both the game and their reputation.

No Man’s Sky followed a similar arc. The 2016 launch delivered so little of what was promised that the studio went silent for months while rebuilding the game from the ground up. To their credit, they eventually delivered. But “eventually” took years of free updates, and the launch damage was severe enough that it became a cautionary tale for the entire industry.

The counter-argument exists. Day-one patches allow continued development during the 4-6 week manufacturing and shipping window. QA testing windows are larger than ever because teams can fix issues discovered late.

These are all fair points, but there’s a difference between “polishing during the manufacturing window” and “shipping a fundamentally incomplete product” because the release date was set before the game was ready.

When Viable Means Perfect

The opposite failure mode is less visible but equally instructive.

Star Citizen has raised over $925 million from backers since its 2012 Kickstarter. As of early 2026, it still hasn’t reached version 1.0. The scope has expanded continuously, with new features announced before previous ones are finished. Chris Roberts projects a full release sometime between 2027 and 2028. The game exists in a state of perpetual almost-done.

It’s not alone. The crowdfunded MMO space is littered with projects that have been in “development” for the better part of a decade.

Some of these projects will eventually ship. Some already have in limited form. But the pattern is consistent: scope expands faster than development progresses (especially when the “base game” is suddenly technical debt), and “we want to get it right” becomes indistinguishable from “we can’t ship.”

The failure isn’t ambition. It’s confusing “viable” with “perfect.”

The V Is Doing All the Work

I wrote about this years ago. The classic skateboard-to-car progression illustrates the point: each iteration should be complete and functional for its scope, not a partial version of the final product.

A skateboard isn’t a car without wheels. It’s a fully viable mode of transportation at a smaller scale. A bicycle isn’t a car missing an engine. It’s a complete product that serves the same fundamental need differently.

The problem in both failure modes is treating MVP as a statement about quality rather than scope.

When AAA studios ship broken games, they’ve defined minimum as “whatever we have by the deadline” regardless of whether it’s viable. When indie studios spend a decade in early access, they’ve defined viable as “everything we eventually want to build” regardless of whether any minimum version could ship.

Both miss the point. The V isn’t optional. It’s the whole constraint.

What This Means for Software Teams

The gaming industry’s failures are instructive because they’re so visible. When a game ships broken, millions of customers notice immediately. When a game never ships, the crowdfunding page becomes a public record of broken promises.

Enterprise software failures are usually quieter but follow the same patterns.

Teams under deadline pressure ship features that technically work but create more problems than they solve. The integration is live, but the edge cases break constantly. The dashboard exists, but nobody trusts the data. Minimum was achieved. Viable wasn’t.

Other teams polish endlessly, afraid to ship until everything is perfect. The refactor before the refactor. The edge case that affects 0.1% of users but somehow blocks release. “We want to get it right” becomes the excuse for never getting it done. Viable is redefined as “impossible to criticize.”

The Viability Question

Before any release, the question isn’t “is this everything we want?” It’s “does this work for the purpose we’re shipping it?”

A game that crashes on startup isn’t viable. A game missing a planned multiplayer mode might be, if the single-player experience is complete.

A feature that requires manual workarounds to function isn’t viable. A feature that lacks advanced options might be, if the core workflow is solid.

Viability isn’t about feature count. It’s about whether someone can accomplish the thing they’re trying to accomplish, reliably, without heroic effort.

The teams I’ve seen navigate this well define viability criteria before development starts, not when someone asks if they’re ready to ship. They know what “done enough” looks like because they agreed on it when scope was smaller than ambition.

The Patience Trap

There’s a related failure mode worth naming. The community that’s too patient.

Crowdfunded games survive perpetual development because backers keep funding them. Early access games stay in early access because players keep buying them. The market signal that would force a traditional release decision never arrives.

This isn’t purely a criticism. Some games genuinely need longer development cycles than publishers would allow. Dwarf Fortress spent 20 years in development before its December 2022 Steam release and shipped one of the most ambitious simulation games ever made, selling over 160,000 copies in its first 24 hours.

But patient communities can also enable indefinite scope creep. When there’s no external forcing function, “minimum” expands to match whatever the team wants to build next. The viable product that could ship this year becomes the ambitious product that might ship in three.

The discipline has to come from somewhere. If the market won’t provide it and the funder won’t demand it, the team has to impose it themselves.

When the Market Moves Without You

There’s another viability problem that extended development creates: the market you’re building for might not exist by the time you ship.

Duke Nukem Forever spent 15 years in development and holds the Guinness World Record for longest video game development cycle. When it finally released in 2011, it was building for a gaming audience that had fundamentally changed. First-person shooters had evolved toward tactical realism and multiplayer focus. The over-the-top single-player action that defined Duke Nukem 3D in 1996 felt dated by 2011. The game wasn’t just late. It was building for a market that had moved on.

This happens in enterprise software too, though usually less dramatically. A two-year integration project launches into an ecosystem that’s consolidated around different standards. A custom analytics platform ships after the industry has standardized on cloud-native alternatives. The product works exactly as designed. The problem is that nobody needs products designed that way anymore.

I still enjoy games from 20 years ago. Not because I’m nostalgic for “old school gaming,” but because many of them feel complete in a way that some modern releases don’t. They shipped as finished products. The scope was what the team could deliver, not what they hoped to eventually build. There’s something to be said for that discipline.

The Marketing Gap

Open development creates its own viability trap. Marketing makes promises that engineering can’t keep.

When studios “develop in the open,” they create expectations that compound faster than capabilities. Every preview and dev diary adds to the public’s mental model of what they’re getting. The marketing team describes what the game could be. Engineering builds what it actually is. The gap between those two grows with every roadmap update.

No Man’s Sky promised a universe of infinite exploration. Hello Games built something more modest. The gap between promise and delivery wasn’t just a quality problem. It was a coordination problem. Marketing had committed to features that development hadn’t finished, sometimes to features that were never actually planned.

This isn’t unique to games. Enterprise software demos routinely show idealized workflows that don’t match production reality. Roadmaps announce integrations that engineering hasn’t scoped. Sales commits to delivery dates that development hasn’t validated.

The viability question has to include public expectations. If you’ve promised world peace and cancer cures but you’re actually shipping high-resolution water rendering, the product might technically work while the launch still fails. Viability isn’t just about whether the thing functions. It’s about whether it functions for the purpose people think they’re getting.

The teams that navigate this well keep marketing and engineering in the same room during planning. They announce what’s built, not what’s imagined. They scope public expectations to match development reality, even when that feels less exciting.

Shipping Is a Skill

The uncomfortable truth is that shipping is its own skill, separate from building.

Some teams are excellent at building and terrible at finishing. They can construct elaborate systems, but they can’t draw a line and call it done. Every version feels incomplete because they can see all the things it doesn’t do yet.

Other teams ship constantly but never cohesively. They hit deadlines by cutting scope, but the result feels like a series of disconnected pieces rather than a product.

The skill is holding both constraints simultaneously. Minimum means something ships. Viable means what ships works. Neither constraint cancels the other.

The V is doing all the work in that acronym. It’s the part that separates a useful product from a broken one, and a shipped product from vaporware.

When you find yourself rationalizing why something incomplete should ship, or why something functional shouldn’t, ask whether you’re honoring the V or avoiding it.