In my experience, I (usually) don’t see milestones get tanked from one or two huge, absurd, or ridiculous asks. I mean, yes, scope creep like that exists - but in most cases, something like that typically triggers a reset of a milestone or deliverable. The real problem is the reasonable, seemingly innocuous requests that hide within the scope. That’s exactly what makes them hard to manage, and why it’s so critical to manage them when you’re working with a co-dev partner. At least, if you want them to be successful.
Take an ask like this: Can we improve combat readability?
I’d be careful dismissing that as scope creep, particularly if combat is part of the milestone. It might be the exact right question or feedback. It’s also the kind of thing that’s hard to see until a build can be played, and harder to solve without knowing what’s actually broken.
So the co-dev studio says yes.
Of course they do. They want to be a good partner. They probably agree with the feedback — chances are they already saw the problem. And in that moment, the ask still feels close enough to the milestone that nobody wants to make a formal thing out of it/
Then the work starts. And so does the pain.
As they start “responding to the feedback”- mid-milestone - “Improve readability” turns out to mean adjusting animation timing and VFX. Then, that uncovers that enemy silhouettes need more clarity. So, they fix that, and attention shifts to camera distance, encounter layout, tuning, lighting, UI support, audio cues… (and tigers, oh my!)
The sneaky, infuriating thing is that this doesn’t happen all at once — that would at least allow for obvious, clear, plan changes. But, nope. It arrives one reasonable discovery at a time, coming in as an innocuous line in Slack or a fraction of an update in a meeting. Nobody did anything unreasonable. But the milestone shifted.
That’s what I mean by Iterative Drift. All those changes that look small, legitimate, and basically in scope — but the iteration required to satisfy them uncovers more work, more questions, and more decisions than the milestone was originally holding.
The problem isn’t the feedback or the ask. It’s the missing “why.”
As I’ve said, “Improve readability” is reasonable feedback. But… It is not enough context to make a good production decision.
Digging deeper, the actual core issue - Players missing attack animations, muddied VFX, and/or combat that’s simply too dense are three completely different problems with three completely different fixes. If the co-dev team only has the surface request, they can still do the work — it’ll just take longer and stands a much better chance of missing, because nobody equipped them with the detail they needed.
This cuts both ways. Co-dev studios sometimes under-ask for direction; I understand the pressure, because nobody wants to sound defensive or turn every note into a negotiation. And core teams — and by “sometimes” here I mean “most times” — under-communicate the reasoning behind the feedback in the first place.
The “why” is critical production information. The biggest impact usually isn’t in saying no. It’s in making the yes more informed.
The milestone changes before anyone calls it changed
Here’s the part that really bites: we rarely stop to acknowledge that the milestone has actually changed. And that gets easier to miss the more distributed the work is.
As an industry, we’re leaning harder into co-dev, and that makes the org chart of a single milestone genuinely complicated. The core team owns product direction. The co-dev studio owns a meaningful slice of implementation. Another partner owns art or UI or audio. And the feedback itself might come from a publisher, an exec group, or a creative director who wasn’t in the room when the milestone was shaped.
That can absolutely work. But it means the agreement now lives across a lot of people who each see a different slice through a different lens.
So even when Jira or Asana gets updated with the new tasks, the *reason* behind the change doesn’t. The decision trail lives in half-remembered conversations and buried Slack threads — which, I probably don’t need to tell you, isn’t great.
That’s not a swipe at anyone’s memory. Memory is just a bad place to store production agreements. People retain the part of a conversation that mattered most to the problem *they* were carrying. Then review day arrives, and the team isn’t just asking whether the milestone was delivered. They’re trying to reconstruct what “delivered” even came to mean.
A sharper question than “is this in scope?”
“Is this in scope?” isn’t a bad question. It’s just not always sharp enough. In game dev, a request can be technically in scope and still change the amount of iteration, risk, or review expectation enough to matter.
So here’s the question I’d add:
Does this change what the milestone is being asked to prove?
If no, keep moving. Don’t turn it into paperwork.
If yes, then for the love of all that is sweet and pure, make the decision visible. Using the running example, that might sound like: Yes, we can improve readability — but if the goal is player comprehension, there’s a simpler path than pushing this all the way to final presentation.”
That sentence is exactly the kind of thing co-dev teams should feel empowered to say more often. The combat note might be essential to proving the loop — great, do it. Or it might quietly move the milestone from “prove the loop works” to “show the loop at a higher presentation quality than we planned for this stage.” That may still be the right call. It just needs to be a call, not a drift.
The lightweight fix: a two-minute decision record
None of this requires a change-control ceremony. I know we, as production leaders, have enough of that kind of thing on our plates, we don’t need more. Besides, ceremony like that is the version of milestone discipline creative teams rightly hate — the one that treats the original plan like sacred text and turns every idea into a form to fill out. Iteration isn’t a nice-to-have in game development; it’s the job. A baseline that stops the work from changing is worse than useless.
The baseline isn’t a brake. It’s a reference point — the thing that tells you whether you’re iterating inside the milestone or changing it.
So when an ask or feedback clears the “does this change what we’re proving?” bar, I just capture three lines:
What changed: Pushing combat readability past comprehension toward presentation polish.
Why: Playtest review flagged players missing telegraphs; publisher wants it demo-ready.
What it now proves: Loop clarity and first-pass combat feel — up from loop clarity alone.
That’s it. Thirty seconds to a couple of minutes. It gives the next reviewer the context they’d otherwise be missing, it gives the partner studio a sharper target, and it gives you something better than memory when the milestone gets reviewed two weeks later.
The trigger for writing one is simple: if the change touches acceptance, test time, partner dependencies, review expectations, payment, or follow-on work, it’s earned three lines.
The takeaway
Iterative drift isn’t a failure of collaboration. It’s usually a side effect of collaboration moving faster than the record of what was agreed. The fix isn’t to make teams less responsive.
It’s to get precise about the one moment that matters: when a reasonable ask quietly becomes a changed commitment — and to write down the “why” while everyone still remembers it.
Author note: I’ve spent my career leading and supporting cross-discipline creative teams, primarily in game development, with a focus on production clarity, alignment, and communication. I’m currently building planning tools for creative leaders who need to turn ambiguous direction into execution plans their teams can actually use. You can connect with me on LinkedIn.