If you read my earlier article on planning the path from prototype to production, this one builds on the same foundation, but now through the lens of what it takes to actually ship.

There’s an old truth whispered in the game development community that is: “Every game that ships is a miracle.”
And after more than a decade working in game development across indie teams, massive LiveOps organizations, and global franchises, I’ve learned this is not poetic exaggeration, it’s simple fact.

Shipping a game requires the perfect convergence of design, engineering, art, animation, audio, narrative, QA, platform compliance, production, build systems, timelines, tools, and dozens of tiny systems that no player will ever notice… unless they break.

Games are not books.
They are not films.
They are interactive, living ecosystems that must survive whatever the player throws at them. This complexity is why it’s so painful (and so inaccurate) when recruiters evaluate developers by a single question:

“How many shipped titles do you have?”

It’s a broken metric.
And it hides a leadership problem no one wants to talk about.

The Myth: Shipped Titles = Competence

We love the idea that developers with shipped titles are “proven” and those without are “unproven.”
But after seeing both sides of this equation up close, I can tell you:

Shipped titles reflect luck and leadership far more than talent.

Some of the most brilliant developers I’ve ever worked with have zero shipped games: not because they failed, but because the projects failed.

Vision changed.
Leadership changed.
Budgets vanished.
Publishers pulled out.
Projects pivoted into oblivion.
Teams were restructured.
Games were canceled in mid-production.

Meanwhile, I’ve seen other developers who arrived in the last six months of a stable project suddenly credited with a “shipped title” despite doing almost none of the foundational work.

Talent didn’t change.
The timeline did.

My First Shipped Game? Pure Luck.

When I shipped my first game in Early Access almost ten years ago, I didn’t fully understand this dynamic yet. I celebrated on Facebook with a rocket ship image because it felt like the beginning of a potential successful game.

But behind the scenes, it was chaos.

The producer and designer (both with prior shipped experience) assumed programmers took care of certification requirements (CTR). They came from larger teams where CTR was handled by dedicated engineers. On our tiny team, I was the only programmer… and they never realized that meant CTR responsibility now fell entirely on me.

Two weeks before launch, they discovered CTR existed.

They panicked.

Thankfully, my learning at DigiPen taught me about platform compliance, so I had quietly been knocking out small CTR items every week since my third week on the job. By the time they realized the risk, I’d finished about 90% of the requirements: screen resolutions, graphics settings, platform expectations, build robustness, the basics needed for Steam Early Access back in 2015.

The remaining 10% was because of outdated CTR that I had on hand, so it took extra effort… but we shipped.

We didn’t ship because leadership planned for it.
We shipped because a single developer anticipated a blind spot.

That’s not a fair hiring metric.
It’s luck meeting preparedness.

The Developer Who Taught Me the Most Has 0 Shipped Titles

One of the people who shaped my career the most wasn’t a coworker, he was a senior undergraduate in the real-time interactive simulation program while I was completing my Master’s. He had a few years on me, understood engine development at a depth I had never seen, and guided me through some of the hardest parts of my learning curve. A large portion of the developer I became was because he helped me at exactly the right moment.

Today, on paper, he has 0 shipped titles.

Not because he “couldn’t do it”, but because every single studio he worked for canceled the projects he contributed to.

And he is not an outlier.

I’ve met dozens of developers across the industry with a decade or more experience and no shipped games, and dozens of others with one or two shipped titles they barely touched.

This is why the metric itself is broken.

When We Finally Shipped, Veterans Got Emotional

Across my career, I’ve worked with people who had shipped AAA titles and others who hadn’t shipped anything in more than a decade. And when one of our projects finally shipped, I saw something I’ll never forget.

Veteran developers (seniors, leads, even staff-level engineers) were celebrating publicly on Facebook and other platforms.
For some, it was their first shipped title in almost a decade.
For others, it was the first ever.
You could feel the pride and relief in every post.

And even though a few of those projects only survived three or four weeks after launch before being shut down, the celebration still mattered.
They weren’t celebrating longevity, they were celebrating the fact that the game finally made it out the door after years of cancellations, resets, and dead ends.

That’s when it truly hit me:

Not shipping is not a developer failure.
It’s a leadership failure.

If you want a structured way to prevent the confusion, resets, and misalignment that sink so many game projects, the Story Mapping Tool for Game Developers can help.

What LiveOps Teams Taught Me About Predictable Shipping

My time on Minecraft (Senior Software Engineer) taught me how stable LiveOps cultures ship incrementally every ~3 months because their entire pipeline is built for consistency.

ARK taught me the intense discipline behind shipping every six weeks across multiple platforms, as I worked as a build engineer submitting builds to different storefronts.

Pokémon GO taught me what it takes to fix a production backlog, create accurate estimates, and build development plans that reflect reality, not optimism.

None of these teams relied on “talent alone.”
They relied on:

• Clean backlogs

• Sliced increments

• Definition of Done

• Realistic planning

• A strong product mindset

• Tight alignment between product, engineering, and production

This is what the CSP-PO program emphasizes:
The Product Owner defines Value “the What”, while developers and Scrum Masters handle “the How.”

Shipping is never “just coding.”
It’s product leadership.

Modern Certification Requirements Still Matter

Yes, platforms today have lowered the barrier to publish.
Yes, modern engines automate a lot of technical requirements developers used to do manually.

But reviewing CTR documentation is still essential, because:

• Requirements evolve

• Platform expectations shift

• Some engines don’t configure everything by default

• Target devices vary

• Screen sizes differ

• Performance budgets change

• You still need to pass submission checks

Before shipping, always:

• Review the CTRs for every platform you intend to launch on

• Test on multiple devices, resolutions, and aspect ratios

• Check for UI clipping, scaling issues, artifacts, and performance drops

• Verify minimum spec

• Validate settings and graphics options

• Confirm platform-specific expectations

Even if the engine does 80% automatically, the other 20% can kill you.

A Game Is Not a Project, It’s a Product

Some studios over-focus on the game and neglect marketing.
Others over-focus on marketing and neglect the game.

Both are wrong.

A game is a product, and products need:

• Visibility

• Stability

• Positioning

• Value clarity

• And quality

If players don’t know your game exists, it fails.
If the game is buggy, unstable, or not understandable, it fails.

It must be a 50/50 split.

So Why Do Games Ship?

Because, for one brief moment:

• Leadership aligns

• Teams communicate

• The backlog is clear

• Requirements make sense

• Platforms are satisfied

• Builds are stable

• Marketing is coordinated

• And a thousand invisible decisions finally converge

This is why I repeat it again:

Every game that ships is a miracle.

And it has far more to do with leadership alignment than individual developers.

Closing Thoughts

Shipping a game isn’t about luck, it’s about clarity, alignment, and leadership. Teams ship reliably when they share the same map, understand the value they’re building, and follow a structure that supports them from concept to launch. When those pieces are missing, even the most talented developers struggle to finish a game.

If your studio needs support creating those conditions (shaping the path, organizing the backlog, or preparing a vertical slice) my Game Project Management Services help teams define scope, set priorities, and build plans that make shipping predictable.

FAQ: Shipping Games

Why do so many talented developers have zero shipped titles?

Because shipping has far more to do with leadership, budgets, timelines, and organizational stability than individual talent. Many incredible developers spend years on canceled or rebooted projects due to decisions entirely outside their control. The skill level is there, the opportunity isn’t.

Is “shipped titles” a reliable hiring metric?

No. It’s one of the weakest indicators of an individual developer’s ability. Some developers ship because they join a stable project near the end; others contribute for years to ambitious projects that gets cancelled along the way. “Shipped titles” measures context, not competence.

Do canceled projects still count as real experience?

Absolutely. Canceled projects often involve some of the hardest technical, design, and production problems, the kind that never make it into the public release. Working through reboots, pivots, and prototype cycles builds deep expertise, even if the game never ships.

What are Certification Technical Requirements (CTR)?

CTR (Certification Technical Requirements) are platform-specific checklists ensuring your technical game meets quality, performance, compliance, interface, and stability expectations. Modern engines cover many of these automatically, but teams still need to review them, especially UI scaling, performance, graphics settings, and platform-specific behaviors.

With modern engines, do I still need to test across multiple devices?

Yes. Even though today’s engines automate a lot, every platform, screen size, performance tier, and aspect ratio behaves differently. Testing on multiple devices is essential to avoid UI clipping, resolution issues, input problems, unintended artifacts, and platform-specific bugs.

How important is marketing in the shipping process?

Critical. A game is not a project, it’s a product. Delivering a polished build without visibility means players will never discover it. Marketing and development need to work in parallel; the closer the split is to 50/50, the healthier the product launch tends to be.

Why do games feel harder to ship than other forms of media?

Because games are interactive. Books and films are experiences with a predefined point of view, but games must respond to player actions, physics, systems, and edge cases. They require perfect coordination across design, engineering, art, audio, narrative, UX, QA, platform requirements, and technology. That’s why every game that ships truly is a miracle of coordination.

What does a Product Owner contribute to successful shipping?

A Product Owner defines value (the “what” of the product), by keeping the backlog clear, setting priorities, and aligning the team on what they’re building and why.
And in game development, this overlaps heavily with the role we traditionally call the Game Designer or Creative Director.
In practice, PO and Game Design are the same role translated across two different worlds, both responsible for guiding the vision and ensuring the team builds something engaging and valuable.

Why do LiveOps teams ship more predictably?

Because their systems, pipelines, and backlog structures are designed for cadence. In LiveOps environments like Minecraft or ARK, teams work in consistent increments, maintain clear priorities, and treat shipping as a rhythm. Predictability comes from structure, not crunch.

What’s the biggest factor that determines whether a game ships?

Leadership alignment. When leadership creates clarity, defines value, and sets achievable priorities, teams ship. When leadership is inconsistent, unclear, or constantly shifting direction, projects stall or collapse, no matter how talented the development team is.