At Choco Media, we used to skip the retrospective. Not formally — we’d tell ourselves we’d circle back once the next project got underway — but in practice the debrief never happened. Projects ended, invoices went out, and whatever friction had built up quietly carried forward into the next engagement. The agency retrospective process we run today grew out of that failure. It takes about 45 minutes, uses four questions, and has genuinely changed how we work.
This post is for agency owners and project leads who want to build a consistent reflection habit without turning it into a bureaucratic ritual. If you run retainer clients, studio teams, or project-based work and you’re not doing structured post-project reviews, this is the operational change worth making first.
What you’ll leave with: the four questions we use, how we run the session, where we store the output, and — importantly — the changes we’ve actually shipped as a result of doing this regularly.
Why most agencies skip retrospectives (and what it costs them)
The honest reason agencies skip retrospectives is that they feel like they’re for teams that made mistakes. If a project went smoothly, what’s there to talk about? And if it went badly, the last thing anyone wants is a formal post-mortem that feels like an accusation.
That framing is the problem. A retrospective isn’t a debrief on what went wrong — it’s a structured way to extract what you actually learned from any project, good or bad. The projects that run well are often the most instructive, because they reveal what your process does right. The projects that had friction reveal where the system breaks.
- Without retrospectives, knowledge stays personal — it lives in one person’s head and leaves when they do
- Pattern recognition is slow — you might make the same onboarding mistake four times before connecting the dots
- Client relationship signals get missed — retrospectives surface things clients say in exit calls that don’t make it into the project file
- The same friction recurs — scope creep, unclear briefs, missed expectations — because nobody stops to identify root cause
In client work, we’ve found that the average agency takes two to three repetitions of a problem before they change the system that caused it. A consistent retrospective habit cuts that down significantly.
The four questions we ask
We arrived at four questions after trying longer formats that nobody filled in honestly and shorter ones that produced answers too vague to act on. These four generate specific, actionable answers about 80% of the time.
Question 1: What worked better than expected?
Start here. It primes the conversation for observation rather than judgment, and it surfaces the practices worth repeating and codifying. “Our intake call format meant we had the brief locked by day three” is a process insight worth documenting. “The client was great” is not — push for specificity.
Question 2: What created friction, and at which stage?
This is the diagnostic question. The key is pinning friction to a stage — discovery, briefing, production, review, delivery — rather than leaving it as a general complaint. “Feedback rounds took too long” is useful only when you also know whether the slowdown was in the brief (unclear scope), the review process (no defined stakeholder), or the delivery format (client wasn’t sure what to approve).
Question 3: What would we do differently on a similar project next time?
This is where pattern recognition happens. It’s deliberately forward-looking, which keeps the session from becoming a complaint forum. The constraint “on a similar project” matters — it stops the team from proposing changes that wouldn’t apply to the kind of work you actually do.
Question 4: Is there anything the client said (or didn’t say) that we should take seriously?
This question catches the signals that get lost between the project ending and the invoice going out. Exit comments, offhand feedback in the final call, the thing they praised that you almost cut — all of it lives here. It’s also where you note the things the client didn’t say: if nobody mentioned the strategy work, that’s worth knowing too.
The retrospective question we almost dropped — “what would we do differently?” — has generated more process changes than the other three combined. The fact that it’s hypothetical makes people more honest.
How we run the session
The session is 45 minutes, scheduled within five working days of final delivery. We don’t wait until the invoice is paid or the client gives a sign-off — by then the detail has faded.
The format is simple:
- 10 minutes: everyone writes their answers individually before the discussion starts. This prevents the loudest voice from setting the frame.
- 25 minutes: go through each question together. One person captures answers in the shared doc in real time.
- 10 minutes: identify one to three action items — specific, owned, and dated. If you can’t name who is responsible and by when, it’s not an action item.
We run this with whoever was directly involved in the project — usually two or three people. We don’t include the client; this is an internal session. If there’s client feedback to incorporate, it comes in through question four as captured observations, not live input.
For shorter projects (under four weeks), we use an async format: everyone fills in the four questions in a shared doc, then we have a 20-minute call to discuss anything interesting that emerged. The full session is worth it for longer engagements.
Where we document the output
Every retrospective lives in the same place: a running Notion document called “Project retrospectives,” with one entry per project, tagged by client, project type, and date. The format is deliberately minimal — the four questions, the answers, and the action items.
We don’t summarise or synthesise at the time of writing. That comes later, during a quarterly review of retrospective notes, where patterns across projects become visible. A single project’s feedback might not look like much; four projects with the same friction point in question two is a system problem worth fixing.
- Tag by project type (brand, paid media, content, website) so you can filter retrospectives for the type of project you’re about to start
- Tag by whether the project went well, average, or had significant friction — not for blame, but so you can quickly surface the instructive ones
- Link the retrospective to the project file so anyone picking up a similar brief in the future can read what the team learned
The documentation habit is more important than the format. A retrospective that lives in someone’s notes doesn’t compound. One that’s searchable and linked to the project record does.
The changes we’ve shipped because of this
This is the part that makes the habit worth maintaining. Here are four changes we made directly because retrospectives flagged the same issue more than twice.
We added a scope confirmation step to onboarding
Three separate retrospectives noted friction in the briefing stage — specifically, that the scope we thought we’d agreed on in the sales call didn’t match what the client expected when work started. We added a written scope confirmation to the onboarding call agenda. Scope disputes at delivery dropped significantly in the quarter after.
We shortened our review rounds from three to two by default
Question two kept surfacing that third-round feedback was usually minor and could have been caught in round two if the review instructions had been clearer. We rewrote our review request email to be more specific about what kind of feedback we needed and added a deadline. Two rounds became the norm, not the exception.
We started sending a project brief summary before kick-off, not after
A retrospective on a brand project surfaced that the client hadn’t fully understood the production sequence until we were already mid-project. We now send a one-page project summary — scope, milestones, what we need from the client and when — 48 hours before the kick-off call. The kick-off call is better because of it.
We changed how we handle feedback from quieter clients
Question four repeatedly flagged that clients who didn’t give much feedback during the project sometimes surfaced significant dissatisfaction at the end. We added a brief mid-project check-in for projects longer than six weeks — a two-question async message, not a full call. The early signals we get from that have prevented at least two difficult exit conversations.
What happens when retrospectives reveal a structural problem
Occasionally a retrospective surfaces something that can’t be fixed with a process tweak — a pricing model that creates misaligned incentives, a service offering that consistently produces friction, a client profile that doesn’t fit how we work. These are more uncomfortable findings, but they’re the most valuable ones.
We treat these differently. Minor friction gets an action item and a process change. Structural problems get escalated to a separate conversation about whether the offering or model needs to change, not just the execution. Our bespoke retainer model was partly shaped by retrospective feedback indicating that fixed-scope projects created adversarial dynamics at delivery — friction that had nothing to do with the quality of the work.
The willingness to act on structural findings is what separates agencies that use retrospectives to maintain the status quo from those that use them to improve the business model.
Retrospectives for retainer clients
Retainer engagements don’t have a natural endpoint, which makes retrospectives easy to skip. We run them quarterly instead — same four questions, applied to the last 90 days of the engagement.
The quarterly format has one addition: we include a fifth question — “is this retainer still the right scope and shape for where the client is now?” — which catches the drift that happens when a client’s needs evolve but the retainer scope doesn’t. We’ve had retainer clients for over a year whose engagements have been restructured twice because quarterly retrospectives caught the signal early.
- Schedule quarterly retainer retrospectives on a fixed cadence — don’t wait for something to go wrong
- Share a brief summary with the client after the internal session — it signals that you take the relationship seriously
- Use the cumulative notes to prepare for annual renewal conversations — you’ll have 12 months of documented evolution to draw from
Our guidance on how we use AI in client operations covers some of the tooling that supports this rhythm, including how we use AI to draft the retrospective summary before the session rather than after.
Getting the team to actually do it
The most common failure mode for agency retrospectives isn’t bad questions — it’s that the habit doesn’t stick. Projects end, the next one starts, and the retrospective gets pushed to next week indefinitely.
The two things that make the habit stick in our experience:
First, it has to be in the project plan. If the retrospective session isn’t on the calendar when the project kicks off, it won’t happen. We add it to the project timeline on day one, usually five working days after the planned final delivery date.
Second, the facilitator role has to be explicit. In a two-person agency, it’s still worth naming who will run the session. Without a named facilitator, the session becomes a conversation that wanders. With one, it stays on the four questions and produces outputs.
For what it’s worth, the 45-minute format makes it easy to protect. We’ve found it harder to skip a 45-minute session than a 90-minute one — the time cost is low enough that there’s no good excuse, which removes most of the friction.
Starting this week
If you haven’t run a retrospective on your last three projects, the most useful thing you can do right now is pick the most recent one and schedule 45 minutes. Use the four questions above. Write the answers individually before you discuss. Identify one action item you’ll implement before the next project of the same type starts.
You don’t need a formal system in place before you begin. The system comes from doing it a few times and noticing what format works for your team. What matters is the first session — because retrospectives compound, and the agency that runs them consistently is the one that stops making the same mistakes.
If you’re thinking about how to build this kind of operational discipline into your agency structure, our contact page is the right place to start that conversation.