Running a short marketing retro

1. Set a narrow review boundary

A marketing retrospective examines how work happened, not just whether the campaign performed. A weekly performance review might decide where to adjust spend. A retro asks why the landing page reached approval late, what helped the launch stay accurate, and which working rule should change.

Choose one completed campaign, launch or fortnight of comparable delivery. State the intended outcome and the boundary: from approved brief to publication, for example. Invite people who handled those steps, including the person receiving the handoff. Keep the group small enough that everyone can contribute.

Hypothetical example: an email promotion launched on time but required evening corrections. Review the promotion workflow, not the entire email strategy. Commercial success does not make avoidable rework harmless; disappointing sales do not prove the delivery process failed.

• Name the work, review dates and original delivery commitment.
• Identify the decision this retro can make without further approval.
• Park unrelated strategy questions for a separate discussion.

2. Prepare evidence, not a presentation

Ask one organiser to assemble a single-page timeline before the meeting. Include brief approval, first draft, feedback, final approval and release. Link to existing records rather than asking everyone to reconstruct their week. Mark missing timestamps as unknown.

Separate observations from explanations. ‘Copy received three rounds of feedback’ is observable. ‘The reviewer was indecisive’ is an interpretation. Include scope changes, blocked time and constraints such as a late price decision.

Keep delivery evidence separate from campaign results. Google distinguishes GA4 key events from Google Ads conversions; do not put both under an unexplained ‘conversions’ heading. Record the source, definition and reporting window before discussing differences. A measurement mismatch should become a tracking task, not an argument about team competence.

• Bring one successful handoff and one difficult handoff.
• Record original scope alongside what actually shipped.
• Include defects or corrections discovered after publication.

3. Run a 30-minute agenda with silent input

Send the scope and evidence beforehand. Open with a clear rule: examine decisions using the information available at the time, rather than judging them only through the outcome. The facilitator should interrupt personal accusations and ask for the missing process detail.

Use silent writing before discussion so the first senior opinion does not set the entire agenda. Ask each participant to name one thing to preserve and one source of friction, with a specific example. Group observations by workflow stage, not by person.

If a sensitive conflict emerges, acknowledge it and arrange appropriate follow-up. A short group retro is not a substitute for a confidential management conversation.

• Minutes 0–3: confirm scope and review the previous action.
• Minutes 3–7: write observations silently.
• Minutes 7–15: compare evidence and identify patterns.
• Minutes 15–23: investigate one recurring constraint.
• Minutes 23–30: agree an experiment, owner and review date.

4. Investigate the mechanism, not the nearest person

Choose a friction point with repeated cost or meaningful delivery risk. Walk backwards through the actual handoff: what was requested, what information was available, who could decide, and what happened next? Stop when you reach a condition the team can change.

Hypothetical example: paid social assets waited two days for approval. The reviewer was available, but the request contained six files without placement labels or a confirmed offer. ‘Approve faster’ misses the mechanism. A complete approval packet might address it.

Do not force every problem into a single root cause. Late offer confirmation and unclear approval authority can coexist. Distinguish the immediate repair from the structural change, and avoid adding a checklist when the real constraint is decision-making authority.

• What exactly was missing when work stopped?
• Was the decision owner known and authorised?
• Would the proposed change prevent recurrence or merely move the queue?

5. Choose one improvement and expose its tradeoff

Rank candidate changes by recurrence, avoidable effort, implementation cost and risk. Voting can reveal shared frustration, but popularity alone should not determine the action. A rare incorrect pricing claim may deserve attention before a frequent minor inconvenience.

Prefer one change the team can trial before the next retro. Define what will stop as well as what will start. Otherwise, improvements accumulate as extra administration.

Hypothetical example: consolidate creative feedback into one named reviewer’s response. The tradeoff is that this reviewer now needs time to resolve conflicting comments before sending them. Preserve specialist sign-off where required; consolidation must not silently remove legal, accessibility or brand checks.

• State the proposed working rule in one sentence.
• Name the workload or delay it could introduce elsewhere.
• Keep useful existing practices rather than redesigning everything.

6. Turn the decision into a testable action

An action such as ‘improve briefs’ cannot be meaningfully closed. Write the change, owner, trial boundary, evidence and decision date together. The owner is accountable for running the trial, not personally completing every dependency.

Hypothetical action: ‘For the next two landing pages, the campaign lead will confirm the offer, audience, supporting evidence and approver before design starts. Record clarification requests and any rework caused by missing information. Review after the second publication.’

Set a guardrail as well as a success signal. Fewer clarification requests are not progress if designers stop raising legitimate concerns. Check output accuracy and unresolved questions alongside speed. When volume is low, extend the trial rather than treating one smooth task as proof.

• Owner and collaborators.
• Start condition and trial end.
• Expected change and quality guardrail.
• Review date and keep, adjust or stop decision.

7. Measure efficiency without confusing speed with value

Track active effort separately from elapsed delivery time. A task can take 90 minutes of work across four days because it sits in approval. Useful measures include active minutes per comparable deliverable, elapsed time from ready-to-start to approval, revision rounds and post-publication defects.

Count the cost of the improvement. Hypothetically, four people attending a 30-minute retro use two person-hours. Adding 30 minutes of preparation brings the cost to 2.5 hours. If ten comparable tasks each require 20 fewer active minutes, the gross reduction is 200 minutes. Subtracting 150 minutes leaves 50 minutes of estimated net capacity, before implementation costs.

That is not guaranteed savings or cash recovered. Compare similar work, note scope differences and report the number of tasks observed. Period comparisons cannot establish that the retro caused either faster delivery or better revenue.

If the improvement hypothesis concerns advertising performance, consider a suitable Google Ads experiment rather than presenting a before-and-after result as causal proof.

8. Keep the decision beside the work

Store a short decision record where the next owner will find it: observation, supporting evidence, trial rule, owner and review date. Keep sensitive personnel details out of shared task notes. Link the record to the affected brief or approval workflow rather than creating a separate retrospective archive nobody checks.

Its product scope describes RiseProjects for tasks, owners, due dates and workload; RiseChat for work-related discussion; and RiseInsights for source-labelled reporting and period comparisons. These do not make a retro automatic or establish causation.

See RiseProjects, RiseChat and RiseInsights, or the connected workflow at /the-solution. Connected evidence depends on provider access, permissions and source availability. TikTok Ads and LinkedIn integrations remain approval pending. Verify availability before making a workflow dependent on them.

9. Start the next retro with the previous decision

Before collecting new problems, ask whether the last trial happened. If it did not, identify the blocker rather than declaring the idea ineffective. If it ran, review the agreed evidence and decide whether to keep, adjust or stop the rule.

Hypothetical example: a new approval packet reduces missing-file questions but takes the producer longer to assemble. Keep it only if the overall effort and quality tradeoff is worthwhile. A template or narrower packet may be better than either abandoning the idea or imposing it everywhere.

A useful retro leaves a small visible change, not a large list of aspirations. Cancel or shorten a session when there is no completed work or trial evidence to inspect.

• Did the change run as agreed?
• What improved, worsened or remained uncertain?
• Who will update the working template or remove the failed rule?