The Producer's
Co-Pilot

// the premise

The job is a loop, and half of it is mechanical

Strip a producer's week down and most of it is the same transformation performed over and over: a stakeholder gives you an ambiguous outcome, and you convert it into a sequence of dated, owned, costed, de-risked work — then you keep that conversion current as reality drifts away from the plan. The skilled part is the judgement: what's actually in scope, who can really do the work, which risk is the one that bites. The mechanical part is everything around it — restructuring a brain-dump into tasks, sequencing them, totting up a budget, rewriting the same status three ways for three audiences.

That mechanical half is exactly what a language model is good at, and it's the half that eats your hours. The trick is not "ask the AI to manage the project." It's to treat the model as a fast, tireless junior who drafts the artefact — the WBS, the Gantt, the budget table, the risk register, the status note — and to keep every decision that carries consequence on your side of the line. The model proposes; you dispose.

// where it fits

Six places AI earns its seat

Across a project's life there are six recurring artefacts where handing the first draft to a model reliably saves real time. None of them are the decision — they're the scaffolding the decision hangs on.

• 1 · scope → WBSTurn a freeform brief or kickoff transcript into a structured work breakdown — phases, deliverables, tasks — that you prune rather than build from a blank page.
• 2 · tasks → scheduleSequence tasks, infer dependencies, and produce a Gantt or timeline as data you can paste straight into a sheet or import into your PM tool.
• 3 · schedule → budgetRoll roles, rates and effort into a costed estimate with contingency, then flex it for the scenarios a client always asks for.
• 4 · resourcingSpot over-allocation, surface the weeks where two people are booked at 140%, and propose levelling options before they become a crisis.
• 5 · risk registerGenerate a first-pass register from the plan itself — the dependencies and assumptions are the risks — scored and with mitigations to react to.
• 6 · status & commsRewrite one set of facts into the three registers you actually need: a client update, an exec one-liner, and a team stand-up note.

// playbook 1

Brief → work breakdown

The blank WBS is the most expensive blank page in the job, because everything downstream inherits its structure. So this is the highest-leverage thing to hand over. The move is to give the model the raw brief (or a kickoff transcript) plus your house structure, and ask for a structured output you can manipulate — not prose.

The single biggest quality lever is making the model emit machine-readable data rather than a bulleted essay. Ask for a table or for delimited rows, and the same output drops into a sheet, a Gantt, or your PM tool with no retyping.

Role: You are a senior producer building a work breakdown.

Input: the brief below, plus our standard phases
  (Discovery, Design, Build, QA, Launch, Hypercare).

Task: Decompose into phase > deliverable > task.
For each task output a row:
  phase | deliverable | task | rough_effort_days | depends_on | owner_role

Rules:
- Effort is a rough order of magnitude, not a commitment.
- Mark anything you inferred (not stated in the brief) with [ASSUMED].
- List open questions separately at the end. Do not invent dates.
- Output as a pipe-delimited table and nothing else.

Brief:
"""<paste the messy brief or transcript here>"""

Two details do the heavy lifting. The [ASSUMED] tag forces the model to separate what you told it from what it filled in — those flags are your edit list. And "list open questions separately" turns the model's uncertainty into your kickoff agenda instead of into silently wrong tasks.

// playbook 2

Tasks → Gantt & timeline

Once tasks carry effort and dependencies, a schedule is mostly arithmetic over a calendar — the kind of thing that's tedious by hand and instant for a model, provided you give it the real constraints. Hand it your task rows, a start date, working-day assumptions and any hard milestones, and ask for dated output plus a visual.

Mermaid is the sweet spot for the visual: it's text, so the model can author it directly, it renders in most modern tools and on the cyber-wyse article pages, and it round-trips — you can hand a Mermaid chart back to the model and ask it to reflow after a slip.

Task: From the task rows below, build a schedule.

Constraints:
- Start 2026-06-15. Mon–Fri working days. UK bank holidays off.
- Respect every depends_on. Flag any circular dependency.
- Hard milestone: client review must land on/ before 2026-08-07.

Output two things:
  1) A table: task | start | end | duration_days | depends_on
  2) A Mermaid gantt chart of the same schedule.

If the milestone cannot be met, say so explicitly and show
the critical path that breaks it — do not silently compress tasks.

That last instruction is the one that separates a useful schedule from a dangerous one. Left to please you, a model will quietly shrink durations to hit the date you wanted. Telling it to refuse and show the critical path instead turns it from a yes-man into something closer to a scheduling engine that reports bad news — which is the only kind worth having.

gantt
  title Project Schedule
  dateFormat YYYY-MM-DD
  section Discovery
    Stakeholder interviews   :a1, 2026-06-15, 5d
    Requirements synthesis   :a2, after a1, 3d
  section Design
    Concept directions       :b1, after a2, 8d
    Client review            :milestone, after b1, 0d

// playbook 3

Schedule → budget & scenarios

A budget is the schedule seen through the lens of money: roles times rates times effort, plus contingency, plus the things that aren't labour. The model is excellent at the assembly and the re-runs — the part where a client asks "what if we drop the second region?" and historically you'd rebuild the sheet by hand.

Give it the effort data, a rate card and your contingency policy, and ask for the calculation laid out so you can audit every line. Then ask for the scenarios in the same shape, so they're comparable at a glance.

Inputs:
- Task rows with owner_role and effort_days (below).
- Rate card: PM £650/day, Design £700, Eng £750, QA £500.
- Contingency policy: 15% on Build & QA, 10% elsewhere.
- Non-labour: licences £2,400, user-testing incentives £1,500.

Task: Produce a budget table grouped by phase with columns:
  phase | role | days | rate | line_cost
then a subtotal, contingency line, non-labour, and grand total.
Show the arithmetic — I need to audit each line.

Then produce three scenarios as a comparison table:
  Baseline | Lean (−1 region) | Plus (added hypercare month)
with grand total and the key trade-off for each.

// playbook 4

Resourcing & the over-allocation you can't see

The schedule says the work fits. The resource view often says it doesn't — because the same designer is on the critical path of three things in the same week. This is precisely the pattern a human misses scanning a Gantt and a model catches instantly, because it's just looking for overlapping bookings per person per period.

Feed it the scheduled tasks with owners and ask for an allocation grid: person down the side, weeks across the top, percentage loaded in each cell. Then ask it to flag every cell over 100% and propose levelling options — without you having to decide which option yet.

From the scheduled tasks (task | owner | start | end | effort_days):

1) Build a weekly allocation grid: rows = people, cols = ISO weeks,
   cells = % allocated (assume 5-day weeks, effort spread evenly).
2) Flag every cell > 100% in a separate list: who, which week, what's clashing.
3) For each clash propose 2 levelling options — e.g. shift a
   non-critical task, or split effort — and name the cost of each
   (slip risk, extra cost). Recommend nothing yet. Just lay out the choices.

"Recommend nothing yet" is deliberate. Levelling decisions trade slip against cost against who's already had a brutal month — context the model doesn't have. Its job is to surface the clash and frame the options cleanly; the call is yours.

// playbook 5

The plan is the risk register

The best first-pass risk register is hiding inside the plan you already built. Every dependency is a risk that the upstream thing slips. Every [ASSUMED] tag from the WBS step is a risk that the assumption is wrong. Every resource at 100% is a risk that one sick day cascades. So you don't brainstorm risks from nothing — you ask the model to read them out of the artefacts.

Read the WBS, schedule and resource grid above. Produce a risk register:
  id | risk | source | likelihood(1-5) | impact(1-5) | score | mitigation | owner

Derive risks from the artefacts themselves:
- every [ASSUMED] task → an assumption risk
- every long dependency chain → a cascade risk
- every >90% allocated person → a single-point-of-failure risk
- the milestone with least slack → a schedule risk

Score = likelihood × impact. Sort high to low.
Keep mitigations concrete and actionable — no "monitor closely".

Banning "monitor closely" matters more than it looks. Risk registers rot into a column of meaningless verbs; forcing concrete mitigations ("pre-book a backup designer for weeks 6–7") makes the register a thing you act on rather than a thing you present.

// playbook 6

One truth, three audiences

The status update is where producers lose hours to translation. The client wants reassurance and the headline. The exec wants one line and the number. The team wants the specifics and the blockers. It's the same set of facts rendered in three registers — and rendering one set of facts into three registers is the thing a language model does almost too well.

The discipline is to write the facts once, plainly, and let the model do the three translations — never the other way around. You stay the author of what's true; the model is only the translator of tone.

Facts (the single source of truth):
- Design phase complete, signed off 2 days early.
- Build 60% done. One risk: third-party API docs are thin.
- Need client decision on payment provider by Friday or Build slips a week.

Produce three versions of the same status, no new facts:
1) Client email — warm, confident, one clear ask (the Friday decision).
2) Exec one-liner — RAG status + the single number that matters.
3) Team stand-up note — blunt, specific, blockers first.

Keep each self-contained. Do not soften the Friday deadline in any version.

"No new facts" is the guardrail. A model asked to write a reassuring client email will, unprompted, invent reassuring detail. Pinning it to the fact list keeps all three versions honest — same truth, three tones, zero drift.

// the line

What stays human

It's worth being explicit about the half of the loop that never goes to the model, because the value of the whole approach depends on the line holding. The model drafts; it does not decide. Specifically, it never owns: whether a scope is the right scope, whether an estimate is one you'll actually commit to, who can really do a piece of work given everything you know about them, which risk is the one that matters this week, or what you say when a project is genuinely in trouble. Those are the producer's job, and they're the reason the role exists.

Everything in this playbook is in service of clearing the mechanical work out of the way so you have more attention for that judgement — not less. Used like that, AI doesn't make you a lighter-touch producer. It makes you a faster one with more room to think. The companion toolkit below collects every prompt here, plus copy-paste templates for the WBS, budget, resource grid, risk register and status pack, and a one-page checklist for keeping the human-in-the-loop line where it belongs.