Running Playtests for a 200-Person Dev Team

How I own playtest production on an unannounced title: from build readiness and blocker triage to hosting sessions attended by everyone from engine programmers to EA's most senior executives. Project details are withheld under NDA; this is about the process.

01Context

Playtests were just being stood up when I was brought in. The lead producer and Dev Directors set a mandate: QV would own the sessions, and they would be mandatory for the entire team, designers, leads, and software engineers alike, so that every discipline actually plays major new features during development.

The reasoning is simple and very production-minded: 200 pairs of eyes spot issues earlier than any QA team alone, and the people building the game backend, engine and script work included, often have no other way to experience what they're shipping. Sessions run daily, with the audience ranging from the dev team to General Managers and VPs.

02What I Own

My pod covers a significant portion of the game, and I run its playtest sessions twice a week end-to-end. On the remaining days I co-run and support sessions led by other QV designers. Owning a session means owning everything that can go wrong before 200 people show up:

• Build readiness. Selecting the build candidate, running smoke passes, and confirming our slice of the game holds up before anyone else touches it.
• Blocker triage. When the build isn't ready: logging issues, assigning them to the owning dev, and chasing the fix so it lands before the next event.
• Running the room. Hosting and moderating the team-wide Zoom sessions, distributing roles (like server hosting) across a small QV team, and troubleshooting so every dev can connect and play.
• Risk escalation. My lead producer sits a desk away, and I keep that line hot: flagging blockers that threaten future sprints or UXR studies, and calling out when features moving through my pod are ready for playtest and UXR inclusion.

The lead producer and Senior Game Designer Lead decide what each event focuses on and what each pod owns per sprint. My job is to make sure that when the session starts, the plan survives contact with the build.

03A Session's Lifecycle

04Results

The clearest win is speed of discovery outside QV's expertise. With software engineers, designers, and audio in the same session, issues surface that QV alone would have found later or not at all, and they route fast: participants request tickets or flag us live, and we get the bug to the dev who'll own the fix.

The second win is risk visibility ahead of milestones. As UXR studies and sub-milestones approach, consistent problem patterns become a production conversation: I bring the evidence to the Dev Directors and producers, explain what's failing and why, and we decide together whether a feature stays active in the study build.

05What I Learned

The night before our first UXR event, we caught a major feature issue that should have been found a week earlier. I stayed late with our Dev Director and Senior Game Designer to get a fix through that night, then smoked the build before they left for the airport. The event ran; the process behind it clearly hadn't.