The framework · Title Review
Is this game worth delivering?
A healthy team can ship the wrong game.
Studio Assessment asks whether a team can deliver. Whether the game is worth delivering is a separate question, and each can fail without the other. A Title Review is an independent read on the game itself: its core, its audience, its scope and its business model.
What a review answers
- Has the core of the game been proven, or only asserted?
- Are the plan and the content it requires the same size?
- Which patterns are present, and is it still early enough to correct them?
- What is working, and should be protected?
Good milestones, failed launches
Milestone review is built to catch execution problems, and it catches them well. A title can pass every gate on schedule, on budget, and at quality, and still fail on the day it meets its audience. The questions that would have caught it are not necessarily questions about the team.
What a Title Review looks at
- Core: has the fun been demonstrated, or asserted?
- Vision: how far has the current game moved from the one that was funded?
- Audience: what are these players playing now, and why would they switch?
- Production math: does the remaining work fit the demonstrated rate?
- Model fit: do the design and the business model want the same things?
When a review is most useful
The same review supports four different decisions.
At a greenlight gate
A build review shows what the team prepared. A title review asks whether the game underneath it justifies the production budget that follows.
Before signing an external title
An independent read on the pitch itself, alongside the legal and financial diligence. The cheapest possible point to find an audience problem.
Portfolio review
Several titles assessed against the same framework, so the comparison between them means something.
When the model changes
A platform, pricing, or portfolio decision made above the project rewrites its business case. Someone has to re-open the question without it reading as the team's failure.
Five patterns that put the game at risk
A project can be well run, hit its milestones, and still have fundamental problems with the game. These five patterns indicate whether a title supports the investment required to finish it. As with teams, each is judged against stage: a prototype isn’t judged like a beta.
Unvalidated core
Production has moved ahead of evidence that the core game is working
Warning signs
- Significant content production has started before the core experience has been validated with players.
- Confidence in the game is based more on internal opinion than playtest or behavioral evidence.
- Weak engagement is repeatedly attributed to missing content, polish, progression, or features.
- The team has not defined what evidence would cause them to reconsider the core experience.
What this puts at risk
The team can spend months producing content around a core experience that has not been proven. As production advances, changing the fundamentals becomes increasingly expensive and disruptive.
What healthy looks like
First-time players choose to keep playing the core gameplay loop, and the team knows what evidence would lead it to reconsider its conclusions.
Vision drift
The game has changed, but the production plan and investment thesis haven’t
Warning signs
- Systems and features have accumulated without meaningful cuts elsewhere.
- Different parts of the team describe the game’s priorities differently.
- The original player experience is becoming harder to identify in the current build.
- Major additions have been made without revisiting scope, schedule, or audience assumptions.
What this puts at risk
The project becomes larger and more expensive while losing focus. Individual features may be defensible, but together they can result in a game that is harder to produce, harder to explain, and less distinctive.
What healthy looks like
Anyone on the team can describe the game in the same two sentences, and every major addition came with a cut or an updated plan.
Unproven audience thesis
The intended player is well defined, but the reason they will choose the game is not
Warning signs
- The audience is defined primarily by demographics or broad genre preferences.
- The team can describe the target player but has limited evidence that the game appeals to them.
- There is no clear answer to what players will stop playing, or spend less time playing, to make room for this game.
- Market assumptions made at greenlight have not been revisited as the game and competitive landscape have changed.
What this puts at risk
The team can build a competent game for an audience that has little reason to choose it. A large addressable market does not establish demand for a specific title.
What healthy looks like
The team can name what its players are playing now and why they’d switch, and has put the game in front of those players to check.
Production math doesn’t close
The remaining work does not fit the demonstrated production rate
Warning signs
- Content targets have not been tested against measured production velocity.
- The schedule assumes substantial improvements in throughput that have not yet been demonstrated.
- Recovery plans depend heavily on future hiring, outsourcing, reduced iteration, or increased efficiency.
- The amount of remaining work is growing faster than the team is closing it.
What this puts at risk
A milestone schedule can look reasonable while the total production plan does not. If the remaining work exceeds demonstrated capacity, something has to change: scope, schedule, cost, or quality.
What healthy looks like
Remaining work divided by measured velocity lands inside the schedule, with margin, without assuming hires or efficiency that haven’t happened yet.
Business model misalignment
The business model requires player behavior the game has not demonstrated
Warning signs
- Revenue assumptions depend on engagement or retention levels the current experience has not produced.
- The model requires a volume or cadence of content the team has not demonstrated it can sustain.
- Progression, retention, or monetization systems have been added without evidence that they strengthen the core experience.
- Financial assumptions depend on player behavior that has not been validated through testing or comparable titles.
What this puts at risk
The game may work as a product but not support the economics behind it. If the financial model requires more engagement, retention, or content than the game can reasonably generate, the investment assumptions need to be revisited.
What healthy looks like
The game already produces, at small scale, the player behavior the model depends on, and the content cadence it requires is one the team has demonstrated.
Finding one of these patterns does not determine the recommendation. The assessment looks at the severity of the problem, the evidence behind it, whether it can be corrected, and what that correction requires in scope, schedule, capital, or product direction.
How a Title Review reads a game
A short, structured read on a single title, scoped to the decision leadership is facing. It covers what the project has produced, what exists to play (with a structured playtest where possible), and conversations with the people making it. What “on track” means depends on stage, genre and studio, so every question is calibrated to all three.
Materials
Pitch and pillars, current plan and budget, milestone history, playtest and user research results, and the last two reviews where they exist.
Play
A structured playtest where possible, and time playing the build the way a player would, not the way a demo is guided. Where there’s no build yet, the review reads what stands in for it.
Assessment
Which patterns are present, whether it’s still early enough to correct them, and a recommendation framed for the decision at hand.
What the team gets out of it
A Title Review is not a verdict on the team. Often the hardest questions about a game are ones the team is already asking and can’t easily raise. An outside read gives those questions standing, separates a game problem from a team problem, and when the evidence is good, gives leadership a reason to back the team with confidence.
How a review runs
Three steps, sized to fit inside a normal review cycle.
Kickoff
Agree the decision being made and the questions that need answering. Materials are reviewed in advance: plan, budget, milestone history, research results, prior reviews.
Duration: 1-2 days
Review
Time with the build and with the team: play sessions, working conversations with leads and with people across the team, and a read of the production data against what the plan assumes.
Duration: 2-5 days, on-site or remote
Synthesis and recommendation
Which patterns are present, how far each has run, and what correcting them would take at this stage. Findings are shared with the team first. Then a written report with a recommendation of proceed, proceed with conditions, or pass, followed by a debrief.
Duration: 1 week
Total timeline: 1-3 weeks from kickoff to final report
Short enough to sit inside a review cycle, thorough enough to change a decision.
The report
- 1Executive summary: proceed / proceed with conditions / pass
- 2What’s working: the strengths worth protecting
- 3Pattern analysis: which of the five are present, and how far each has run
- 4Stage calibration: what should be true by now, and what isn’t
- 5Evidence: the playtest data, production rates and build observations behind each finding
- 6Recommendation: framed for the decision at hand, with what would have to change
The other half of the read
Title Review asks whether the game is worth delivering. It doesn’t ask whether this team can deliver it. Studio Assessment covers that question.
The question a milestone build can’t answer.
Greenlight, continue-or-stop and slate decisions all improve with an independent read on the title itself. If you’re building an independent review function, or wondering whether you should, I’d welcome the conversation. colin@cmackie.com