Ryan Cole
Most games don’t die because the team ran out of talent. They die because nobody knew when to stop, reassess, or kill something early enough.
Milestones are supposed to prevent that. And yet, in studio after studio, I’ve watched them turn into performative box-checking exercises where leads scramble to demo a vertical slice that’s nowhere near representative of the actual game, just so the build looks passable for a publisher review. That’s not a milestone. That’s theater.
Here’s what I tell people new to production: a milestone is a decision point, not a deadline. The moment you treat it as purely a calendar event, you’ve lost the plot.
Use these pass/fail criteria at each gate to force honest evaluation rather than performative demos.
| Milestone Gate | Core Question | Pass Threshold | Kill/Pivot Signal |
|---|---|---|---|
| Concept/Pitch | Is this worth building? | Core fantasy articulable in one sentence; TAM supports budget; team has relevant shipped experience | Cannot identify target player or comparable market success |
| [Prototype](/how-to-define-a-playable-prototype-milestone/) | Is the core mechanic fun? | Playtesters replay voluntarily; 30-second loop generates measurable engagement (retention in session >10 min) | Fun requires explanation; team disagrees on what the game is |
| Vertical Slice | Can we build this at quality? | 10-minute segment at near-final quality; content pipeline produces 1 hour of gameplay/month minimum | Slice required >40% of total budget; scope math doesn't close |
| Alpha | Is the game complete in shape? | All features implemented (bugs allowed); full critical path playable; no placeholder systems in core loop | Core loop still being redesigned; team morale trending negative |
| Beta | Is it shippable with polish? | All content in; bug count trending downward week-over-week; first-time user experience tested with >20 external players | Bug count rising; performance targets missed by >25% |
| Gold/Release Candidate | Would we be proud to ship this? | Zero critical bugs; day-one patch scope defined and <500MB; launch marketing assets final | Team leads unwilling to attach their name publicly |
General information for comparison, confirm specifics for your situation.
What a Milestone Actually Is (and Isn’t)
A milestone marks a specific moment where your project should answer some hard questions. Can we actually make this? Does the core mechanic feel fun? Is the loop working? Are we still on pace for the budget? Every milestone needs to be built around questions you genuinely don’t have answers to yet.
That sounds obvious. Most teams don’t practice it.
Milestones aren’t a signal that you’ve finished a phase. They’re not a trophy, and they’re definitely not primarily for the publisher or executive team. They’re for you and your team. A good milestone forces you to surface what’s working and what’s broken, on a cadence tight enough to course-correct before it’s too late.
I made this mistake myself on a mid-sized mobile project around 2017. We inherited a milestone calendar from a contract template, and we hit every single one of them on time. The game shipped in a state that nobody was proud of. The milestones were there; the honest evaluation wasn’t.
The Standard Milestone Gates, Explained
The game industry doesn’t have one universal standard, but there’s a common structure that most AAA studios and publishers recognize. Indie teams adapt it. Work-for-hire studios live by it. Here’s how it usually works:
Concept / Pitch
This is pre-production’s starting gun. You deliver a vision document, sometimes a playable proof of concept, and a high-level budget estimate. The real question: is this idea worth investing development resources in? The bar here isn’t polish. It’s convincing yourself and whoever controls the budget that this deserves serious pursuit.
Prototype
Often the most undervalued milestone in the entire pipeline. A working prototype doesn’t mean a press-ready demo. It means you’ve proven the core mechanic can exist in playable form. This is where your assumptions get tested for the first time, and many of them will be wrong. Teams that skip or rush prototyping pay for it hard during production.
Pre-Production Complete / Greenlight
This is the gate separating pre-production from full production. You walk in with a platform list, a feature set, a scope that matches your budget, a production schedule you actually believe in, and a vertical slice showing your game’s core experience at something close to target quality. A vertical slice is one small piece done well, not a trailer-friendly moment you’ll never replicate.
Publishers often hold back significant funding until greenlight. That’s intentional. It forces teams to commit to a real plan instead of guessing.
Alpha
Alpha means all features are in, even if they’re rough. Content may be missing or placeholder. The structure exists and you can play through it. The question: does everything we said we’d build actually exist in playable form?
Teams lie to themselves here constantly. They’ll call something alpha because the calendar says so, when really a third of the planned features still aren’t implemented. Don’t do this. A false alpha just compresses your beta and crushes your team during crunch.
Beta
Beta is content-complete. All levels are in, all features are tuned, assets are final or close. You’re now testing for bugs, not design changes. Ideally, design lock happens before beta. Feature creep that sneaks in during beta is the single fastest way to blow your ship date.
Gold / Submission / Release Candidate
End of the road for platform submissions. The build is bug-free enough to pass certification. For console, that’s Sony, Microsoft, or Nintendo’s TRC/TCR checklists. For PC, your bar’s different but your responsibility to players isn’t.
Then you ship.
Why Teams Get This Wrong
Jobs in Game Development [Team Management] · Masahiro Sakurai on Creating Games on YouTube
The gap between what milestones should do and what they actually do comes down to a few honest problems.
First, the definitions drift. Every studio, publisher, and lead has a slightly different understanding of what “alpha” means. I’ve been in rooms where two senior producers argued for twenty minutes about whether a game was in alpha or beta. Define your milestone criteria at the start of pre-production, in writing, and get everyone to sign off. Sounds bureaucratic. Saves months.
Second, milestones become pass/fail events instead of conversations. A missed milestone shouldn’t be a crisis. It’s data. You need to know why, whether the plan needs to change, and what’s going to be different next time. That milestone review meeting is probably the most important recurring conversation a production team has. It’s also often the one that gets handled worst.
Third, and this one stings: sometimes the people reviewing milestones have incentives that don’t align with honest assessment. Publishers want projects moving forward to protect their investment. Studio executives want to reassure their board. Leads don’t want to be the person who called the red flag. Result: everyone in the room knows the milestone wasn’t really met, but agrees to move on anyway. I’ve seen it happen at studios with hundreds of people.
Using a tool like Jira, Shortcut (formerly Clubhouse), or Hack n Plan (built specifically for game dev) to track your milestone criteria gives you a fighting chance at honest reporting. Data’s harder to spin than a verbal check-in.
Pre-Production Deserves Way More Time Than You’re Giving It
This could be its own article. Since milestones frame pre-production, I’ll say it here.
Most indie and mid-tier teams massively underinvest in pre-production. They want to get to making the game. The prototype felt great. The temptation to just start building is enormous, and “we’ll figure it out as we go” sounds agile but it’s usually just avoidance.
Pre-production should last long enough to answer every major unknown. What’s your core loop? Does it actually feel good? What’s the art style at scale? What’s the technical risk? Where are the systems that might not work?
The vertical slice is your best tool here, and it’s worth doing properly. Pick one representative section and build it to as close to shipping quality as you can. Not a scripted demo. An actual playable section where design, art, and code all coexist and work. The problems that surface here are the exact ones that’ll eat your production if you don’t catch them early.
Obsidian Entertainment’s talked openly about this tension in interviews and documentaries about their projects. They push for ambitious scope while committing to something achievable. That tension is real for everyone, no matter the team size.
Tools and Resources Worth Having in Your Corner
If you’re a producer trying to build a milestone system that actually functions, a few things help.
For project management, Hack n Plan was built by game developers for game developers and handles game dev workflows better than Jira does out of the box. That said, most mid-to-large studios use Jira with a well-configured setup, and knowing it matters for your career.
For production knowledge, “The Game Production Handbook” by Heather Maxwell Chandler is the closest thing to an industry textbook. Get the third edition. If you want something more honest about the chaos of actual development, Jason Schreier’s “Blood, Sweat, and Pixels” covers what goes wrong and why milestones matter.
Coursera and LinkedIn Learning both have game production courses worth taking if you’re newer to the role. Look specifically for anything taught by someone who shipped a game, not someone who studied production management academically.
The thing about milestones: they only work if everyone agrees to be honest inside them. The structure is easy. A spreadsheet, a checklist, a date. The hard part is building a team culture where calling a red flag early is safer than pretending everything’s fine.
That’s not really about production methodology. It’s about what kind of environment you’re creating. The best milestone system in the world fails when the humans using it are afraid to tell the truth.
