I suspect we’ve all been there. Sitting in a content, feature, or system review that’s going south, even though the work is good.
That, for lack of a better word… sucks. It’s easy to want to just write it off as “it wasn’t ready to show”. Which, I get, but I’ve found a lot of times, that’s not actually the issue. The work, itself, is fine - demonstrable, functioning, at quality, but… despite that, the folks in the room can’t decide to move forward, iterate, or rework. Because a lot of the decision makers, stake holders, or whatever you want to call them… They’re all evaluating through different lenses and agendas.
One person is looking at whether the direction is strong enough. Someone else is looking at whether the work is polished enough to show outside the team. A discipline lead is thinking about feasibility. A stakeholder is reacting to deliverability confidence. Production is trying to understand whether the milestone or deliverable can close.
Same content (or build). Different standards.
The problem, really, is a lack of clarity on what “done” actually means for any given situation. The team thought “done” meant one thing. Leadership thought it meant another.
Or, unfortunately, leadership had not made the meaning of “done” concrete enough for anyone to test. So the team did what good teams do: they filled in the gaps with their own judgment.
Sometimes that works, I’ve seen it happen. But… Most times it turns the review into the first moment where the real definition of done gets negotiated.
And that is a real expensive time to have that conversation.
“Done” is not just a status
In a lot of creative work, we talk about done as if it is a neutral state. The thing is either done or not done.
That works well enough for simple tasks. It does not hold up as cleanly for creative deliverables that exist to support a decision. And, I know for a lot of passionate creative folks, there’s a secondary issue that nothing is ever actually ‘done’. There’s always more that could be polished… But, at the end of the day, we gotta ship. So, aligning on what “shippable” means is pretty critical, and it varies based on a lot of factors.
A concept deck can be done enough to choose a direction, but nowhere near done enough to sell the work to a client. A prototype can be done enough to test a risk, but too rough to build stakeholder confidence. A trailer cut can be done enough to judge structure, but not sound, pacing, audience clarity, or final tone.
None of those are contradictions; they’re just different views. We run into problems when we do not say which view we’re using.
That is why I think “definition of done” is more useful than it sounds. I know the phrase can feel a little process-heavy. It has the vibe of someone trying to solve creative judgment with check boxes on a form, which… no thanks.
A checklist isn’t really useful for this kind of thing anyway - it’s more about leadership alignment and agreement about what the work for any given deliverable needs to accomplish.
Does it allow us to choose a direction? Or is the deliverable in a good enough state for handoff? Will it let production do a deep dive on planning? Can a stakeholder approve the next phase?
You get it. That list could go on forever. Really, behind all of that, is just knowing what done is meant to prove, solve, or answer - and that will help you define what done looks like.
A definition of done should tell the team what decision the work is here to support.
The review is often where an earlier problem becomes visible
Unfortunately, if we don’t do the hard work ot align on all that early, it tends to explode in reviews. Which, makes sense, we’re seeing actually delivered work, usually in some context of the larger project, and it’s where earlier ambiguity finally becomes visible.
The team did their best, often thinking and believing they were delivering what was asked. But, ultimately, the ask was unclear. They didn’t, really, know what they were aiming for. Or they knew, but only in broad language. “Make it polished.” “Get it ready.” “Show the direction.” “Prove the experience.”
What’s frustrating is that those phrases feel clear in the moment because everyone can nod along to them. Everyone knows what they mean, but through their own personal lens. So “make it polished” to a designer is very different than an artist.
It’s one of the reasons this is so important - and so challenging. People leave the same conversation with different assignments in their heads.
Making things worse - if the team is experienced, they may not even notice the gap right away. They will make smart assumptions on past patterns. They’ll try to protect the work from risks they know leadership usually cares about.
That can look like ownership (and to a degree it is), but when too much of the standard lives in assumption, ownership turns into guessing. Which is an express ticket to frustration all around.
Where I learned to distrust the word “ready”
I learned a lot of this in game development, especially around milestone builds and demos.
A team might say, “We need a vertical slice.” For people outside games, a vertical slice is usually a small, polished piece of the larger experience. Ideally, it shows what the finished thing could feel like. Sort of a combination demo and proof-of-concept.
It can also be a vector for misdirection and misunderstanding, because a vertical slice does several different jobs.
It needs to prove that the core player experience works. It needs to show the visual target. It might need to convince an executive group or publishing partner that the project deserves more investment. It might need to expose whether the team can actually build the thing at scale.
Sure, when viewed as a “vertical slice”, all those are close enough to sound like one goal in a meeting. They are different enough to create very different work.
So if the agreement is only “we need a vertical slice,” the team may still be missing the agreement that matters - on a lot of facets.
What really needs to be clarified is: What things does this slice need to prove?
That question travels well outside games. An agency concept presentation, an internal brand direction, a product prototype, an animation test, a campaign treatment, a rough cut… the artifact name changes, but the leadership problem is familiar.
The team is not just making a thing, they’re making something that has to support or enable a decision and, ideally, show some demonstrable progress.
If leadership does not define that decision or what progress looks and feels like, the team will still build toward what they think is being asked. It just may not be the same thing everyone else had in mind.
“Done enough” is often the more honest standard
The word “done” can also create trouble because it sounds final.
Creative work rarely moves that cleanly. A deliverable can be complete for one purpose and unfinished for another. That does not make the work sloppy. It means the team is moving through decisions in sequence. Also, as I touched on above, creative folks are passionate, driven, and want their work as perfect as it can be.
So - I find “done enough to decide” more useful.
Examples: A concept pass is done enough when leadership can choose what to develop next. A risk prototype is done enough when it has exposed the risk honestly. A stakeholder review is done enough when the right people can make the next commitment with eyes open.
That phrasing protects the team from two bad options.
One option is pretending the work is final when everyone knows it is not. The other is keeping everything open because some part of the work could still be improved.
Creative teams can lose a lot of time in that second state. There is always another improvement available, another concern worth considering, and always a smart person with a valid concern.
At some point, the leadership question becomes: does this concern affect the decision this work is here to support?
If yes, deal with it.
If no, capture it somewhere and keep moving. And, yes, the capture part is important, and in my experience, gets overlooked. Often getting buried in meeting notes that no one ever looks at again. So, make sure there’s a clear process for capturing these things. This is critical because good feedback often arrives at inconvenient times, a valid concern can still be out of scope for the current pass (I see this one a lot), and a good idea can still be too late for the decision in front of the team.
That is one of the less glamorous parts of creative leadership: protecting the work from useful input that belongs somewhere else.
The part leaders avoid
The hardest part of defining done is usually not writing the definition. It’s actually, for really realz, committing to it.
A clear definition of done forces leadership to say what matters now, what does not matter yet, and what tradeoffs the team is allowed to make. That can feel uncomfortable because it reduces optionality. Once the standard is visible, leadership can be wrong.
Keeping things vague feels safer. Particularly when you’re in more of a concepting, prototyping, or exploratory phase where the whole point is to learn what the work wants to become.
But even exploration needs a boundary.
“Explore until it feels right” is usually too vague to guide a team for long. A more useful version might be: “Get two or three directions with clear tradeoffs, and we can decide which risk we want to carry forward.”
Still flexible. Much clearer. Granted, you may realize those two or three directions are terrible and you need to revisit, but that’s then a strategic decision, not something that magically happens.
At any rate, the point is not to eliminate creative discovery, but to stop making the team absorb ambiguity that leadership could have (and, honestly, should have) clarified.
I know from experience. I’ve made that mistake. I have walked out of meetings thinking I had given clear direction or goals, then realized later that I had mostly given clear intent. Intent helps. It is not always enough.
The team also needs to know what the next decision is, and what kind of evidence will help make it.
A practical way to start
I would not introduce this as a big new process. If you do that, you’ll hate it, the team will hate it, your stakeholders will probably hate it, and it will fall apart.
Instead, start with one recurring pain point. Look for a review that keeps going off the rails, or deliverables where the team keeps doing strong work and still ends up back in the same conversations, iterating endlessly, or reopening previous decisions without solid reasoning.
Then, before the next pass starts, get the right leads aligned on one question:
What decision does this work need to make possible or answers does it need to provide? You’ll probably need to stay there longer than feels necessary (or comfortable at first).
That question usually reveals where the gaps and misalignment are hiding. Someone will think the work is meant to secure approval, but then someone else will think it is meant to compare options. Then, you’ll find someone who thinks it’s meant to pressure-test feasibility.
This is all good. Resolving that disagreement is much cheaper before the team starts building.
Then, once the decision is clear, the definition of done can be plain language.
For example:
“This pass is done when we can choose one direction to develop, understand the main production risks, and agree on what we are deliberately not solving yet.”
I would probably say it less stiffly in an actual meeting. But that is the basic shape.
It gives the team a target. It gives reviewers a standard, and it gives leadership a way to say, “That is a fair concern, but it is not what this pass is here to answer.”
That sentence, used well, can save a lot of churn.
Of course, used badly, it can become a shield against feedback. So it requires judgment. If someone raises a concern that changes the decision, you should probably stop and deal with it. If someone raises a concern that belongs to a later decision, you should probably protect the current one.
There is no formula that handles that for you, which is why it’s often hard work.
When the target moves
And here’s the messy reality. Sometimes the definition of done changes.
The first pass can reveal something you did not understand. Sometimes a stakeholder reacts differently than expected. I’ve also seen a technical constraint suddenly go from hypothetical to real, or a whole new constraint is discovered. The work, itself, makes it clear that the original bar was wrong.
That is normal. The mistake, though, is pretending the target did not move.
In my experience, teams can handle change better than we sometimes assume. What wears people down is silent change and assumptions. Leadership sees the work, updates the standard internally, and gives feedback from that new standard as if it had been obvious all along.
That can kill the psychological safety of your team.
If the definition changes, own it. Name it. Tell the team what changed, why it changed, and what no longer applies. Be direct about the tradeoff. You do not need a grand ceremony for this. You just need to make the new agreement visible.
That kind of reset is much healthier than letting everyone continue under yesterday’s assumption while leadership grades against today’s concern.
What this gives the team
A useful definition of done does not make creative work less subjective; instead, it gives the subjectivity a job.
The team still needs taste, judgment, instinct, craft, technical creativity, and debate. All of that stays. What changes is that the debate has a clearer relationship to the decision in front of the team.
Are we debating this because it affects the next decision…
… Or are we debating it because it is visible, interesting, or someone has a strong opinion?
It’s an important distinction. A lot of creative churn comes from treating every visible issue as a current issue. Good teams can survive that for a while, but it burns energy. It makes reviews feel heavier than they need to be. It teaches people to either defend everything or wait for leadership to reveal the standard after the fact.
None of that is great.
When “done” is defined well enough, the team gets a better target and leadership carries more of the decision. That feels like the healthier split.
The work will still be messy, and there will still be judgment calls. People will still disagree. Some reviews will still be uncomfortable.
But at least the team is not spending its best thinking trying to reverse-engineer what “ready” was supposed to mean.
Shawn Ketcherside has spent 25+ years in game production and creative leadership, and is now building tools for leaders of creative teams. You can find him on LinkedIn.