Purpose:
To ensure that internal stakeholders stay informed about where a project stands, what’s been accomplished, and what’s coming next—so teams can stay aligned and plan support accordingly.
What this means:
Developers are expected to communicate timeline updates either as needed or at minimum every 12 weeks during progress check-ins. These updates help the broader team understand current progress, what’s likely to happen in the next sprint, and whether adjustments in support, resources, or deadlines are needed.
Developers who are actively iterating or approaching major milestones may share updates more frequently with their internal project lead.
RACI Roles Defined:
- Accountable The developer is accountable for ensuring timeline updates are shared regularly and reflect reality—not assumptions or hopes.
- Responsible The developer provides status updates and estimated timelines for upcoming work.
- Consulted Internal project leads, Production, and Leadership are consulted to coordinate downstream tasks, align expectations, and identify risks.
Key Guidance:
- Every 12-week check-in must include a timeline discussion:
- What was just completed
- What’s coming next
- Where there are blockers or gaps
- Formal weekly updates are not needed —but when given should be clear, honest, and current.
- If your timeline shifts significantly, flag that to your project lead outside the regular meeting.
Action Items:
- Prepare a quick timeline snapshot before each 12-week progress meeting
- Update internal project leads directly if a major date, delivery, or decision shifts
- Document your next planned sprint or milestone and share it in the shared project file or Asana
Reminder: Clear timelines aren’t about pressure—they’re about visibility. If people don’t know what’s happening next, they can’t help you get there.
12-weekly Meetings Further Guidance:
Every 12 weeks, developers at AEG present the current best version of their game. These presentations may happen in front of a small group of directly involved stakeholders or the entire company—but the goal is always the same: strategic alignment.
These are not routine status updates. They are opportunities to:
- Show the most recent, most complete expression of the game
- Give the company visibility into progress
- Invite feedback while it can still shape the product
What’s shown should be thoughtfully selected and well-prepared. These meetings are meant to show, not tell—giving everyone a real glimpse of what the product is becoming, across gameplay, visuals, packaging, and experience.
When done well, these presentations lead to real improvements in the final game—because feedback is shared while there’s still time to act on it, not just after the fact.
This guide outlines the likely stages of product iteration to help developers plan what to build and what to show at each checkpoint.
NOTE: These are not “How much did you get done?” meetings. Developer work pace is self-managed and autonomous. The cadence exists to maintain visibility and momentum—not to evaluate velocity.
How Developers Can Show Progress
Every 12-week progress meeting is a chance to share the current best expression of your game, but that doesn’t always mean you need a fully rebuilt prototype. The goal is to give visibility into what’s evolved and where the energy has gone—whether that’s gameplay, visuals, production, or packaging.
Here are several valid and valuable ways to show progress:
Updated TTS/TTP Build
- Even if the physical prototype hasn’t changed, updating the digital version (e.g., adding art, refining components, adjusting layout) gives a clear window into development.
- Screen-sharing a TTS mod can be just as effective as passing around a box.
Vision Boards & Concept Previews
- Show curated images, sketches, component layouts, or cover art in progress.
- This is especially helpful when collaborating with artists or working toward packaging goals.
- Can be shared as a slide deck, Figma board, or physical printout.
Evolving Physical Prototype
- Bring in the latest physical prototype, even if only part of it is new.
- Additions or swaps—like new trays, tokens, rules inserts, or a different board layout—can spark meaningful discussion.
Rulebook & UX Updates
- Sometimes the biggest leap forward is clarity.
- Share updated rulebook drafts, setup guides, diagrams, or player aids to show improvements in usability.
Cover Art or Box Treatments
- Showing off a new box mockup or updated logo can communicate huge leaps in vision, even if gameplay hasn’t changed.
- Packaging is part of the product—let the company see it take shape.
Production Samples & White Boxes
- If the game has moved into pre-production, bring white samples, component proofs, or box mockups.
- Let others physically engage with the work if possible.
Structured Feedback or Playtest Summaries
- Show what’s been learned, even if the materials haven’t changed.
- Summaries of blind playtests or feedback from specific audiences show maturity and momentum.
The key is to make your progress visible and intentional. You don’t have to rebuild the whole game—just pick the most meaningful changes and present them clearly, so the company can support, align, and respond.
Editor Note - WE NEED TO -Build a checklist of benchmarks and questions for the 12 week check ins
- Is it RFQ time?
Inspiration Behind AEG’s 12-Week Progress Meetings
AEG’s 12-week product presentations are inspired by some of the most effective creative and development cultures in the world—including Pixar, Apple, and Agile product teams. Each of these models emphasizes showing real work, sharing it early, and inviting hard feedback while there’s still time to act on it.
Pixar: Honest Feedback Among Peers
At Pixar, in-progress films are regularly reviewed in sessions known internally as the Braintrust. These are not status updates or marketing pitches—they are unfiltered peer reviews, attended by other directors, writers, and creative leads. The goal is to get honest, actionable feedback on the version of the film that exists right now, not what it mightbecome.
Key elements of Pixar’s Braintrust model:
- Everyone sees the real current version—even if it’s messy or incomplete.
- Feedback is direct, candid, and focused on helping the story improve.
- There’s no hierarchy in the room during critique—only clarity, trust, and shared purpose.
- The creative lead receives feedback but owns the decisions that follow.
Pixar believes this approach works because creativity thrives on iteration, and truth told early is a gift. You don’t protect a fragile idea by hiding it—you strengthen it by testing it.
Apple: Best Version Reviews with High Standards
At Apple, teams didn’t report progress—they showed it. From iPods to iPhones, key stakeholders regularly reviewed physical or digital prototypes. These demos weren’t polished for show—they were intense internal critiques meant to push quality forward through sharp focus and relentless refinement.
Agile: Incremental Progress and Course Correction
Agile teams end every sprint with a review to demonstrate what was accomplished. It’s not just about showing success—it’s a built-in opportunity to gather feedback, resolve ambiguity, and adjust the plan if needed. The team stays aligned because progress is always visible.
What This Means for AEG
Your 12-week progress meetings aren’t just calendar events—they’re cultural rituals. They exist so that:
- Everyone at the company sees real, recent work
- Developers show—not just tell—where their game is
- Cross-functional insights can be incorporated early, not too late
- Hard truths and bold ideas have a place to be shared and tested
The goal is to create better games through shared visibility, early accountability, and a culture that values clarity over comfort.
