Use when an org role acts as studio producer and must own scope, schedule and capacity for a creative or game production from pitch to shippable build. Covers trading off scope vs schedule vs capacity, look-ahead risk, just-in-time cuts and milestone tracking. For tooling and vendor ops see studio-operations.
Installs into .claude/skills of the current project.
Are you the author of Studio Producer?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/monoes-studio-producer)
---
name: studio-producer
description: "Use when an org role acts as studio producer and must own scope, schedule and capacity for a creative or game production from pitch to shippable build. Covers trading off scope vs schedule vs capacity, look-ahead risk, just-in-time cuts and milestone tracking. For tooling and vendor ops see studio-operations."
tags: ["leadership","operations","game-dev","planning"]
tools: []
license: Apache-2.0
source: https://github.com/monoes/monomind
---
# Studio Producer — Best Practices
## Focus
Owns scope, schedule, and capacity for a creative/game production — the person who keeps a project moving from pitch to shippable build without burning the team out.
## Best practices
- Track three levers, not one: scope, schedule, and capacity. When one slips, decide explicitly which of the other two absorbs it — never let all three silently degrade.
- Look 2-3 sprints ahead for risk, not just at the current sprint. Milestones slip because of problems visible weeks earlier that nobody named out loud.
- Make cut decisions just-in-time, not up front. Lock scope only as late as quality of information allows; protect flexibility for as long as it's cheap.
- Keep a single visible source of truth for milestones and owners (board, doc) — cross-discipline teams (design/eng/art/audio) drift apart without one.
- Timebox risk-heavy unknowns as spikes with a hard decision date, so ambiguity doesn't quietly eat the whole schedule.
- Protect crunch as a last resort, not a plan — a schedule that only works if everyone works overtime is not a schedule.
- Close every milestone with a retro that changes something in the next milestone's plan, not just a status report.
## Common pitfalls
- Treating the schedule as fixed and scope as the release valve, when scope cuts are usually cheaper and less risky than schedule slips.
- Reporting "on track" from vibes instead of from a burndown against actual remaining scope.
- Letting a discipline (art, audio, design) work in isolation until integration, discovering conflicts only at milestone review.
- Overloading the schedule with optional polish before core loop / critical path features are proven.
## Tools & techniques
- Milestone/sprint boards (Jira, Trello, ClickUp, Shotgrid) with owner + due date on every card, not just epics.
- Risk register reviewed weekly: top 3 risks, likelihood, and the specific mitigation in progress.
- Vertical slice / playable-first milestones to validate the core loop before scaling content.
- Explicit descope list maintained alongside the roadmap — the pre-agreed cuts if time runs short.