A Weekly Build Review Agenda That Catches Problems Early

A build review works when everyone plays the same build on a real device before discussing it, the agenda moves from blockers to progress to decisions, and every item ends with an owner and a date. Forty five minutes weekly is enough. Reviews that start with a demo instead of hands-on play produce impressions rather than findings.

Why this matters

The build review is the only recurring moment where the whole team looks at the actual game rather than at their part of it.

Done badly, it becomes a status meeting with a video. Done well, it is where problems surface a month before they would otherwise.

The difference is almost entirely structure.

Why unstructured reviews waste everyone's time

Three failures account for most of it.

The presenter drives. One person plays while everyone watches, which shows the build working rather than the build being used. Problems only appear when someone unfamiliar holds the phone.

Discussion outruns decisions. A long conversation about a feature ends with nobody assigned anything, and the same conversation happens next week.

Feedback arrives as taste. Without a structure, comments default to preference, which is unactionable and demoralising.

The output of a build review is a list of decisions with owners. Anything else is a conversation you could have had in writing.

The 45-minute agenda

Five segments, timed.

The silent play at the start is the part teams skip and the part that makes the rest work. Ten minutes of everyone using the current build on real hardware produces more findings than an hour of discussion.

Distribute the build at least a day ahead as well, so anyone who wants longer with it has the chance.

What to look at, in what order

Order matters, because attention is highest at the start.

1. Does it run. Cold launch, on the device floor, without a crash. If this fails, the review is about that.
2. The first sixty seconds. The part that decides retention, reviewed every single week even when it has not changed.
3. What changed this week. New work, in the order a player would encounter it.
4. The number that matters this milestone. Frame rate, build size, level count, whatever the current constraint is. One number, tracked weekly.
5. The oldest open decision. Anything unresolved for more than two weeks gets forced to a conclusion.

That last item prevents the slow accumulation of unanswered questions that quietly stalls projects, as described in Rescuing a Stalled Game Project.

How to give feedback that is actionable

Three rules, worth stating to the team once and enforcing gently.

Describe the experience, not the fix. "I could not tell what to tap first" is useful. "Make the button bigger" skips the diagnosis and is often wrong.

Separate observation from preference. "The timer is hard to read at arm's length" is an observation. "I do not like the timer" is a preference. Both are allowed; label which is which.

Attach a severity. Blocking, should fix, or nice to have. Without it, everything competes equally for the same week.

For anyone reviewing as the client rather than the maker, the fuller guidance is in How to Give Feedback on Game Builds.

Tracking decisions between reviews

A decision that is not written down will be made again.

Keep one document, in the same place every week, with four columns: the decision, who made it, the date, and the reason.

The reason column is the one people leave out and the one that pays. Six weeks later, someone will ask why the game works a particular way, and the answer being written down prevents relitigating it.

Two more habits.

• Read the actions aloud at the end, with owner and date. Two minutes, and it roughly doubles follow-through.
• Open the next review with the previous actions. Anything not done is either done today or explicitly dropped.

Who should be in the room

Small and consistent works best.

Whoever holds the design vision, a lead from each discipline actively working, and whoever owns the schedule. Plus the founder if the founder is the decision maker.

Anyone else attends when their work is on the agenda. A review with twelve people becomes a presentation, and presentations do not produce findings.

If the team spans time zones, record the play segment individually and hold the discussion in the overlap window, per How to Work With an Outsourced Team Across Five Time Zones.

What we would do

Start with the play segment, every week, without exception. It is the single change that converts a status meeting into a review.

Keep the same slot and the same length. Reviews that move around get skipped, and skipped reviews are how a month passes without anyone looking at the whole game.

Track one number per milestone and put it on screen every week. Teams respond to a visible trend far more than to a target mentioned once.

The short version

• Everyone plays the same build on a real device, in silence, for the first ten minutes.
• Five segments: play, blockers, walkthrough, decisions, actions.
• Review the first sixty seconds every week, whether or not it changed.
• Describe the experience rather than prescribing the fix, and attach a severity.
• Record every decision with its reason, and open the next review with the last actions.
• Keep the room small, the slot fixed, and one tracked number visible.

Run next week's review with the play segment first and see what surfaces. If you want a studio that runs this cadence with you, start a conversation.

Related reading: How to Give Feedback on Game Builds, Hiring Your First Game Producer, and Signs Your Game Project Is Off Track.