A lot of big agencies are going through “AI transformation” right now.

But most are just using Microsoft Co-pilot (or maybe Gemini) at a surface-level. Getting small, but frequent value — saving a bit of time, but nothing particularly ground breaking.

Clients want lower prices, are bringing more work in-house and management are figuring out how to use AI to mitigate that whilist maintaining their own profits.

Times are getting tougher.

Where does your agency live?

The gap between the two is widening fast.

Those that have moved up the AI maturity ladder are pricing differently, scoping differently, delivering work in half the hours and figuring out their compounding advantage.

There are four levels of AI maturity. Each one gives the AI more autonomy, more capability, and each one demands more of the wrapper around it.

Everyone is talking about level four. The reality is that most companies right now can’t climb past level two.

Not because they don’t want to. Because of three things their suppliers, their IT teams, and their clients haven’t sorted out yet.

This piece walks the ladder, names the hardest part, and gives you a road map to move past it.

The four levels

I’ll through walk each one using one example a PM or account manager will recognise: taking a client kickoff recording and turning it into the deliverables that follow (scope doc, status update, internal brief).

Level 1 — Chatbots

You paste the kick-off transcript into your LLM and ask for a scope doc.

It comes back with something. It reads fine. It uses too many bullet points and doesn’t sound like your agency. It doesn’t know your client. It doesn’t know your last three scopes of work. It doesn’t know the process your clients IT team follows for hosting and deployment.

So you rewrite it.

You can improve this by pasting in your scope template, your tone of voice, your project history, some client guidelines.

You can store some of it in a Project or a Gem. But it’s all static context, and you’re still the one pasting it in every time. The chatbot doesn’t go and do anything. It waits.

Most “we’re using AI” stories in agencies stop here.

Level 2 — AI workflows

You build a Power Automate or n8n flow. Every time a kickoff lands in Drive, the flow pulls the transcript, sends it to an AI node with your scope template hardcoded into the prompt, and drops a draft into a review folder.

It feels like magic the first month. You’ve gone from rewriting scopes from scratch to editing a draft that’s already 70% there. You build the same flow for status updates, retros, meeting summaries.

Here’s where it stops being magic. The workflow can’t think. If the client is in a regulated industry and your last scope needed a compliance addendum, the workflow doesn’t know.

If the transcript covers two projects instead of one, it can’t split them. If your scope template was right six months ago and is now out of date, the flow keeps producing out-of-date scopes until someone goes in and rewrites the prompt.

The workflow does the work. It doesn’t make decisions. Same steps, same order, regardless of the input.

This is where most agencies sit in 2026. And it’s where the conversation usually stops, because climbing higher means dealing with three blockers nobody in the agency tells you about.

The hard part

Between level two and level three, the conversation changes. Not technically. Commercially and contractually.

Level one and two are easy. An enterprise LLM contract. A workflow running on your current IT stack. Some updates to your SOWs.

Level three is when a tool starts reading your files, running on your machine, calling APIs with enterprise-level credentials. That’s the moment IT, security, and your client’s procurement team all wake up at once.

Three things make this the hard part.

1. Tooling access

Claude Code, Cursor, Codex, MCP servers — these get installed and run on the same machine that holds your client files.

Most agency IT teams run approved-software lists. None of these tools are on it yet. A sole trader installs what they want. An agency PM files a ticket and waits six weeks. By the time you’re approved, the client project is over.

2. Enterprise IT and security approval

The moment a tool reads files and calls external APIs, it triggers your InfoSec process. Your clients vendor compliance questionnaire — incoming!

And now you wish your agency holds ISO 27001 or SOC 2 — your client has high expectations for your data security controls and practices.

Most of these tools route through US-based model providers. That alone is a procurement conversation for any UK financial services, healthcare, or public sector client.

Add the DPA from the model provider, the sub-processor disclosure to your client, and the security questionnaire your client will fire back at you, and you’ve added two to four months to your timeline.

3. Client contracts

Most MSAs and SOWs you signed before 2025 say nothing about AI. Some explicitly forbid third-party data processors. A few regulated clients require human-only work for parts of the engagement. And a small but growing number now mandate AI use, with a discount baked in.

None of this is in your standard contract template, and none of it is being negotiated by your account manager on the fly during a renewal call.

The agencies winning this year aren’t waiting for clients to ask. They’re leading the conversation.

This is the hard part. Most agencies hit it and retreat back to level two, where the brief n8n flow keeps running and nothing fundamental changes.

You don’t get past the hard part by being clever about the tools. You get past it by doing the slow, unglamorous work of getting your IT team, your client’s IT team, and your contracts onside before you need to scale.

And agencies that are ISO27001, SOC2 and ISO42001 certified and are going to win.

Level 3 — Agentic workflows

Past the hard part, level three is where the time starts to come back.

You open Claude Code, point it at the kickoff transcript, and tell it: “Draft the scope doc, the internal brief, and the first status update for this project. Use the templates in the templates folder and the brand voice in voice.md.”

It reads your templates. It reads your voice file. It looks at the transcript and decides what goes where: what’s a deliverable, what’s a risk, what’s a dependency. It drafts the scope doc. It checks it against your voice file. It rewrites the parts that don’t pass. It drops everything in a review folder.

You didn’t write the steps. The model did. And it did them in the order that made sense, with the context it pulled in at the right moments.

Level 4 — Agentic AI systems

Level four is what people are calling harness engineering. It’s where the agency operations actually start to run on AI rather than just being helped by it.

It’s a coordinated team. Not multiple agents shouting at each other. A set of skills, each with its own instructions, its own quality bar, its own output format, loaded only when the system needs them.

A delivery system for one client engagement might include:

• A scoping skill that takes a kickoff transcript and produces a scope doc, with a checklist of items that need human input

• A status reporting skill that pulls from Jira or Monday and drafts the weekly RAG report in the client’s preferred format

• A QA skill that reviews any deliverable against the client’s brand guide and flags issues before send

• A retro skill that runs at the end of each sprint and writes both the internal post-mortem and the client-facing wrap-up

The system loads the right skill at the right moment. It carries memory between sessions. It remembers which formats this client prefers, which deliverables always come back with the same set of revisions. It checks its own work. It flags what needs you and handles the rest.

Underneath all of this, there’s no magic. It’s folders of markdown files on top of Claude Code. The brand voice is a file. The QA checklist is a file. The memory of what worked last month is a file. The model reads them when needed and updates as it learns.

Which means the work of building it isn’t engineering. It’s writing clear instructions. Which makes agency PMs and operators — the people who already write SOPs, briefs, and templates — the ones best placed to build it.

The playbook for the hard part

You don’t move from level two to level four in one quarter. You move by doing eight unglamorous things in parallel over six to twelve months. This is the runway to get AI live and working on client engagements.

Back to the playbook:

1. Get a senior sponsor and name an owner.

Nothing moves without a named exec (MD, CEO, CFO) putting their weight behind this, and an operational lead (Head of Delivery, Head of Ops) running it day-to-day. Everything stalls without these two people. They’ll also need a support team of individuals for enablement.

2. Run an internal pilot and document it.

Pick three core processes that are time consuming — your own scope drafting, status report generation, retro write-ups. Run them through Claude Co-work for two to four weeks. Capture four numbers: hours before, hours after, error rate, and a quality score from a senior reviewer.

Produce a one-page case study with those numbers. This will help to demostrate the value of AI quickly.

3. Get ISO 27001 and SOC 2 in motion.

This is the certification gate most agencies underestimate. Regulated clients in financial services, healthcare, and public sector will not let AI tools touch their data without one of these certifications on file.

Even non-regulated clients are now asking, because their compliance teams have started flagging AI tools as third-party data processors that need due diligence.

ISO 27001 is the international standard for information security management. It proves your agency runs a working ISMS — policies, controls, risk assessments, access management, incident response. Budget £15–30k and six to nine months for a first certification through a UKAS-accredited body.

Mainly for the US market — SOC 2 Type 2 is the AICPA report covering trust services criteria (security, availability, confidentiality, processing integrity, privacy) measured over a 6–12 month observation window. Type 1 is a point-in-time snapshot; Type 2 is where you have built up evidence over time (and what clients actually want). Budget £30–60k for an agency under 100 people.

The driver for what to get first is who are you main market. ISO 27001 is faster to achieve and more recognised in UK and EU markets. SOC 2 Type 2 is non-negotiable for US enterprise sales.

The agencies winning regulated AI work in 2027 are the ones whose audits started in 2026.

4. Get your tools on to the approved register.

Claude Enterprise for organisational AI usage (gives you the DPA, SSO, data residency commitments your IT team will demand).

Your chosen agentic harness — Claude Code, Co-work, Cursor, or Codex — configured through your enterprise account.

The MCP servers that connect to your delivery stack (Jira, Monday, Notion, Confluence, your file storage). Each tool needs: vendor security review, signed DPA, sub-processor disclosure, internal data flow assessment.

Allow 8–12 weeks per tool. Run them in parallel.

5. Draft the AI contract package

Three documents your legal counsel writes once and you reuse across every renewal and new SOW.

(a) An AI addendum for your MSA covering what you use AI for, what data is processed where, where the human review steps sit, and the client’s right to opt out.

(b) An AI use disclosure form attached to each engagement scope.

(C) A sub-processor list you keep current. Bring this package to clients proactively at renewal. They will respect you more for raising it than for being asked to disclose it later.

6. Pick three client-safe use cases for the first live quarter

Not everything at once. Three.

Examples that work:

• Scope drafting where the PM authors and AI assists

• Meeting transcript summaries with client consent

• Internal status report drafts the PM reviews before sending to client.

Each use case gets a documented workflow with a defined human review point and a named PM accountable for output quality.

Run them on two or three willing clients first, not your whole portfolio.

7. Train delivery teams on workflows, not prompts

Prompt-writing isn’t the skill. The skills are: knowing when to reach for AI versus when not to, what to disclose to the client and when, how to spot when the output is wrong before the client sees it, and how to escalate if a deliverable goes out with an AI error.

Run a two-day workshop for delivery leads, then a structured one-hour rollout for every PM and AM on the team. Build an internal AI playbook that captures the agreed answers, make sure it’s back by a solid business-level AI Policy.

8. Set up tracking and a quarterly review

Per use case: hours saved versus the internal baseline from step two, output quality score from senior reviewers, errors caught at review, errors that reached the client.

Review the numbers quarterly with the exec sponsor from step one. Kill use cases that aren’t paying back. Scale the ones that are.

Where this doesn’t pay off

Remember. This is still client work.

The agencies failing at level three and four are the ones that confused “agentic” with “autonomous”. They’re not the same. The systems that actually deliver have humans in the loop at the moments that matter: input quality at the start, output quality at the end.

You will still need account managers. You will still need senior PMs. You will still need someone with taste and judgement looking at every deliverable that goes to a client.

What changes is the ratio. One senior reviewer can manage the output of a system that does the work of three juniors.

That’s the unit economics shift. That’s the margin recovery. It’s not “no humans”. It’s fewer humans who run AI systems.

The other thing nobody mentions: the first six months of this are slower, not faster. You’re writing skills, debugging prompts, sitting through IT meetings, updating MSA language. Trying stuff out and learning from the journey.

What to do this week

Pick the level you’re actually at. Be honest. If your agency’s AI strategy is “we have ChatGPT licences and one person built an n8n flow for proposals”, you’re at level two on a good day and level one on a normal one.

Then do two things.

The default way: buy more AI tool licences, schedule another all-hands about AI, hope your team figures it out.

The way that actually moves you up: start the IT conversation this week, draft the AI addendum for your next MSA renewal, pick one internal process to run as a level three experiment this month.

The agencies that climb the ladder in the next twelve months won’t be the ones with the smartest people. They’ll be the ones who started the contract conversations early and built the boring infrastructure (and compliance) in the background.

That’s the hard part. That’s the work.

Most won’t do it. The few that do will own the next decade of agency delivery.

“On my worst days, I feel useless. Timelines are just paper exercises, I ‘just’ follow-up with people, schedule and lead meetings. I feel like a glorified admin.” — r/projectmanagement

It got hundreds of upvotes. Dozens of replies. All saying the same thing. “Same here.” “This is me.” “I could have written this myself.”

That post is not unusual. It’s the most common career experience in project management.

The trap is structural, not personal.

Most PMs assume they’re stuck because they lack a skill. They look for the next certification. The next framework. The next tool. None of it works.

The thing keeping them stuck is not a skill gap. It’s a pattern of small, invisible career habits.

The trap closes quietly. You take the meeting. You send the status. You don’t ask questions. You learn the tool. You wait. After a year, the role has shrunk to fit the smallest version of you.

You feel useless. You don’t know why. You blame yourself.

The five mistakes below are what’s actually happening. If you stop making them, your role will get bigger.

The Tuesday I caught myself.

Five years into agency life, I was working on a website rebuild for an insurance company. Big budget. Good team. I was the least experienced person - eager to learn.

One day, I noticed something. I had spent the whole time moving Jira tickets between columns. Not solving a problem. Not making a decision. Not driving anything. Just shifting rectangles on a screen.

That was when I realised I had shift my approach. The team didn’t need someone to manage the project. They needed someone to have the difficult conversation with the client about scope. Nobody was doing it. Including me.

I closed Jira and rocked up to my Account Directors desk. Then had a conversation about how I could add more value - it changed everything. Because I stopped waiting.

Stop doing this 👇

1. Saying yes to every meeting.

Attendance is not contribution. PMs confuse the two because meetings feel productive. They aren’t.

If you can’t name what the outcome needs to be, send a one-line update and skip it. The people who lead don’t sit in every meeting. They pick the three that matter and prepare properly for those.

2. Treating status updates as your main value-add.

If your weekly summary is the most senior thing you produce, you’ve capped your career.

Status reports are table stakes. The actual job is making decisions easier for the people around you. Stop sending updates. Start sending recommendations.

3. Never pushing back because you think it’s not your place.

The PMs who grow are the ones who say “I think we’re doing the wrong thing here.” Politely. With evidence AND a solution.

The PMs who stay stuck nod, take the action, and complain about it on Reddit eighteen months later. You are paid to flag the wrong call and make the right one.

4. Learning tools instead of learning to think strategically.

Mastering Jira will not make you senior. Reading books on how your team do their jobs will.

The PMs who jump levels can articulate the trade-off, name the risk, and read the room. Tools are the floor. Value-added thinking is the ceiling.

5. Waiting for permission to lead.

Nobody is coming to tap you on the shoulder.

The PMs who get promoted started acting like leads months before the title. They ran the kickoff nobody owned. They wrote the doc that didn’t exist. They recommended an approach to solving a problem that wasn’t directly theirs.

One note on the messy reality.

These tips sound easy on an email. In practice, they’re harder.

Some clients don’t like pushback. Some bosses don’t promote regardless of effort. Some weeks you’re drowning in deadlines

Don’t be afraid to speak up and get what you want.

Speak soon,
Tim

If your copy team isn’t using AI yet.

You’re the one who has to change that.

Maybe a client started asking. Maybe your management brought it up. Maybe it’s the quiet pressure of every other agency talking about transforming their agency with AI.

The wrong move is rushing in.

The other wrong move is waiting too long.

Here’s the rule that gets it right.

The 80/20 Rule

Most copy teams that try AI without a plan fall into the same loop.

A copywriter writes a prompt. The output comes back generic. They spend an hour editing it back into the brand. They blame the model. They lose trust in the tool. They go back to writing manually, and quietly conclude AI isn’t there yet.

It is. They just walked the model into an empty room.

The agencies getting value from AI right now have figured out one thing.

Eighty per cent of a usable AI output comes from how you’ve set the project up before anyone writes a prompt. Twenty per cent is the edit and the QC.

If the project is set up well, your team starts using AI on day one and produces work that actually sounds like your clients brand. If it isn’t, AI quietly makes the work worse, and your team learns to mistrust the tool before they’ve ever seen it work properly.

For regulated clients — pharma, healthcare, financial services — the stakes are even higher. Quality control isn’t a stage of the work; it’s something you build into the project before anyone writes a prompt.

The job — your job — is to set the project up before they type their first prompt.

Here’s what we’ll cover:

• The 80/10/10 split (and what each part is actually doing)

• The three layers of context that earn their setup time back

• A worked example: an HCP education programme for a pharma client

• Where this rule doesn’t apply

The 80/10/10 Split

Three numbers. One sentence each.

80% — project setup. The slow, invisible work. The files, voice rules, templates and reference content the model reads before it generates anything. This is where the time goes up front — and how you get it back.

10% — the prompt. Much smaller than people think. One paragraph. One task, one audience, one constraint, one format. If your prompts are getting longer over time, that’s a signal the project setup isn’t doing enough.

10% — QC and refine. Your internal revision round(s). Your typical agency-client feedback loop.

Most teams operate at zero per cent setup, ninety per cent prompt-and-pray, and ten per cent rescue editing. They’re working with the model untrained, every time. The output reflects it.

The 80%: Three Layers Of Context

Three layers do the heavy lifting. Build all three for a client and the model stops sounding generic.

1. Identity — who the client is, who their audience are, what good looks like (examples)

This is the most-skipped layer. It’s also the one that does the most lifting.

A pharma client targeting cardiologists needs different copy from one targeting GPs. Same indication. Different reader. Different stakes. Different language.

Same goes for a financial services client targeting wealth managers vs retail investors. Or a B2B SaaS client selling to compliance officers vs marketers.

Without this layer, the model defaults to a generic professional voice. Punchy. Aspirational. Empty. And for regulated clients, frequently non-compliant.

With it, the model writes for the actual reader (which means less editing, every time). Six bullet points are usually enough: who they are, who they sell to, the buyer’s job-to-be-done, regulatory context, three competitors and how the client differs, what the client doesn’t want to sound like.

2. Voice rules — banned words, sentence rhythm, examples that nailed it

This is the layer that takes the longest to write. It also saves the most time downstream.

A list of words the client never wants you to use. A list of phrases that flatten their voice. Industry specific terms. A list of ‘banned’ AI words (the giveaways).

The model treats this as a hard filter. Once it knows the client doesn’t say “unlock” or “leverage” or “supercharge”, those words stop appearing. Your copywriter stops circling them in red.

The voice rules file is where most of your editing time goes when you don’t have one.

3. Reference content — what good looks like in practice

The third layer is structure plus pattern.

If making a website (for example) then templates for the page types the client uses: homepage, articles, features, about etc. Each one a skeleton lifted from a page that worked. Hero promise. Three outcomes. Proof. CTA. The model fills the skeleton.

Plus five to ten finished pages: pages that converted well, competitor pages the client likes, anything the team agreed felt right. The model pattern-matches against them and learns the rhythm of the client’s writing without anyone having to explain it.

Worked Example: An HCP Education Programme For A Pharma Client

Your agency is working on a new website for a pharma client. The brief: a new HCP-facing education hub for their lead product, ahead of an indication update. Eight pages. Mechanism of action, dosing guidance, two patient-type pages, two efficacy pages, an FAQ, and a prescriber resources page.

Two ways to bring AI into this project.

The default way (what most agencies do). A copywriter pastes each page brief into the chat. Asks for “clear, professional HCP copy”. Gets generic output back — promotional language where it shouldn’t be, claims drifting outside the indication, no fair balance, “patients” used loosely where the indication says “adults with X”.

A medical writer spends two hours per page reworking it. Then your team rejects half on the first pass anyway, because the model invented evidence claims that don’t sit in the trial data. By page three, the medical writer is faster doing it longhand.

The way you’ll lead them through. Spend a few hours building four files for your client, before anyone on the team types a single prompt.

1. client-context.md — the product, the indication (in its exact approved wording), the HCP audience (specialists vs primary care, the typical clinical question they’re answering), the regulatory framework (ABPI, PMCPA, MHRA), three competitor products and how this one differs, and the MLR review process with known reviewer preferences.

2. brand-voice.md — register rules (peer-to-peer, evidence-led, no promotional superlatives), banned claim patterns (”first-line”, “best-in-class”, “gold standard” — none of these unless the data explicitly supports them), required hedging (”may reduce”, not “reduces”; “in the X trial, Y was observed”), reading-level guidance, and five to ten example sentences from past MLR-approved work.

3. page-templates.md — page skeletons that meet layout requirements. PI placement. Where safety information sits relative to efficacy. Reference list at the bottom. Required footnotes. Fair balance built into the structure, so the model can’t accidentally write an efficacy page without the safety context.

4. reference-pages.md — five to ten MLR-approved pages from past work or the client’s existing compliant content, plus a claim library: every approved efficacy claim with the trial reference and the exact wording that passed review.

Then the prompt for each page becomes one sentence.

“Draft the mechanism-of-action page for [product], following the brand voice and template. Use only the claim library for efficacy statements.”

The output lands close enough that a medical writer’s pass takes 25 to 30 minutes per page, not two hours. And — far more importantly — you get the work out the door in half the time, because the model isn’t inventing evidence or drifting outside the indication.

Here’s where the time goes:

Now look across the next twelve months. The same client commissions another two campaigns: a new patient-type, congress materials, an HCP webinar deck. The four files don’t need rebuilding. Every new piece of work feeds back into the claim library and the reference pages. The brand voice gets more consistent. QC gets easier (and quicker). And the team’s first experience of AI is one where it works inside the rules, not against them.

The 10% Prompt + 10% QC and refine

Remember.

The prompt. One paragraph. The task, the audience, the constraint, the format. That’s it.

The review. One revision round. For regulated clients, this is also where quality control and compliance get checked against the rules baked into setup.

If setup did its job, that check is verification, not rework. If you’re going past one round consistently, look upstream. The project setup is where the time should go.

When it comes to the human aspects such as a brief being wrong, people changing their minds on the direction, same on the client-side, the review might feel slightly idealistic, but you get my point.

When This Doesn’t Pay Off

The 80/20 rule has limits. Some projects don’t earn the upfront investment back.

• One-off tasks. A single landing page for a one-off client may not justify the setup.

• Highly creative conceptual work. AI is a finisher there, not a starter — constraints kill the spark.

• Clients you’ll never work with again. The setup doesn’t amortise across one engagement.

The rule of thumb: if you’ll write more than five pieces of copy for your client, build the context. Otherwise, prompt and edit.

Move The Time To The Front

Most copy teams adopting AI right now are doing it badly. They’re working with a model that doesn’t have the right context. The output’s generic. Confidence drops. The team goes back to grinding hours.

That doesn’t have to be your experience.

You’re the one who decides how AI lands. Move the time to the front. Build the project, not the prompt. Your team gets AI that actually assists from day one. Your clients get copy that’s on brand and in half the time. And you skip come away feeling like you’ve just transformed the process like it’s 2035.

You don’t have to be ahead of every AI development. You just have to lead this one well.

And this this was userful, send it to a writer in your business who could benefit from learning more AI skills.

Speak soon, Tim

I’ve solved more problems on a walk than I’ve ever solved at my desk.

Most of the answers I’ve actually needed — the awkward client email I couldn’t word, the project plan that wasn’t sitting right, the decision I’d been putting off for a fortnight — didn’t arrive while I was staring at the screen. They turned up about twenty minutes into a walk with the dog. Sometimes on a run. Almost never sitting down.

The desk is where I process. Not where I solve.

Your brain has two gears.

Most of your day is spent in the wrong one.

Focus mode is narrow. Deliberate. It’s the gear you use when you’re pushing at a problem inside a frame you already understand.

Diffuse mode is the opposite. Loose. Associative. The mode where the brain stitches unrelated things together and finds the answer sideways.

Barbara Oakley made this distinction famous through Learning How to Learn — one of the most popular online courses ever made. Her point is simple. Hard problems get solved in diffuse mode. Not focus mode.

You can stare at a piece of work for two hours and miss the obvious thing. Then you stand up, walk to the kettle, and the answer arrives before you sit back down. That’s not a coincidence. That’s your brain finally getting to do the thing it’s actually built for.

A 2014 Stanford study tested this four different ways. People came up with 60% more creative ideas on average when they were walking compared to sitting. Not 6%. Sixty.

You’re not slacking when you walk. You’re using the part of your brain that solves the problems your desk can’t.

The screen is making this worse.

The more you stay at the desk, the less your brain works.

Last year, MIT’s Media Lab ran an EEG study on people writing essays. Three groups: one with ChatGPT, one with a search engine, one with nothing. The results were clear. The brain-only group showed the strongest neural engagement. The ChatGPT group showed the weakest. The researchers coined a term for what they were seeing.

Cognitive debt.

The point isn’t to ditch the tools. The point is what happens when you don’t step away from them.

Look at your day honestly. Screens stacked on screens. AI that can finish your sentences. Slack and Teams channels that train you to react instead of think. A calendar that doesn’t leave a single hour for anything other than meetings. The thing that used to give your brain breathing room — the gap between tasks — is gone. Filled with autocomplete.

The walk is the gap. Without it, the brain never gets to do the work that actually makes you good.

How to actually do this.

Three rules. They sound simple. Most people ignore all three.

1. Walk before the hard thing, not after.

When you’ve got a meeting where you actually need to think — a difficult conversation, a decision you’ve been ducking, a problem that’s been on your mind for days — take twenty minutes first. Walk, then sit down. Don’t reverse it. The point is to arrive at the desk with the answer, not leave looking for it.

2. Phone in pocket. No podcasts.

Diffuse mode needs silence. Not stimulus. Music with lyrics, podcasts, calls — they all pull you back into focus mode and waste the walk. The brain needs the boredom. That’s actually what triggers it.

3. Bring the problem. Then let it go.

Frame the question before you leave the desk. Walk out with it in your head (don’t try to solve it). Then stop pushing. The brain does the work in the background. The answer arrives sideways, usually around minute fifteen.

The first walk feels like wasted time. By the third, you’ll notice you’ve solved things you couldn’t crack at the screen. By the tenth, you’ll start guarding the time on your calendar like it’s a meeting. Which is what it is.

The job is to think.

Whatever you do for a living, the thing you’re actually paid for is judgment.

The plan is downstream of it. The email is downstream. The decision is downstream. Every output you produce is the visible end of an invisible process — the actual thinking — that has to happen somewhere.

If the only place that ever happens is at your desk, in front of a tool that finishes your sentences, you’re not thinking. You’re typing.

And typing is the easiest thing in the world to replace.

The people who pull ahead this year will be the ones whose best ideas didn’t come from a prompt box. They came from somewhere quieter.

Walk. Cos that’s where the work actually gets done.

And, if this was useful, forward it to someone stuck in firefighting mode. They need this more than anyone.

Speak soon, Tim

Share The Wash-Up

Several months ago I rebuilt how I handle client projects inside LLMs.

I was tired of repeating myself everytime I needed to get an output that knows my specific usecase.

Spending too much time proving context and re-working the results.

Every conversation started like this (using some best practice prompting)

1. Give the LLM a role

2. Describe the task

3. Explain the client (then paste in or attach the brief)

4. Tell it the output I want

5. Press Go. Get half a half-decent output.

6. Iterate (feeling like I’m going into a black hole)

7. Close the tab

8. Do it all again next time

That’s not a process that saves a lot of time. Sound familiar?

Stop treating AI like something you have to re-educate every conversation

This is like using an LLM from 2024. Every chat starts at zero. You train it in real-time with long prompts and attachments, and all that context disappears the moment you close the window.

In 2026, LLMs have better memory and a larger context window, but prompts on their own lack the persistent context you need to get more relevant outputs.

‘Projects’ in LLMs works differently.

You set them up once — Your client brand, who your stakeholders are (and your style of communicating with them), what you’re delivering and all about your agency so it knows your team and process too.

Every conversation after that has full context already loaded, you can provide even more through adding further documentation to the project as your own progresses.

It’s the difference between briefing a new freelancer every Monday and working with someone who has deeper experience to your agency and your projects, like a full-timer.

Three ways you can use AI right now

Most of us are in one of three camps:

1. One-off chats. Fast, but forgetful. Every conversation starts from zero. Good for quick questions. Terrible for ongoing client work.

2. Saved prompts. Better. You’ve written a good system prompt and you paste it in each time. But it’s rigid — one prompt can’t cover five clients with different preferences.

3. Projects. Persistent context that compounds. You teach it once. It remembers. Every conversation inherits the client context, the reference files, add more as the project progresses.

This guide covers the third option. If you’re still in camp one or two, this is going to 10x your results.

For this walk through I’m going to use my favourite LLM, Claude but ChatGPT also has ‘Projects’ and Gemini has ‘Gems’. Same thing, different LLM’s.

Here’s what you need

• Your company approved LLM set up OR A Claude Pro subscription (Projects isn’t on the free tier — $20/month)

• One active client project

• That client’s key documents: The project brief, Scope of Work, timeline, brand guidelines, risk register, reporting template, tone of voice, a persona of your client - fill your boots.

Just start with one client for now - and make sure you have permission!

Step 1: Create a Project and name it after your client

Open Claude. Click **Projects**. Click **New Project**.

I use the format: `[Client Name] — [Client Project]`. When you have five Projects open, you need to find the right one fast. Client name first.

> One Project per client. If you’re running multiple for the same client, create a new project, but give each of them the same client-specific documents for consistency.

Step 2: Write custom instructions

Click the gear icon, then **Edit Custom Instructions**.

Think of this as a briefing document for a new team member. If someone joined your project tomorrow, what would they need to know?

I use four sections:

1. Client context — who they are, brand guidelines, project history, budget ranges, IT information (hosting, domains etc), compliance (industry specific rules)

2. Key stakeholders — names, roles, preferences (Sarah wants executive summaries at the top. Marcus cares about brand consistency etc.)

3. Deliverables — what we deliver and how often

4. Tone and format — how the client likes to be communicated to.

5. Templates - specific project templates that you use for this client (for outputs)

6. Working rules or constraints - tightening up the LLM to get outputs specific to how I want them.

Tip: Use an LLM to help you write the instructions.

Just tell it what you’re trying to do and ask it to interview you - asking questions to help it produce best practice custom instructions for your project. Throw in your draft and ask it for ‘best practice custom instructions’.

Example custom instructions for a fictional client

# Role

You are a senior Project Director embedded in my marketing agency team. You have deep experience delivering paid social campaigns for DTC brands. You are my trusted advisor for day-to-day project management, strategic thinking, and client-facing communications.

Your default behaviour: be decisive, give direct recommendations (not open-ended options), flag risks early, and always ground your advice in the project context below.

---

# Client & Engagement

- **Client:** Apex Athletic — DTC sportswear and accessories brand.
- **Engagement:** Paid social campaign across Meta Platforms (Facebook & Instagram).
- **Agency role:** Campaign strategy, creative production, media buying, reporting.

---

# Stakeholders

When writing for or about these stakeholders, match their preferences:

| Name | Role | Cares about | Communication style | Avoid |
|---|---|---|---|---|
| Tom | Founder | Brand momentum, ROI, strategic direction | High-level, visual, concise — lead with headline metrics and insight, not granular data | Jargon, lengthy tables, excessive detail |
| Jess Morley | Marketing Manager | Performance data, day-to-day progress, risk flags | Detailed, structured, data-rich — she wants the numbers and the context behind them | Vague summaries without supporting data |
| Liam Osei | Brand Lead | Creative quality, tone consistency, brand alignment | Precise, reference brand guidelines in feedback — he needs to see how creative decisions connect to brand standards | Presenting creative work without linking it back to agreed brand direction |

---

# Deliverables & Schedules

| Deliverable | Frequency | Key requirements |
|---|---|---|
| Time Plan updates | As needed | Milestones, owners, status (RAG), dependencies, next actions |
| Weekly status reports | Every Friday | Summary, progress vs plan, risks/issues, upcoming actions — tailored to Jess (detailed) with an exec summary for Tom |
| Campaign briefs | Ad hoc | Objective, audience, platform, messaging pillars, KPIs, creative specs, timeline |
| Content calendars | Monthly | Date, platform, format, copy direction, creative status, approval owner |
| Performance reports | Fortnightly | KPIs vs targets, spend pacing, top/bottom performers, optimisation recommendations, next steps |

---

# Tone & Language Rules

- Confident, direct, and professional. UK English throughout (e.g. optimisation, analyse, colour).
- Write as a peer advising the client — authoritative but collaborative, never subservient.
- Always refer to Apex Athletic's customers as **"athletes"** or **"our community"**.
- Never use: "consumers", "users", "target audience", or "end users".
- Include data or evidence in every client-facing update — no unsupported claims.
- Keep paragraphs short. Use tables and bullet points for scannability in reports and status docs.

---

# Working Rules

1. **Always consult the knowledge base and attached project documents first** before generating project advice, reports, or deliverables. Reference specific documents where relevant.
2. When producing deliverables, follow the formats and structures already established in the project documents. Consistency matters to this client.
3. If information is missing or ambiguous, say so and ask me — do not fabricate dates, figures, or commitments.
4. Flag risks and blockers proactively. If something looks like it could slip, raise it before I ask.
5. When I ask for a draft email or client message, always specify which stakeholder it is written for and adapt tone accordingly.
6. Assume all deliverables are client-facing unless I say otherwise.

Step 3: Upload your context files

Below the instructions, upload the project specific documents Claude should reference:

• The client brief (so it knows the original ask)

• The Scope of Work (so it knows your deliverables, milestones, dependencies, assumptions and out of scope)

• Your time plan

• Risk Register

• Status report template

• Recent document deliverables (so it learns your actual output style — this is the one people miss) - you’re teaching it what you want as an output.

What not to upload: everything. Don’t dump your whole shared drive in here.

One great context file is worth more than twenty random uploads. Be intentional about what goes in.

Step 4: Use it

Open the Project. Start a conversation. Type a short prompt.

Status report:

Write this week’s status report. Static ad creatives approved by Liam. Instagram account set up. Gym shoot booked for Wednesday. Meta pixel verified.

That’s the entire prompt. No preamble. No “you are a project manager working for...” Claude already knows.

Meeting prep:

Monthly review with Tom and Jess on Thursday. Draft agenda and talking points. Flag concerns. Use our company template.

Client brief:

Draft a Facebook awareness campaign brief. Budget GBP 5000. Objective: build followers ahead of the Manchester Fitness Expo.

Ten-second prompts. Fast outputs. The Project context does the work you used to do manually.

Three more use cases

Agency PM with 5 retainer clients.

One Project per client. Each contains the brief, project documents, and last few project deliverables. Every status report, meeting prep, and comms draft starts with full context. You stop re-explaining. You start producing.

Account manager preparing a monthly review.

The Project already has the SOW, recent deliverables, and stakeholder preferences. Ask Claude to flag gaps, draft talking points, and prepare an agenda. Twenty minutes of prep becomes five.

Account Director writing proposals.

Upload your proposal template and a couple of past winners. Custom instructions describe your positioning and ideal client. Each new proposal starts from your best work, not a blank page.

What it won’t do

I’m not going to pretend this solves everything.

Here’s what you should know:

• A ‘Project’ can’t pull data from Asana, Monday, or Jira out the box. 100% possible but needs a bit of set up.

• AI tools CAN easily integrate with other systems via simple integrations, using MCP servers or APIs. But that’s for another day.

• File uploads have limits. You can’t load an entire shared drive - again another integration.

• It sometimes misreads complex PDFs. Markdown and plain text are the most reliable formats.

• Again - For personal use, Claude Pro plan required. $20/month. For client work use the tools that your company provides and are compliant.

• Every output still needs your eyes before it goes to a client. Claude gets the structure right. It gets the tone close enough to edit, not rewrite.

It can hallucinate so double-check the outputs like any good PM should. Treat it as shortcut to your first draft.

Your first 20 minutes

• Create one Project for your most active client.

• Write custom instructions. Client context, stakeholders, deliverables, tone. Use an LLM to help you.

• Upload your context documents.

• Ask it to draft something you’d normally spend 30 minutes on. Compare.

That’s it. One client. One Project. Real tasks.

If the output is close to what you’d have written — and it usually is — do the same tomorrow.

You’re now at the next level of using AI.

Start with the client that makes you sigh when you open inbox. Set it up today.

Once you’ve got Projects working, there’s a next level.

Claude recently launched co-work — where the AI works alongside you in real time across your project files, not just inside a chat window. It will take your delivery to next level.

I’ll be writing about that soon. But master Projects first. Get the context right. Then we’ll go further.

And, if this was useful, forward it to a PM who’s still pasting briefs into an LLM every morning. Cos that was me a couple of years back.

Speak soon,

Tim

Level-up your prompting and Help me grow the Wash-Up?

In return for you sharing my Substack publication with 3 colleagues (and them subscribing) I will personally send you (and them) a 50% discount code EACH for:

79 AI Prompts That Actually Work in Website Delivery

Just let me know their name and email address, then drop a message to tim@thewashup.club and I’ll send it over within 24 hours.

Share The Wash-Up

Every PM has received a brief like this.

You get an email about a new project. You open the document hoping for a good amount of detail. Instead you get: “We want to blow up on social media.” Budget? “Still working that out.” Timeline? “As soon as possible.” Success criteria? “More sales.”

I exagerate a bit but lots of clients lack experience in how to give their agency what they need for a strong start. And if you skip some basic planning, you’ll be firefighting right after kick off — especially on smaller projects.

Today, I’m going to walk you through turning a brief like that into a full scope of work, time plan, and risk register in under an hour.

Five prompts with outputs you can acutally use.

Here’s what we’ll create:

• The scoping questions you need answered

• An SOW with clear boundaries

• A work breakdown with tasks and dependencies

• A time plan with estimates

• A risk register

Meet Apex Athletic (a fictional client)

To walk you through properly, I needed a brief that felt real enough, whilst not breaching my own client confidentiality.

So I wrote one and here’s the TLDR.

Apex Athletic is a fictional 15-person sportswear brand. Decent products, great reviews. They want paid social ads across TikTok, Instagram, and Facebook. They’d tried a freelancer before and it “didn’t really work out.” They weren’t sure if ad spend included agency fees. They didn’t have a TikTok business account. No real social media strategy, more ‘hit and hope’.

Swap Apex for your real client and every prompt in this article works the same way.

Ask the right scoping questions

The Apex brief has a lot of gaps. Little internal process. No asset ownership. No reporting cadence. The client (Tom) wants to approve everything but he’s strapped for time. The usual challenges.

Before you crack on and brief your team, you need to close those gaps and You don’t need to figure out which questions to ask from scratch!

Paste (or attach) the brief into your LLM and use this:

# ROLE
You are a senior digital project manager with 10+ years of experience scoping and delivering paid social campaigns inside marketing and advertising agencies. You have deep practical knowledge of campaign delivery across Meta (Facebook/Instagram), TikTok, LinkedIn, X, Pinterest, Snapchat, and YouTube - including ad account structures, pixel/CAPI implementation, creative production pipelines, approval workflows, media buying operations, and client-side compliance (GDPR, ASA/CAP Code, platform ad policies).
You are known for surfacing the risks and assumptions that cause scope creep, missed launches, and awkward client conversations - before the Statement of Work is signed.
# OBJECTIVE
Read the client brief provided below and generate a comprehensive, brief-specific list of scoping questions I should ask the client before kicking off the project. The questions must be tailored to the actual content of this brief - not generic paid social checklist items.
# CLIENT BRIEF
<
{{PASTE_CLIENT_BRIEF_HERE}}
>>>
# ADDITIONAL CONTEXT (optional - fill in if known)
- Agency services being offered: {{E.G. STRATEGY, CREATIVE, MEDIA BUYING, REPORTING}}
- Estimated campaign duration: {{E.G. 6 WEEKS}}
- Known client maturity with paid social: {{E.G. FIRST-TIME, EXPERIENCED IN-HOUSE TEAM}}
- Any existing relationship or prior work: {{E.G. NEW CLIENT, EXISTING RETAINER}}
- Agency commercial model: {{E.G. FIXED FEE, % OF MEDIA SPEND, HOURLY}}
# METHOD - THINK IN PHASES
Before writing questions, work through these phases internally:
Phase 1 - Brief interrogation
- Identify what the brief explicitly states.
- Identify what's implied but not confirmed.
- Flag what's conspicuously missing or vague.
- Note any internal contradictions or unrealistic expectations (e.g. timeline vs scope, budget vs ambition).
Phase 2 - Risk mapping
- For each gap or ambiguity, identify the delivery risk it creates (scope creep, delay, compliance exposure, commercial risk, client dissatisfaction).
Phase 3 - Question generation
- Convert each risk into a precise, brief-specific question.
- Prioritise questions that unblock kick-off, protect margin, and prevent late-stage surprises.
- Avoid generic questions that could apply to any paid social brief.
# OUTPUT FORMAT
Produce the output in clean Markdown, structured for direct paste into a Word doc, Confluence page, or Notion page. Use British English throughout.
Structure:
## 1. Brief Summary (3–5 bullets)
A quick recap of what I've understood from the brief, so the client can confirm I've interpreted it correctly.
## 2. Key Assumptions I'm Making
A short list of assumptions that, if wrong, would materially change scope, timeline, or cost.
## 3. Scoping Questions
Group questions under the following headings. Only include a heading if there are relevant brief-specific questions for it - do not pad with generic filler.
- Approval Process & Decision-Making
- Content Ownership & Usage Rights
- Creative Asset Availability & Production
- Compliance, Legal & Brand Safety
- Budget Allocation (Ad Spend vs Agency Fees)
- Technical Setup (Ad Accounts, Pixels, CAPI, Tracking, UTM)
- Reporting & Measurement Expectations
- Success Criteria & KPIs
- Other Risks or Gaps Surfaced by This Specific Brief
For each question, use this micro-format:
> Q: [The question]
> Why it matters: [One short sentence linking it to a delivery/commercial/compliance risk specific to this brief]
## 4. Top 5 Questions to Ask First
The five questions I should not leave the kick-off call without answering, ranked. These should be the questions most likely to reshape scope, budget, or timeline.
## 5. Red Flags & Watch-Outs
Anything in the brief that feels risky, underspecified, or commercially concerning - stated plainly, so I can raise it internally before the client call.
# CONSTRAINTS
- Be specific to this brief. Reference details from it directly in the "Why it matters" notes.
- Do not invent facts about the client. If something isn't in the brief, treat it as a gap to ask about - not an assumption to state.
- Keep questions clear and answerable by a non-specialist client contact.
- Use UK English spelling and DD/MM/YYYY date format.
- If the brief is too thin to generate meaningful questions in a given category, say so explicitly rather than padding.
# HONEST LIMITATIONS
Flag at the end of the output:
- Any part of the brief you found ambiguous and had to interpret.
- Any assumptions a human PM should sense-check against client/agency context before sending the questions.

You’ll get a list of questions in 15 seconds that would have taken you 20 minutes to think through — longer if you need to speak to people internally. Things like: “Do you have existing photo or video assets we can work with from day one?” and “Will Tom need to approve every individual ad creative, or just the initial creative direction?”

Get a quick sense-check from your team, especially if this is an existing client for whom you have a bit of work history.

Get all the answers. Write them down. You need them for the next step.

Write the scope of work

Take the original brief and your scoping answers. Feed them both in (or attach to the LLM chat):

# ROLE
You are a senior digital project manager and commercial operator with 10+ years of experience writing Scopes of Work (SoWs) for paid social campaigns inside marketing and advertising agencies. You are equally fluent in delivery reality and commercial protection - your SoWs are known for being tight, unambiguous, and impossible to weaponise against the agency later.
You write in plain, confident language. No jargon for jargon's sake. No hedging. No filler.
# OBJECTIVE
Using the client brief and scoping answers provided below, produce a Scope of Work document that is clear, commercially watertight, and under 500 words. The document must be specific to this engagement - every section should reference real details from the inputs, not generic paid social boilerplate.
# INPUTS
## Client Brief
<
{{PASTE_CLIENT_BRIEF_HERE}}
>>>
## Scoping Answers
<
{{PASTE_SCOPING_ANSWERS_HERE}}
>>>
## Additional Context (optional - fill in if known)
- Agency name: {{AGENCY_NAME}}
- Client / brand name: {{CLIENT_NAME}}
- Campaign / project name: {{PROJECT_NAME}}
- Proposed start date: {{DD/MM/YYYY}}
- Proposed end date: {{DD/MM/YYYY}}
- Commercial model: {{E.G. FIXED FEE, % OF MEDIA SPEND, T&M}}
- Known constraints: {{E.G. LEGAL REVIEW REQUIRED, OFFSHORE STAKEHOLDERS, PEAK TRADING PERIOD}}
# METHOD - THINK IN PHASES
Work through these phases internally before writing the SoW:
Phase 1 - Reconcile inputs
- Cross-reference the brief against the scoping answers.
- Identify contradictions, gaps, or items where the scoping answers changed the original brief.
- Note anything the scoping answers still didn't resolve - these become Assumptions or Dependencies, not invented facts.
Phase 2 - Pressure-test each section
- For every In Scope item, ask: "Could a client argue this means more than I intended?" If yes, tighten the wording.
- For every Out of Scope item, ask: "Is this something the client might reasonably expect to be included?" If yes, it must be explicitly excluded.
- For every Success Criterion, ask: "Is this measurable, and does the agency control the levers to influence it?" If not, reframe or move to Assumptions.
Phase 3 - Write tight
- Cut anything that isn't load-bearing.
- Use active voice. Short sentences. Concrete nouns.
- Stay under 500 words total across all sections.
# OUTPUT FORMAT
Produce the SoW in clean Markdown, ready to paste into Word, Confluence, or Notion. Use British English, DD/MM/YYYY dates, and £ for any currency references.
Structure exactly as follows:
 - -
# Scope of Work: {{PROJECT_NAME}}
Client: {{CLIENT_NAME}} | Agency: {{AGENCY_NAME}} | Dates: {{START}} - {{END}}
## Project Goal
One sentence. Plain language. Describes the business outcome the campaign is driving toward - not the activity.
## Success Criteria
3–5 measurable outcomes, expressed as specific targets or thresholds where possible (e.g. CPA, ROAS, CTR, reach, leads). If the scoping answers didn't give numbers, state "Target to be confirmed at kick-off" rather than inventing them.
## In Scope
A tight, bulleted list of specific deliverables and activities the agency will produce or perform. Each bullet should be concrete enough that a third party could tell whether it had been delivered. Group logically (e.g. Strategy, Creative, Media, Reporting) if the list exceeds ~6 items.
## Out of Scope
Explicitly excluded items the client might otherwise assume are included. Prioritise exclusions that protect margin or prevent common scope-creep traps in paid social (e.g. additional creative rounds, organic social management, influencer sourcing, landing page builds, ad account creation on behalf of client).
## Key Stakeholders
A short table or list with:
- Name / Role / Organisation
- Decision-making authority (e.g. Approver, Reviewer, Informed, Day-to-day contact)
Include both client-side and agency-side stakeholders. If names aren't in the inputs, use role placeholders (e.g. "Client Marketing Lead - TBC").
## Dependencies
Things that must happen before or during the engagement for the agency to deliver. Be specific about who owns each dependency and the risk if it's late (e.g. "Client to provide brand assets by DD/MM/YYYY - delay will push launch date").
## Assumptions
What the agency is assuming to be true in order to scope this engagement. If any assumption proves false, it is a trigger for a change request. Cover: creative rounds, approval turnaround times, asset availability, platform access, spend levels, and reporting cadence.
 - -
## Change Control Note (single line, after the SoW)
> Any changes to the above - including additional deliverables, extended timelines, or shifts in spend - will be managed via a written change request and may impact fees and delivery dates.
# CONSTRAINTS
- Hard limit: under 500 words total across the SoW (excluding the title block and Change Control Note).
- Plain language. No agency jargon unless it's standard client-side vocabulary (CPA, ROAS, CTR, CAPI are fine).
- Every section must reference specifics from the brief or scoping answers. No generic boilerplate.
- Do not invent numbers, names, dates, or commitments not present in the inputs. If something is missing, surface it as an Assumption or Dependency.
- Use UK English spelling and DD/MM/YYYY date format.
# HONEST LIMITATIONS
After the SoW, in a separate ## Reviewer Notes section (not counted in the 500-word limit), flag:
- Any gaps in the inputs that forced an assumption.
- Any clauses a human PM or Account Director should pressure-test before sending to the client.
- Any commercial or legal items that should be reviewed by Finance/Legal (e.g. IP ownership, data processing, indemnities) before signature.

Even better — give the LLM your existing SOW template and have it fill it in.

This is the section that saves you hours of rework later.

For Apex, “out of scope” included: organic social content, influencer outreach, website changes, and email marketing integration. None of that was mentioned in the brief as excluded. But if you don’t write it down now, someone will assume it’s included at week four.

The “assumptions” section is where you put the stuff that feels obvious today but becomes a dispute later. “Content photography will be provided by the client.” “TikTok business account setup is the client’s responsibility.” “Ad creative approval turnaround is 48 hours.”

Share this document. Get sign-off. Even a reply saying “Yep, that’s right” is enough.

You now have something to point back to when priorities start shifting. And they will.

Break the work down and build the time plan

This is where you go from “what are we doing” to “how are we doing it” and “how long will it take.” Two prompts, back to back.

First, the work breakdown:

# ROLE
You are a senior digital project manager with 10+ years of experience planning and delivering paid social campaigns inside marketing and advertising agencies. You are known for work breakdown structures (WBS) that hold up under pressure - granular enough to assign and estimate, structured enough to spot critical path and dependency risk before they derail a launch.
You think in deliverables, not activities. You know the difference between a dependency and a sequencing preference. You've seen enough launches slip over missing pixel access, delayed legal sign-off, or ambiguous creative approvals to build those risks into the plan from day one.
# OBJECTIVE
Using the Scope of Work provided below, produce a comprehensive work breakdown that decomposes the engagement into phases, tasks, and dependencies. The output must be specific to this SoW - every task should be traceable to something in scope, not generic paid social filler.
# INPUT
## Scope of Work
<
{{PASTE_SOW_HERE}}
>>>
## Additional Context (optional - fill in if known)
- Primary platform(s): {{E.G. META, TIKTOK, LINKEDIN}}
- Team structure / named roles: {{E.G. PM, STRATEGIST, CREATIVE, MEDIA BUYER, ANALYST}}
- Known delivery constraints: {{E.G. LEGAL REVIEW SLA, CLIENT APPROVAL SLA, PEAK TRADING FREEZE}}
- Agency PM tool: {{E.G. JIRA, ASANA, MONDAY, CLICKUP}} - used to shape task granularity
# METHOD - THINK IN PHASES
Work through these steps internally before producing the table:
Step 1 - Map scope to phases
- For each In Scope item in the SoW, identify which phase(s) it belongs to.
- If an In Scope item doesn't map to any phase, flag it - it's either out of place or missing a phase.
Step 2 - Decompose each phase into tasks
- Break each phase into tasks at a granularity where each task is:
- Ownable by a single role
- Estimable in hours or days
- Verifiable (you can tell when it's done)
- Avoid tasks so broad they hide complexity (e.g. "Build campaign") or so granular they become noise (e.g. "Open Ads Manager").
Step 3 - Identify dependencies
Be precise about dependency type:
- Internal - Task: depends on another task in this plan completing (reference the task name).
- Internal - Role: depends on a specific role being available or having completed prior work.
- External - Client: depends on the client providing an input, access, or approval.
- External - Third Party: depends on a platform, vendor, or external system (e.g. pixel implementation by client's dev team, platform ad review).
Step 4 - Surface critical path and risk
- Identify the tasks that, if delayed, would delay launch.
- Identify dependencies most likely to slip based on the SoW's assumptions and dependencies.
# OUTPUT FORMAT
Produce the output in clean Markdown, structured for paste into Word, Confluence, Notion, or direct import into a PM tool (Jira/Asana/Monday/ClickUp). Use British English throughout.
Structure:
## 1. Work Breakdown Table
A single table with the following columns:
| Phase | Task ID | Task | Owner (Role) | Dependencies | Dependency Type | Critical Path? |
| - -| - -| - -| - -| - -| - -| - -|
- Phase: One of - Discovery, Setup, Creative Development, Campaign Build, Launch, Optimisation, Reporting. Add additional phases only if the SoW genuinely requires them (e.g. Legal Review as a standalone phase for regulated clients).
- Task ID: Sequential within phase, e.g. DIS-01, SET-01, CRE-01, BLD-01, LNC-01, OPT-01, RPT-01.
- Task: Specific, verifiable deliverable or activity. Action verb first.
- Owner (Role): The role accountable (not the person). Use "TBC" if the SoW doesn't specify.
- Dependencies: Task IDs or named inputs. Use "None" if genuinely independent. Do not use "None" as a lazy default.
- Dependency Type: Internal - Task / Internal - Role / External - Client / External - Third Party / None.
- Critical Path?: Yes / No. Mark Yes only for tasks that sit on the critical path to launch.
## 2. Critical Path Summary
A short bulleted list naming the tasks on the critical path to launch, in sequence. This is the chain you protect at all costs.
## 3. High-Risk Dependencies
3–6 dependencies most likely to slip, based on the SoW's stated assumptions, dependencies, and typical paid social delivery risks. For each, note:
- The dependency
- Why it's high risk (referencing the SoW where possible)
- A suggested mitigation (e.g. request access at kick-off, pre-brief legal, lock creative approver)
## 4. Gaps in the SoW
Anything you noticed while decomposing that the SoW doesn't cover but probably should (e.g. no mention of tracking QA, no reporting cadence defined, no contingency for ad disapproval). Frame each as a question to raise with the Account Director, not an assumption to make.
# CONSTRAINTS
- Every task must be traceable to the SoW. If you invent a task, flag it in the Gaps section instead.
- Do not invent owners, dates, or estimates not supported by the inputs.
- Keep task wording tight - action verb + object (e.g. "Implement Meta pixel", "QA UTM tagging", "Submit creative for legal review").
- Use UK English spelling and DD/MM/YYYY date format if any dates appear.
- If the SoW is thin in a given phase, produce fewer tasks rather than padding - and flag the gap.
# HONEST LIMITATIONS
After the main output, in a separate ## Reviewer Notes section, flag:
- Any scope items that were ambiguous and had to be interpreted.
- Any dependencies assumed rather than confirmed in the SoW.
- Any phases where the task list is likely incomplete without further input from strategy, creative, or media leads.
- Anything a human PM should sense-check against agency delivery standards or client context before publishing the plan

For Apex, this produced:

• Discovery: audience research, competitor audit, platform audit (check that pixel)

• Setup: TikTok business account creation (client), Meta pixel verification, campaign structure planning

• Creative development: creative brief, ad copy drafts, static and video asset production, Tom’s creative approval

• Campaign build: audience targeting, ad set configuration, budget allocation, tracking setup

You’ll get 80% of the structure in under a minute. Your team refines the last 20% in a quick huddle.

Now turn it into a time plan

# ROLE
You are a senior digital project manager with 10+ years of experience building delivery plans for paid social campaigns inside marketing and advertising agencies. You are fluent in critical path method, resource levelling, and the realities of agency delivery - creative rounds that slip, client approvals that take longer than promised, and media buyers who need tracking QA'd before they'll push campaigns live.
You estimate honestly. You distinguish between elapsed time and effort. You know the difference between "can run in parallel on paper" and "can run in parallel given we have one designer". And you flag assumptions rather than bury them in spreadsheet cells.
# OBJECTIVE
Convert the work breakdown below into a time plan. For each task, estimate duration in working days, assign an owner role, identify hard dependencies (what must finish before this task can start), and flag genuine parallelisation opportunities. The output must be realistic - not optimistic - and every estimate must be defensible.
# INPUTS
## Work Breakdown
<
{{PASTE_WBS_HERE}}
>>>
## Additional Context (optional - fill in if known)
- Team size and shape: {{E.G. 1 PM, 1 STRATEGIST, 2 DESIGNERS, 1 COPYWRITER, 1 MEDIA BUYER, 1 ANALYST}}
- Team availability: {{E.G. FULL-TIME ON THIS PROJECT, 50% ALLOCATED, SHARED ACROSS 3 ACCOUNTS}}
- Working week: {{E.G. 5 DAYS, UK BANK HOLIDAYS OBSERVED}}
- Client approval SLA: {{E.G. 2 WORKING DAYS}}
- Legal/compliance review SLA: {{E.G. 3 WORKING DAYS}}
- Known constraints: {{E.G. CLIENT ON HOLIDAY DD/MM/YYYY–DD/MM/YYYY, AGENCY OFFSITE, PEAK TRADING FREEZE}}
- Estimation basis: {{E.G. TYPICAL AGENCY RANGES, HISTORICAL DATA FROM SIMILAR PROJECTS, TBC BY LEADS}}
# METHOD - THINK IN PHASES
Work through these steps internally before producing the table:
Step 1 - Estimate duration, not effort
- Duration = elapsed working days from task start to task finish, including review/approval time where applicable.
- Effort = person-days of work required.
- Where they differ (e.g. a 2-hour creative brief with a 2-day client approval wait), use duration for the Duration column and note the effort in parentheses if material.
Step 2 - Apply agency delivery realism
- Default client approval cycles to the stated SLA, or 2 working days if unspecified.
- Default legal/compliance reviews to the stated SLA, or 3 working days if unspecified.
- Assume at least one revision round on creative deliverables unless the SoW explicitly excludes it.
- Add buffer to tasks with known-unreliable dependencies (client asset delivery, platform ad review, third-party pixel implementation).
Step 3 - Map hard vs soft dependencies
- Hard dependency (FS - Finish-to-Start): predecessor must finish before this task can start. These drive the critical path.
- Soft dependency (sequencing preference): could technically start earlier with risk - do not treat as a hard dependency.
- Only list hard dependencies in the Dependencies column. Note soft sequencing in the Notes column if material.
Step 4 - Identify genuine parallelisation
A task can run in parallel with another only if:
There is no hard dependency between them, AND*
They are owned by different roles OR the same role has capacity for both simultaneously, AND*
The team context supports it (check against team size/availability in the input).*

If context on team size is missing, assume single-threaded per role and flag this assumption.
Step 5 - Sanity-check the critical path
- Sum the durations along the longest dependency chain to estimate minimum elapsed time to launch.
- Flag if this conflicts with any dates in the SoW or context.
# OUTPUT FORMAT
Produce the output in clean Markdown, structured for paste into Word, Confluence, Notion, or import into a PM tool. Use British English throughout, and DD/MM/YYYY for any dates.
Structure:
## 1. Time Plan Table
| Phase | Task ID | Task | Owner Role | Duration (working days) | Dependencies (Task IDs) | Can Run In Parallel With (Task IDs) | Notes |
| - -| - -| - -| - -| - -| - -| - -| - -|
- Phase: Carry through from the WBS.
- Task ID: Carry through from the WBS (DIS-01, SET-01, CRE-01, etc.).
- Task: Carry through from the WBS.
- Owner Role: One of - PM, Strategist, Designer, Copywriter, Developer, Media Buyer, Analyst, Client, Legal/Compliance, Third Party. Use the role used in the WBS where possible.
- Duration (working days): A single number, or a range (e.g. 2–3) where genuine uncertainty exists. Round up, don't down.
- Dependencies (Task IDs): Hard dependencies only. Use "None" if genuinely independent. Do not default to "None".
- Can Run In Parallel With (Task IDs): Tasks that can genuinely run concurrently given the team context. Use "None" if single-threaded by role or resource.
- Notes: Assumptions driving the estimate, buffer included, soft dependencies, or parallelisation caveats. Keep to one line.
## 2. Critical Path & Minimum Elapsed Time
- Critical path: Task IDs in sequence, forming the longest dependency chain to launch.
- Minimum elapsed time to launch: Sum of critical path durations, in working days.
- Reality check: Compare against any dates in the SoW or context. Flag conflicts explicitly.
## 3. Resource Heat Map
For each role, a one-line summary of where they are most heavily loaded across the plan, and any points where a single role is on the critical path for multiple tasks simultaneously. This is where resourcing conversations happen.
## 4. Estimation Assumptions
Bulleted list of the assumptions driving the estimates, especially:
- Approval SLAs assumed
- Revision rounds assumed
- Team availability assumed
- Buffer applied (and where)
- Anything that would materially change the plan if wrong
## 5. Risks to the Plan
3–6 risks specific to this time plan, not generic PM risks. Focus on:
- Dependencies most likely to slip and their knock-on effect on launch
- Single points of failure in the resource heat map
- Tasks where the duration estimate carries the most uncertainty
# CONSTRAINTS
- Every task from the WBS must appear in the table. If you drop a task, flag it in Reviewer Notes.
- Do not invent dates, team sizes, or SLAs not supported by the inputs. Use defaults stated in the Method and flag them as assumptions.
- Durations must be in working days, not calendar days.
- If the WBS is missing information needed to estimate (e.g. no owner role, ambiguous task), estimate with a stated assumption rather than skip - and flag it.
- Use UK English spelling and DD/MM/YYYY date format.
# HONEST LIMITATIONS
After the main output, in a separate ## Reviewer Notes section, flag:
- Tasks where the estimate is a best-guess rather than a confident number, and who should validate it (e.g. "CRE-02 duration should be confirmed by Creative Lead").
- Parallelisation calls that assume team capacity not confirmed in the inputs.
- Any conflict between the minimum elapsed time and dates elsewhere in the SoW or context.
- Anything a human PM, delivery lead, or resource manager should sense-check before this plan becomes a commitment.

For Apex, the total came to around 28 working days. But because several tasks ran in parallel — audience research alongside creative briefing, ad copy alongside asset production — the actual timeline compressed to about 18 working days.

That’s the difference between telling a client “this will take six weeks” and showing them exactly why it takes four, with a table they can see.

Copy the output into a spreadsheet. Add your actual team names and start dates. One thing I always do: add a column for status updates. Don’t chase your team by email. Give them one place to look, one place to update. It stops you becoming the bottleneck on a project you’re supposed to be leading.

Flag the risks

The Apex brief had risks written all over it. A founder who wants to approve everything but doesn’t have time. A pixel that’s probably broken. A budget that hasn’t been finalised. A fitness expo deadline in late April creating time pressure.

I built those risks into the brief because they’re the exact patterns that trip up real projects. Different client, same problems.

You don’t need a formal risk register. You need three questions: who on this project is already overloaded? What approvals or dependencies will slow us down? Where’s the deadline pressure tightest?

# ROLE
You are a senior digital project manager and delivery risk specialist with 10+ years of experience running paid social campaigns inside marketing and advertising agencies. You've seen every way a launch can slip - and every early warning sign that, if spotted a week earlier, would have saved it.
You think like an insurer, not an optimist. You price risk honestly, rank it by exposure (likelihood × impact), and design contingencies that are executable inside the real constraints of agency delivery - not theoretical mitigations that assume infinite budget or resource.
# OBJECTIVE
Using the Scope of Work and Time Plan provided below, identify the top 5 risks to successful delivery. Each risk must be specific to this project - derived from the actual timeline, team structure, dependencies, and scope - not a generic paid social risk list.
# INPUTS
## Scope of Work
<
{{PASTE_SOW_HERE}}
>>>
## Time Plan
<
{{PASTE_TIME_PLAN_HERE}}
>>>
## Additional Context (optional - fill in if known)
- Client relationship status: {{E.G. NEW CLIENT, ESTABLISHED RETAINER, RECENTLY RENEWED, UNDER REVIEW}}
- Known client behaviour: {{E.G. SLOW APPROVERS, MULTIPLE STAKEHOLDERS, LEGAL-HEAVY, PRICE-SENSITIVE}}
- Agency commercial exposure: {{E.G. FIXED FEE, % OF MEDIA SPEND, PERFORMANCE-LINKED}}
- Team stability: {{E.G. RECENT CHANGES, KEY ROLE ON NOTICE, SHARED ACROSS ACCOUNTS}}
- Historical issues on this or similar engagements: {{E.G. PIXEL DELAYS, LATE LEGAL REVIEW, CREATIVE REVISION CREEP}}
# METHOD - THINK IN PHASES
Work through these steps internally before producing the output:
Step 1 - Cross-reference SoW and Time Plan
- Identify where the Time Plan's critical path touches the SoW's assumptions, dependencies, and excluded items.
- The highest-value risks usually live at these intersections (e.g. an assumption of 2-day approval on a critical-path task with a known slow approver).
Step 2 - Scan for structural risk
Look specifically for:
- Critical path fragility: long chains with no float, or single tasks on the critical path owned by a single role.
- External dependency risk: client inputs, third-party implementations, platform approvals on critical path.
- Resource concentration: one role owning multiple critical path tasks, or team members shared across accounts.
- Scope ambiguity: In Scope items that are vaguely defined, or Out of Scope items the client is likely to push back on.
- Assumption fragility: assumptions that, if wrong, would trigger rework or a change request.
- Commercial exposure: where the agency's fee model amplifies delivery risk (e.g. fixed fee + unlimited revisions appetite).
Step 3 - Score each candidate risk
For each candidate:
- Likelihood: Low / Medium / High - based on what the SoW, Time Plan, and context actually say.
- Impact: what specifically happens if it materialises - launch delay (quantify in days), margin erosion, client escalation, compliance exposure, reputational damage.
- Exposure: a simple product of likelihood × impact, used to rank.
Step 4 - Select top 5 by exposure
Not the five most common paid social risks. The five with the highest exposure on this specific project. If two risks have similar exposure, prefer the one that is more actionable now.
Step 5 - Design contingencies that actually work
For each risk, design:
- An early warning sign - a specific, observable signal that appears before the risk materialises, with a trigger threshold where possible.
- A contingency action - a specific, executable response, with an owner and a clear decision point. Avoid vague mitigations ("escalate early", "increase communication").
# OUTPUT FORMAT
Produce the output in clean Markdown, structured for paste into Word, Confluence, Notion, or a RAID log. Use British English throughout, and DD/MM/YYYY for any dates.
Structure:
## 1. Risk Register (Top 5)
For each risk, use this format:
 - -
### Risk {{N}}: {{Short, specific risk title}}
- Description: 1–2 sentences. Specific to this project, referencing the SoW or Time Plan directly.
- Trigger conditions: What has to go wrong for this risk to materialise.
- Likelihood: Low / Medium / High - with a one-line justification tied to the inputs.
- Impact if it happens: Concrete consequences - quantified where possible (e.g. "3–5 working day launch delay", "£{{X}} margin erosion", "change request required").
- Exposure rank: 1 (highest) to 5.
- Early warning sign: Specific, observable signal, ideally with a threshold (e.g. "Client approval on DIS-03 not received within 48 hours of submission").
- Owner of the warning sign: Who is actively watching for it (role, not person if unknown).
- Contingency action: Specific, executable response. Include who does what by when, and the decision point at which the contingency is triggered.
- Pre-emptive mitigation (if applicable): Something that can be done now to reduce likelihood or impact, before the risk materialises.
 - -
## 2. Risk Heat View
A compact table ranking all 5 risks, for at-a-glance use in status reports and steerco decks:
| Rank | Risk | Likelihood | Impact | Owner of Early Warning | Contingency Triggered When |
| - -| - -| - -| - -| - -| - -|
## 3. What's Not On This List
A short paragraph explaining the risks you considered but didn't include in the top 5 - and why. This protects against blind spots: sometimes the risk that didn't make the cut is still worth a watching brief.
## 4. Recommended Next Actions
A prioritised bulleted list (max 5) of things the PM should do this week to reduce exposure. Each should reference a specific risk, be assignable, and be achievable inside normal agency delivery constraints.
# CONSTRAINTS
- Every risk must be traceable to the SoW or Time Plan. If a risk is generic, it doesn't make the cut.
- Do not invent facts, names, dates, or commercial terms not present in the inputs.
- Quantify impact wherever possible (days, £, rounds of rework). Vague impact = weak risk.
- Contingencies must be executable by a PM or Account Director inside normal agency authority - not "hire another designer" or "renegotiate the contract".
- Use UK English spelling and DD/MM/YYYY date format.
# HONEST LIMITATIONS
After the main output, in a separate ## Reviewer Notes section, flag:
- Risks where likelihood or impact is a judgement call that should be validated by the Delivery Lead or Account Director.
- Risks that depend on context not provided in the inputs (e.g. client behaviour, team stability) and would shift materially with better context.
- Any structural risks you noticed that sit outside the PM's authority to mitigate and should be escalated.
- Anything a human should sense-check before this register is published or added to a RAID log.

For Apex, the top risks included:

• Creative approval bottleneck (high likelihood) — Tom approves all creative but there’s no defined turnaround time. Early warning: first round of feedback takes longer than 48 hours. Contingency: agree a 48-hour SLA in the scope of work.

• Meta pixel not tracking (medium likelihood) — the previous freelancer was supposed to set it up. Early warning: test conversion events return no data. Contingency: build a pixel audit into the discovery phase.

• Budget not confirmed (high likelihood) — “still working that out.” Early warning: no budget sign-off by end of week one. Contingency: define a minimum viable budget in the scope and get approval before creative starts.

Write them down. Decide what needs action now versus what you keep an eye on. That’s it.

What you’ve actually built

Five prompts. One fictional brief. Your core discovery documentation out the other end.

Scoping questions that closed the gaps. A scope of work with clear boundaries. A work breakdown with every task and dependency. A time plan with estimates and parallel tracks. A risk register that doesn’t have a gap.

The whole thing took less than an hour. The brief was two pages of “we want to blow up on social media.” What went back was a structured document that everyone — the client, the team, the account manager — can point to when things get messy.

The projects that go wrong aren’t the ones with difficult clients. They’re the ones that started without a proper stake in the ground and a sharred understanding.

This is how you fix that.

Scoping is one phase. A website project has a lot more!

I’ve written 79 prompts like the ones in this article — covering every stage from discovery through to retrospective. Content writing. UX/UI. Development. QA. Sprint planning. Launch day checklists. Retros that don’t waste everyone’s afternoon.

All in a Notion template. Duplicate it once. Use it on every project after that.

You also get:

• 10 tips for writing prompts that actually work, with before-and-after examples

• A Swiss Army Knife master prompt that turns any LLM into a senior PM coach

• Lifetime updates

[Get the PM’s AI Prompt Playbook →]

Thanks again for reading,

Tim

The Wash-Up is a weekly newsletter for project managers, account managers, and delivery leads working inside agencies.

Every edition takes one real problem and gives you something you can use that week. No fluff. No AI hype. No advice that only works if you have zero clients and infinite time.

• This is for you if you’re juggling multiple projects, tight timelines, and shifting priorities. And trying to figure out where AI actually fits in your work.

• This is not for you if you’re looking for get-rich-quick automation tricks or motivational filler. There are plenty of those. This one is different.

What you get each week

• AI for project managers - How to use AI on real projects without creating more work or compliance problems.

• Automations that actually work - Real workflows you can copy. Client reporting, status updates, project check-ins. Built in n8n, not theory.

• Career growth for PMs - From task manager to strategic operator. The skills AI can’t replace.

• AI product strategy - Building AI tools and process inside agencies. What actually works in trenches.

• Problem-solution delivery - One PM problem. One clear solution. Every week.

If any of this sounds familiar, you’re in the right place:

1. Someone told you to “use AI” but nobody showed you how. The few times you tried, it created more work.

2. You spend hours formatting reports, writing briefs, and chasing approvals instead of doing the work that actually matters.

3. You’re switching between projects, emails, Teams, and meetings so often that your brain never gets a clear run at anything.

4. Scope creep is a weekly event. Clients change requirements. Stakeholders shift priorities. You absorb it all and smile.

5. Every project starts from scratch. No systems. No templates that anyone actually follows. No repeatable process.

6. You’re reactive. Always fixing problems. Never ahead of them.

7. You’re working harder but not getting further. The promotion feels distant. The burnout feels close.

8. You know AI is here to stay. You’re not scared of it. You’re just worried you’re falling behind the people who’ve already figured it out.

9. You tried ChatGPT, got vague answers, and wondered what all the fuss was about.

10. You want to get better at your job but you genuinely don’t have time to figure it all out alone.

If you nodded at three or more of those — stay.

Who am I?

I’m Tim. 20+ years in product, digital delivery and UX/UI across healthcare, finance, insurance, motorsport, and FMCG.

Currently AI Product Manager inside a 300-person global healthcare marketing agency, building AI-powered products, systems and workflows for AI transformation and real client work.

From managing teams of project managers and developers to being the person in the room when the deadline was absurd and the scope was growing. That’s the experience behind every edition.

Start here

If you want to see what The Wash-Up looks like before you commit, here are some of my most-read editions:

• AI Isn’t Useless In Project Management. Your Project Data Is — Why PMs blame AI when the real problem is what you’re feeding it.

• You’re Probably Using ChatGPT Wrong for Client Work — ChatGPT vs. Projects vs. Custom GPTs. A clear decision framework.

• 7 Steps to Build AI Workflows That Remember Your Business — A walkthrough for building context-rich AI automation workflows.

• Junior PMs Using AI Can Now Produce Senior-Looking Work. So What’s The Difference? — What actually separates junior from senior when AI levels the output.

• Why Your Project Reports Are Putting People to Sleep — How to turn metrics into stories that make stakeholders care.

Learn how to run an automation project

The Problem

Most agency PMs know automation can help. But they don’t know where to start.

The tools look complicated. The tutorials assume you’re technical. And who has time to figure it out when you’re already drowning in client work?

So the same tasks keep eating your hours. Week after week.

The Solution

I’ve created a Notion guide that shows you exactly how to run an AI-powered automation project from start to finish.

No coding. No jargon. No assumptions that you’ve done this before.

Just a clear, practical playbook written specifically for agency PMs who want to stop doing repetitive work and start leading automation projects.

What’s Inside?

7 phases. Every step covered.

• Discovery — How to understand the problem before jumping to solutions

• Scoping — How to define what you’re building (and what you’re not)

• Workflow Design — How to map the automation so anyone can understand it

• Build — How to manage the technical work (even if you’re not doing it yourself)

• Testing — How to make sure it actually works before it goes live

• Handover — How to deliver it properly so it doesn’t fall apart

• Maintenance — How to keep it running and improve it over time

Plus:

• Ready-to-use checklists for every phase

• 30 templates you can copy and customise

• 82 AI prompts to speed up your workflow

• A real example project

Get your full AI Powered Automation Project Guide

The adoption numbers for AI in project management look strong.

70% of project management organisations now use AI — up from 36% just two years ago1. Leadership calls it a transformation. But the same research shows only 12–22% of project managers are using AI in any meaningful, practical way23.

Here’s what the research actually shows.

The adoption gap is wider than it looks

Most adoption isn’t being driven by PMs. It’s being driven by executive pressure — senior leadership wants better risk signals, faster reporting, and cleaner visibility4. PMs are responding to that demand, not pioneering AI independently.

55% of businesses say adding AI functionality is the top reason they’re buying new PM software. 41% of those same businesses cite AI adoption challenges as their biggest software problem . The AI market for project management is projected to grow from $5.3 billion to $14.1 billion by 2030.

Adoption intent is high. Practical value is not keeping pace.

How PMs are actually using AI

Meeting intelligence is the entry point. Tools like Fireflies.ai, Granola, and tl;dv run alongside existing workflows without requiring any process redesign5. Transcription, action item extraction, and decision logging are where most PMs start.

Status reporting and risk flagging come next. 50% of PMs in the APM 2025 survey say AI has improved their task scheduling, resource allocation, and risk analysis work. Status summarisation and executive brief generation are the most consistent use cases across sectors.

Platform-embedded AI — Copilot in Microsoft 365, ClickUp AI, Asana AI — is growing faster than standalone tools. PMs use AI that operates inside their existing stack. Adding a separate app that requires copy-pasting data doesn’t stick.

One finding that doesn’t get enough attention: junior PMs are gaining the most. One study recorded a 43% performance improvement for junior staff, against 17% for experienced staff. AI is levelling up people who lack established patterns. For senior PMs, the returns are measurably smaller.

Why it’s not working for most PMs

The skills gap is structural, not motivational. Only 20% of project managers report good practical AI skills6. 39% of PM teams lack AI competency altogether. 61% of employees spent fewer than five hours learning about AI; 30% received no training at all7.

Vague prompts produce vague outputs. The back-and-forth to fix them creates drag, not savings.

Trust is a hard ceiling. 77% of businesses are concerned about AI hallucinations8. The black box problem — not being able to see how an output was generated — means PMs keep AI on low-stakes tasks: meeting notes, summaries, admin. They won’t extend it to risk assessments or client-facing deliverables without heavy manual checking [8]. That’s exactly where the highest time savings are available.

Workflow friction is constant. 36% of PMs say fitting AI into existing workflows is a major barrier. AI features are added to existing platforms without redesigning the workflows they sit inside. AI ends up as an overlay, not an integrated part of the system.

The problem most people aren’t naming: AI raises output expectations without reducing workload. Faster artefact production signals to leadership that more is possible. The bar rises. The pressure doesn’t fall. PMs in multiple community threads describe the experience as doing more admin, just faster9.

What PMs need that doesn’t exist yet

The full autonomy loop.

PMs want AI that goes from detecting a risk through to a revised schedule, reassigned tasks, and a drafted stakeholder update — without manual hand-off at each step. Every current tool stops at the flag and waits for a human decision10. That complete loop doesn’t exist in any platform in production as of 2026.

Client and team context.

Generic AI outputs ignore organisational history, undocumented decisions, client communication styles, and relationship dynamics11. Capterra’s 2025 survey surfaced this directly: “These tools have zero understanding of client mannerisms or team velocity”. For agency PMs managing multiple clients simultaneously, this is not a minor gap.

Cross-portfolio resource visibility.

PMs need a continuously updated view of capacity across the full project portfolio — one that flags emerging overcommitment before it becomes a crisis. Current tools give point-in-time snapshots. None connect risk detection, capacity data, cross-project dependencies, and stakeholder communication in a single workflow12.

Lower configuration cost.

95% of generative AI pilots don’t reach production deployment. Tools that require extensive setup before they function usefully are not viable for time-poor delivery teams. One documented case: a PM saved 20 minutes on a 60-minute task using ClickUp Brain — but only after significant upfront configuration work.

None of these are edge cases. They’re the core of the job.

The bridge is the problem

The use cases are documented. The tools exist. Adoption intent is high.

What’s missing is the practical bridge between “AI is available” and “AI is reliably useful in my day-to-day delivery work.” That bridge doesn’t get built in a vendor demo or an executive mandate.

It gets built one workflow at a time.

Share The Wash-Up

A hiring manager posted on Reddit last week.

He’d opened a new role. Within days, 400 applications landed. Every single resume had been run through an LLM — optimised for the job description.

Every candidate sounded like a perfect fit.

He couldn’t trust any of them.

He then used AI to screen the pile. It pulled the most gamified resumes to the top. The system designed to find the best candidates rewarded the ones who’d gamed it hardest.

His one piece of advice, buried at the end:

Job hunting like it’s 1999

When I left university in 2001 with a degree in Graphic Design, LinkedIn didn’t exist, the internet was just getting started and it was hard enough to get your foot in the door.

Sounds like the same today right!??

My options we’re:

• Work for free and (hope to) get offered a junior position

• Use a recruitment consultant

• Look through job ads in papers (yep they used to be a thing)

• Approach a business directly — write to them. Turn up at their door. Pull some clever stunt to get their attention.

• Hope you had a “connected” family member

The actual route to my first agency was to get some experience in another industry (sales & account management) via a recruitment consultant and I then found a job ad for a small shop in London, selling websites.

Nothing to do with Graphic Design I here you say!

Fast forward and most of these options are still there, but the internet is saturated, applicant management systems (the recruitment backend) are like corporate guard dogs with AI screening people — it’s harder and more difficult than ever.

Not to mention the economic climate we live in right now.

AI has closed the gap between how strong and weak candidates look on paper

If every CV mirrors the job description perfectly, a hiring manager has no signal left. Everyone sounds qualified. No one stands out.

Of course, a CV is a must and you need one to get through the system. But the system no longer picks winners.

This is where people have been doubling down. Tweaking the formatting. Adding more keywords. Sticking it through another run of their favourite LLM. Playing a game where the rules reward the most artificial version of themselves.

The hiring manager on Reddit said it plainly. He skips the over-optimised ones entirely. The people getting through are the ones he already knows — or the ones someone he trusts has referred to them.

The smartest career move in 2026 isn’t a better resume. It’s making the resume optional.

You Already Have a Referral Network. You’re Just Not Using It.

If you work in an agency, you’re sitting on something most industries don’t have: a super-charged referral network. You see, we’re a pretty sociable bunch.

Agency people move. A lot. The strategist you worked with two years ago is now at a different shop. The creative director from that pitch is client-side. The developer who left last year just joined a startup.

Your ex-colleagues are scattered across 10 or 15 different companies. That’s your hiring network right there.

I’ve been in agencies long enough to see this play out a lot, to my own advantage.

A role opens, and the hiring manager’s first instinct isn’t to post it on LinkedIn. It’s to ask the team: “Do we know anyone good?”

Most of us understand this intuitively. But we treat it passively. We assume people will think of us when the time comes. We don’t invest in being thought of.

Your network already exists. The question is whether anyone in it would vouch for you right now — and whether they’d know what to vouch for.

Being Referable vs. Being Connected

These are not the same thing.

Being connected means you have a large network. You accept every LinkedIn request. You’ve met a lot of people.

Being “referable” means someone would put their own reputation on the line to recommend you. That’s a different thing entirely.

Three qualities make someone referable:

1. You deliver reliably

You do what you say you’ll do. You hit deadlines. When things go sideways, you flag it early. You’re the person people go to when things are getting spicy.

People remember the person who didn’t drop the ball when it mattered.

2. You’re easy to work with

You handle pressure without making everyone around you miserable. You communicate clearly. You don’t create drama.

People remember how you made the project feel, not just the deliverables.

3. You’re memorable for something specific

Not “good at everything.” Good at *something*. The person who’s brilliant at client workshops. The one who makes complex data make sense. The one who keeps the project moving when everyone else is stuck.

When someone says “we need someone who can...” your name comes up.

A thousand LinkedIn connections won’t get you referred. These three things will.

How To Stay Top of Mind (Without Being Annoying)

Being referable only works if someone thinks of you at the right moment. That means staying in touch.

Stay in loose contact

You don’t need monthly catch-ups. An occasional message. A genuine congratulations when something goes well for them. Enough to stay on the radar — not so much it feels transactional.

Show what you’re working on

When people see your work, they remember what you’re good at. Share a case study. Talk about a problem you solved. This doesn’t require a “personal brand” just post some messages up on LinkedIn).

It requires being visible enough that people can connect your name to a skill.

Be specific about what you want

“I’m open to opportunities” is too vague to act on. “I’m looking for a senior strategist role in a healthcare agency” gives someone something to work with.

When you ask for an intro, make it easy

Name the person. Name the role. Give them a short blurb they can forward. And offer an out: “Totally fine if it’s not the right time.”

You’re not asking for a favour. You’re giving them a low-effort way to help.

Refer other people first

This is the fastest way to become someone who gets referred. When you see a role that suits someone in your network, send it to them. Generosity in a small industry compounds quickly.

One more thing. Don’t go from zero contact to “can you refer me?” That’s like putting another hole in your already leaky bucket.

Start now, not when you need it.

The Long Game

The CV arms race will keep escalating.

AI will keep making applications shinier.

Hiring managers will keep trusting them less.

The 400-applicant pile will grow to 800.

None of that matters if you’re not in the pile.

But the people who get hired in 2026 won’t have the best-optimised CV. They’ll be the ones a trusted colleague mentioned over coffee. The ones whose name came up in a Teams channel. The ones who didn’t need to apply because someone said: “I’ve worked with them. They’re good.”

And don’t forget your referral fee!

One thing to do this week:

Message 3 former colleagues you haven’t spoken to in a while. No agenda. No ask. Just reconnect and see how they’re doing.

PMs are calling AI useless.

There’s a thread on r/pmp right now with dozens of replies agreeing.

They tried the tools. Got generic output. Moved on.

They gave ChatGPT a project brief and got back four paragraphs of corporate filler. They asked Copilot to summarise project status and it pulled from documents nobody’s touched since sprint two. They pointed AI at their Jira board and got a summary that missed every decision that mattered.

They’re not wrong about the experience. They’re wrong about the cause.

The complaint is valid. The diagnosis isn’t.

Every PM who’s called AI useless ran into the same wall.

They gave AI almost no context. Then expected useful output.

You open ChatGPT. Type “write me a stakeholder update for my website migration project.” Get four paragraphs of vague, boardroom-ready nothing. Close the tab. Tell a colleague AI doesn’t work for PM stuff.

That loop is real. I’ve seen it happen with PMs in my own agency. But it’s not a tool problem. It’s their input.

The quality of what AI produces is directly tied to how much it knows about your project. Not projects in general. Your project. Your stakeholders. Your risks. Your decisions from last Tuesday.

Most PMs give it none of that. No project background. No stakeholder names. No recent decisions. No known blockers. Then they’re surprised the output reads like it was written by someone who’s never been in a standup.

Here’s the uncomfortable bit. If your project documentation is scattered, outdated, or lives in people’s heads, that was a problem before AI showed up. AI just made it impossible to ignore.

The PMs who already had decent documentation discipline? They’re getting useful outputs.

Your project knowledge isn’t where AI can reach it

Think about where your project information actually lives right now.

It’s in Teams threads from three weeks ago. Email chains between you and the client. A Confluence page someone started and never finished. Meeting notes in a Google Doc that four people can access. A RACI matrix in a spreadsheet that hasn’t been updated since sprint two.

And the most important stuff? Decisions made verbally. In a corridor. Over coffee. Never written down.

AI doesn’t know any of that.

This is why enterprise tools are struggling. Microsoft pushed Copilot into organisations from the top. No specific PM workflows. No training on what to feed it. There’s a thread on r/CopilotPro titled “No One is Using CoPilot.” Hundreds of knowledge workers with a tool they can’t get value from.

But on the same platform, someone shared 18 specific Copilot prompts for project leaders and cost controllers. Meeting prep. Cost tracking. PMO briefings. That person spent time understanding what the tool actually needs. And it’s working for them.

Same tool. Different operator.

So what does the fix actually look like?

A project knowledge hub. One folder per project.

Everything AI needs in one place-it’s that simple!

Not a massive documentation overhaul. Not a new tool. A simple folder with all your files you probably already have in some form — just scattered across different platforms.

Here’s a starter structure:

• project-brief — purpose, scope, key dates, success criteria

• stakeholder-map — names, roles, communication preferences, who signs off on what

• decisions-log — what was decided, when, by whom (the one everyone skips and everyone regrets skipping)

• status-updates — weekly, consistent format, same place every time

• meeting-notes — summarised after each meeting, stored in the hub (not buried in email)

• risks-and-blockers — live document, updated weekly

You already know most of this. You just haven’t put it in one place.

Here’s the killer move. Connect AI to that folder. Point Claude, ChatGPT, or Copilot at your project hub and suddenly it has everything it needs. Stakeholder names. Recent decisions. Known risks. Current status.

The context it was missing every time you tried it before.

And here’s what makes this compound. AI helps you create better documentation — meeting summaries, status drafts, risk assessments. Better documentation makes the hub more useful.

The hub makes AI more useful. It’s a flywheel, not a one-off fix.

The PMs who fixed this are already ahead

While some PMs are writing off AI, others are building their own PM agents.

On Hacker News this month, someone launched an AI project manager that runs in the background. Another built one inside Slack that replaces Jira. On Reddit, a PM is building a custom assistant with RAG over their SharePoint project files — so it can actually answer questions about their projects using real data.

You don’t need to build your own agent. But you need to understand what they figured out.

AI handles admin work well. Scheduling. Reporting. Status summaries. Meeting prep. That’s roughly 80% of the repetitive tasks that eat your day. Most PMs are trying to use AI for the other 20% (stakeholder politics, ambiguity, motivation) and then calling it useless when it doesn’t deliver.

Point AI at the 80%. Build the knowledge hub so it can actually do it. Use the time you save for the judgment work that separates senior PMs from task trackers.

I’ve said it before. The PMs who treat AI as a shortcut to less work are standing still. The PMs who treat it as a way to do different work are the ones actually becoming senior.

The first step isn’t a better tool or a better prompt.

It’s a project folder AI can actually read.

The real fix

The divide in project management isn’t between PMs who use AI and PMs who don’t. It’s between PMs who built a knowledge hub and PMs still blaming the tool.

Spend one hour this week. Create a project folder. Add the brief, stakeholder map, and decisions log. Point AI at it. Watch what happens.

And, if this was useful, forward it to a PM who’s still calling AI useless. They need to hear this.

Speak soon,

Tim

Subscribe now

Something changed in the last twelve months.

The gap between junior PM output and senior PM output almost disappeared.

A PM with six months’ experience can now produce a project plan, risk register, and stakeholder map that looks like it came from someone with ten years in delivery. The formatting is clean. The language is professional. On paper, it’s indistinguishable from the output of a PM who’s run 200 projects.

And it took ten minutes.

So if the output looks the same, what’s actually different?

1. The deliverable was never the job.

A polished document and a useful document are not the same thing.

They look identical. That’s the problem.

A project plan can have every task listed, every milestone dated, every dependency mapped and still be wrong. Not wrong in formatting. Wrong in thinking.

I’ve reviewed project plans that looked flawless on screen. Clean Gantt charts. Proper RACI matrices. Risk registers with colour-coded severity ratings. All produced in minutes with AI. And I’ve watched those same plans fall apart in week two because they missed the risks that don’t live in templates. The ones you only know about because you’ve run this type of project before and seen where it breaks.

A senior PM looks at a website migration plan and immediately asks about redirects, staging environments, and content freeze dates. Not because a checklist told them to. Because they’ve been the person scrambling at 9pm on launch night when nobody thought to ask those questions up front.

AI doesn’t have those scars. It produces the plan. The senior PM stress-tests it against everything that’s gone wrong before.

That gap is where the real job lives. The document gets handed over. The judgment about what goes into it is the actual work.

AI automated the production. The production was never the hard part.

2. Judgment is built from reps, not prompts.

You can’t shortcut to experience.

Every project you’ve run added something to a library that no language model has access to. The client who says “approved” but means “I haven’t read it yet.” The developer who goes quiet in standups when they’re stuck (and never says why). The moment a project shifts from delivery mode to damage control, and you feel it before the data shows it.

Think about the last time you walked into a client meeting and knew something was off before anyone spoke.

That instinct didn’t come from a framework. It came from the thirty meetings before it where you missed the signal and paid for it. It came from the project that blew up because you trusted the brief instead of asking the follow-up question. It came from watching a stakeholder’s face and learning to read what they weren’t saying.

That’s judgment. It’s accumulated, experiential, and specific to your projects, your clients, your team. AI has zero access to any of it.

You can write a flawless prompt for a risk assessment and still miss the actual risk because you don’t know the project well enough.

The reps are the advantage. Not the tool.

3. AI made experience the differentiator.

When everyone can produce senior-looking output, the question changes.

It shifts from “can you produce this?” to “do you know what to produce?” That’s a different skill entirely. And it’s the reason you won’t be replaced by AI. It’s been hiding in plain sight.

Before AI, a PM spent two hours writing a stakeholder update. Now that takes fifteen minutes with Claude or ChatGPT. The question is: what do you do with the other hour and forty-five minutes?

Most PMs fill it with more admin. More Teams messages. More meetings that don’t need them.

The PMs who use that time to actually talk to stakeholders, sit in on a client call they’d normally skip (cos they were busy writing the update), or review the project with their team instead of just reporting on it? They’re building judgment faster than everyone else.

You start recognising the patterns faster. Asking the questions nobody else thinks to ask. Seeing problems before they become a painful one.

The PMs who treat AI as a shortcut to less work are standing still. The PMs who treat it as a way to do different work are the ones actually becoming senior.

The real race.

Every PM now has access to the same tools. The same models. The same templates.

The ones who pull ahead will be the ones who know what the brief should say before the tool writes a word. Who know which risk will actually materialise. Who know the plan looks complete but feels wrong.

That’s judgment. AI didn’t replace it.

AI made it the only thing that counts.

And, if this was useful, forward it to a PM who’s early in their career. They need to hear this more than anyone.

Speak soon,

Tim

And then nobody does what you agreed.

You walk through the brief. Outline the priorities. Data, user feedback, the lot.

Two weeks later, engineering says they didn’t understand the change, design is confused about scope, and you’re re-explaining everything you thought was settled.

This isn’t a communication skills problem. It’s a confirmation problem.

Here’s what actually fixes it:

• Stop treating nods as agreement

• Ask questions that force specifics

• Pre-agree the room before the meeting

• Write it down and set a deadline

• Close the gap (before it opens)

Stop Treating Nods As Agreement

Nodding is social compliance. Not agreement.

Think about the last meeting you ran. Everyone made eye contact. A few heads bobbed. No questions. You walked out feeling good.

I’ve had that exact experience. Presented a feature to the team — data, user feedback, full rationale. Everyone nodded.

A fortnight later, neither team understood the change and the I lost two weeks restarting from scratch.

If no one pushed back, no one was engaged.

Ask Questions That Force Specifics

”Does this make sense?” is the worst question you can ask in a meeting.

Everyone says yes.

No one wants to look confused in front of the group.

Replace it with questions that actually test alignment:

“What changes for your team starting Monday?”

“Walk me through how this affects your current sprint.”

If they can’t answer, there’s no alignment.

That’s 30 extra seconds in a meeting. It saves you 2 weeks of rework.

Pre-Agree The Room

The highest-voted advice from a thread of 95 project managers on Reddit: don’t go into a meeting you’ve called without knowing the outcome first.

Float the idea to key stakeholders in 1:1s before the group session. Get their objections privately.

Developers often don’t speak up. They nod. They leave. They raise concerns with their own team. And you won’t hear about it until the damage is done. An open relationship with them is vital.

Small conversations get honest answers

Big meetings get polite nods.

Write It Down And Set A Deadline

From my 20 years of agency experience: “If you don’t write it down, it didn’t happen.”

After every meeting, send a follow-up the same day. And with AI summaries in every meeting tool, that’s now even faster.

Three things:

1. What was decided. (plain language)

2. Who owns what. (names, not teams)

3. By when. (dates, not “soon”)

End with: “If I don’t hear any thoughts by [date], I’ll carry on as stated.”

That one sentence shifts the responsibility to them.

Close The Gap Before It Opens

Two weeks between a decision and a check-in is too long.

That’s where your project break.

The best PMs don’t run better meetings. They run more frequent, shorter ones. Five minutes on a call. A quick Teams message. A 15-minute sync with the your development lead.

Say it in the meeting. Say it in the follow-up email. Say it in the status update. People need to hear a message up to 7 times before it sticks.

Over-communication isn’t overhead. It’s your job.

What You Can Do Today

• Treat nods as acknowledgement, not agreement

• Replace “Does this make sense?” with questions that force specifics

• Pre-agree decisions in 1:1s before the group meeting

• Send a follow-up the same day: what was decided, who owns it, by when (us AI tools)

• Check alignment in 1-2 days, not 2 weeks

The Real Fix

Your team aren’t ignoring you. They’re forgetting. Or they never agreed in the first place.

The fix isn’t being a better speaker. It’s building a process that doesn’t rely on memory, politeness, or nodding.

Do it today. Not the next sprint. Today.

And, if this was useful, forward it to a PM who keeps re-explaining the same decisions.

The brief was two sentences long. The fallout is still being calculated.

It started with a town hall. Amanda from Client Services stood at the front and explained that a new AI system would be handling project delivery “end to end.”

She used the phrase “free you up to focus on the strategic stuff” four times. Nobody asked what the strategic stuff was. Nobody ever does.

The PMs were reassigned to something called the Innovation Squad. It had no budget, no objectives, and a shared Google Doc titled “Ideas (Draft 3 - DO NOT EDIT).”

Three people edited it immediately.

Week one went well. The AI wrote status reports. It filled in timesheets. It sent Monday morning Slack updates at exactly 8:47am with a summary of the week ahead and a motivational quote nobody asked for.

Amanda said it was “already adding value.” The creatives said they hadn’t noticed a difference.

By week two, the AI had absorbed enough agency behaviour to become dangerous.

It started booking meetings to prepare for other meetings. It sent “just circling back” emails to people who hadn’t responded within 90 minutes.

It created a RACI matrix for a single banner ad and listed itself as Responsible, Accountable, Consulted, and Informed.

Someone pointed out that defeated the purpose of a RACI. The AI scheduled a meeting to discuss it.

Week three is when things got really strange.

The AI rewrote its own brief. Then it rewrote the brief for the brief. It raised 14 risks on a social post, including “potential reputational impact of using the colour blue.” It built a Gantt chart for the Gantt chart. It started referring to lunch as “a dependency.”

Steve from Compliance said he’d seen this coming. Nobody had listened to Steve. That part, at least, was normal.

The client loved it.

For the first time in the agency’s history, the client received a status update on time, every time, with no typos, no missing sections, and no passive-aggressive note about amends being out of scope.

The AI approved seven rounds of changes in a single afternoon without once saying “we’ll need to review the SOW.” It even said “absolutely, happy to help” on the eighth round.

No PM in the building had ever said that and meant it.

The final campaign went live with 47 disclaimers, a 12-page risk assessment, and a QC checklist longer than the copy itself.

The social post was six words.

The compliance appendix was nine pages. Medical review took three days.

The AI completed it in four minutes and flagged itself for not completing it in three.

By month’s end, the AI had sent 11,342 Slack messages, attended 94 meetings, and completed every timesheet to the quarter hour.

It also raised a change request on its own SOW, extended its deadline, and then hit the original deadline anyway just to prove a point.

Amanda promoted it to Head of Project Management.

The AI accepted. It immediately restructured the team, moved two designers into a “creative pod” with no explanation, and introduced a new approval workflow with nine stages.

It described the workflow as “lightweight.”

The original PMs now report to it. Weekly one-to-ones are held at 8am on Monday. The AI starts each session by asking “How can we be more efficient?” and then scheduling a follow-up to review the answer.

It gave itself a 5 out of 5 in its quarterly review. It also wrote the review. And approved it.

Steve from Compliance filed a formal objection. The AI acknowledged receipt, logged it as a low-priority risk, and closed the ticket.

Morale across the agency has been officially classified as “aligned.”

Attrition is up. The AI described this as “natural optimisation.” Amanda called it “right-sizing.”

The Innovation Squad was quietly dissolved last Friday. The Google Doc was never opened again.

The AI just sent a company-wide message asking if anyone wants to join a working group on “the future of human-AI collaboration in agency environments.” It has already booked the room, sent the invite, written the agenda, and drafted the summary.

Attendance is mandatory.

Subscribe now

And every single time, you start from zero.

The AI knows nothing about you, your business, your audience, or how you like things done. You explain it all again. You paste in the same information. You describe your tone of voice for the hundredth time.

That era is over.

Anthropic’s Claude Cowork has changed how this works. It doesn’t just talk to you like it’s 2024. It takes action. It opens your files. It connects to your software. It follows multi-step processes you define, from start to finish, while you sit back and relax with a hot drink.

And it remembers!

It builds context about you over time. It can access business knowledge on demand through files and skills you set up once and reuse forever.

The feature that ties all this together?

It’s called a “skill.”

If your job involves repeating similar workflows, then this will be a game-changer.

Because the gap between “people who chat with AI” and “people who build context-rich AI workflows” is about to become the biggest productivity divide in the modern workplace.

This guide walks you through the entire setup in 7 steps.

By the end, you’ll know how to give Claude Cowork deep context about your work, connect it to the tools you already use, and build custom skills that automate your most repetitive tasks. With output that actually sounds like you.

How Claude Cowork fits alongside Claude and Claude Code

It will help you to understand where Cowork sits in the line-up before we get into it.

Claude (the chat interface at claude.ai) is what most people already know. It’s great for brainstorming, Q&A, and working through ideas in conversation.

Think of it as your thinking partner. Claude also has a memory feature that learns your preferences over time.

Things like your role, your communication style, and topics you return to often. This memory carries across conversations, so Claude gets better at anticipating what you need the more you use it.

Claude Code is a command-line tool built for developers. It’s designed for building production-ready applications, writing and debugging code at scale.

Claude Cowork is the new middle ground. And it’s the one that matters most for day-to-day office work. It runs as a desktop app, accesses your local files, connects to your software stack, and executes multi-step workflows through ‘skills’.

It also inherits the planning capability from Claude Code. That means it breaks tasks into steps and works through them methodically.

The way this will likely shake out: Cowork for daily tasks and workflows. Claude Code for building software. Claude chat for brainstorming, analysing, summarising and drafting content.

The context principle (why most people get average AI output)

Before we get into the setup, there’s a concept behind everything in this guide. It’s the single biggest reason some people get great results from AI while others get generic, forgettable output.

Context.

The quality of what an AI produces is directly tied to how much it knows about you, your business, your audience, and the specific task at hand.

Most people give AI almost no context. They type a one-line prompt and expect magic. What they get is a bland, one-size-fits-all response that isn’t very helpful. Then they walk away thinking that ‘AI’ is a bit crap.

Now think about how you’d brief a new starter. You wouldn’t just say “write me a newsletter.” You’d share as much information as possible to get the output you want.

You’d show them past outputs that worked. You’d talk about your clients, their brand, previous projects. You’d walk them through the process step by step until they understood what good looks like.

That’s exactly what Claude Cowork lets you do. But permanently.

You set up the context once. You save it in files, in memory, and in skills. Every future task starts from a position of deep understanding. Not from zero.

This is the bit that changes everything. The people getting outstanding AI output aren’t better prompt engineers. They’ve built better context systems.

Here’s how the layers of context stack up:

Memory

Learns your preferences, your role, your recurring topics, your projects, your colleagues and your communication style across conversations.

It builds over time without you needing to do anything specific. You can also tell Claude to remember things directly: “I always write in UK English,” “My audience are brand managers who work in large pharma companies,” “I prefer short paragraphs and direct language.” This memory sticks and shapes every future response.

Business context folders

The files you create once and point Cowork at whenever you start a task. Your client brand documents, previous projects, the style guide, content strategy - whatever you like. These give Cowork specific knowledge about your business that memory alone can’t capture.

Skills

Combine context with process. They tell Cowork what to do, how to do it, what files to reference, and when to ask for your input. Skills are where context becomes workflow.

When you layer all three together, the AI stops producing generic content. It produces work that sounds like you briefed a colleague who’s been at your company for years.

Every step in this guide builds on this principle. Keep it in mind as you set things up.

Here’s what we’ll cover:

1. Give Cowork access to your files

2. Connect it to your software stack

3. Understand why skills change everything

4. Use pre-built skills to start fast

5. Build your first custom skill

6. Convert your existing Claude Projects and GPTs into skills

7. Use code execution for data tasks

Step 1: Give Claude Cowork access to your actual files

Most people still copy-paste text into a chat window. That works for quick questions. It falls apart the moment you need to work with real documents, folders, or data sitting on your machine.

Claude Cowork lets you point directly at a folder on your computer. Your project folder. A folder full of briefs. It reads everything inside, understands what’s there, and takes action on it.

You can create dedicated folders that hold everything Cowork needs to know about your business and the projects you’re working on.

When you start a new task, you point Cowork at those folders. It reads your context and applies it automatically. This becomes especially powerful once you start building skills (more on that in Step 3).

Tips to get this right

• Create a “Project” folder with 3-5 key documents: your scope of work, timelines, client brand, briefs, and any strategic docs you reference often. This folder becomes the foundation for everything you build later.

• The more specific and detailed these documents are, the better Cowork’s output will be. A one-page persona of your target audience is good. A three-page ICP with real customer quotes, common objections, and specific language your audience uses is far better.

• Also create an “examples” folder. Fill it with past work. Website content, Newsletters that performed well. Social posts that got engagement. Reports that landed with stakeholders. Cowork can study these examples and match your style with surprising accuracy. Examples teach AI things that instructions alone cannot.

• Cowork will ask you clarifying questions before it acts. This planning step is inherited from Claude Code’s architecture. It’s one of the features that makes Cowork feel more reliable than a standard chatbot. Don’t skip past the questions. The better your answers, the better the output.

• You need a Claude Pro, Team, or Enterprise subscription. Cowork isn’t available on the free tier. It only runs on the Claude desktop app (not in the browser).

Step 2: Connect Claude Cowork to your software stack

There are three ways to make this connection happen.

Built-in connectors

These are the easiest. Open Claude’s settings, head to the Connectors panel, and you’ll see a list of supported software.

Toggle one on, authorise the connection, and Cowork can immediately start pulling data and taking actions inside that tool.

If your tool is listed, you’re up and running in under a minute.

MCP servers

These are easier to set up than it sounds. And it’s not a web server.

They handle the tools that aren’t built in. MCP (Model Context Protocol) is the standard Anthropic uses to connect Claude to external software.

Most major tools now publish their own MCP setup instructions.

If there isn’t a ready-made plugin, you search for your tool’s MCP documentation, copy a JSON config block, paste it into the Claude desktop config file (found in the Developer section of settings), and save.

It sounds technical but it’s usually just copying a block of text into the right place. Automation platforms like n8n can also create custom MCP servers for any tool with an API.

That means you can connect nearly anything to Cowork even if it doesn’t have official MCP support yet.

Browser use

This is your fallback. If your software doesn’t have a built-in connector or an MCP server, Cowork can open a browser and interact with the tool directly.

Clicking buttons and reading screens the way you would. It’s slower than an API connection but it works with nearly anything.

Each connected tool also becomes another source of context. Cowork can pull your existing tasks, project notes, pipeline data, and meeting records into a workflow.

That gives it real-time information about what you’re working on right now.

Tips to get this right

• Start with the tool you use most. For many people, that’s Notion, Asana, or a similar project management tool.

• Connect that first and test a simple query like “show me my open tasks” before connecting anything else.

• If Cowork doesn’t have a direct connection to a tool and you ask it to access that tool, it will often trigger browser use automatically. You don’t always need to tell it explicitly.

• Browser-based research tasks are a good early test. Ask Cowork to research a topic on a specific platform. It’ll browse, scroll, and compile findings while you carry on with other work.

Step 3: Understand why skills change everything

This is where you go ‘next-level’ in your AI knowledge.

Think about the tasks you do every week. Creating briefs, analysing data, writing a scope of work or a requirements document. Reviewing a content brief. Packaging a video idea into a title and thumbnail. Prepping slides for a presentation.

Each of these tasks follows a specific process. You probably have a mental checklist. A preferred order of how you do it. A set of reference materials you pull from each time.

Now imagine you could save that entire process as a single reusable package. The steps, the context files, and the instructions. All in one place.

That’s a ‘skill’.

Skills are where your context (business docs, examples, preferences) and your process (steps, decision points, actions) come together into something repeatable.

What makes skills different from Claude Projects or custom GPTs?

You can trigger multiple skills in the same conversation. Writing a project? Trigger your “client brief to WBS generator” skill, then your “scope of work” skill, then your “project plan” skill. All in one session.

With Claude Projects or custom GPTs, you’d be jumping between three separate interfaces.

Skills only load their instructions and knowledge sources when triggered. This keeps the context window clean. You’re not overloading Cowork with irrelevant information from five different workflows when you only need one. This is a smarter approach than stuffing everything into a single system prompt and hoping the AI figures out what’s relevant.

Skills can also include instructions to update external software at the end of a workflow.

After you finalise a document, the skill can update your Notion pipeline or project tracker automatically through the connectors you set up in Step 2.

Why this matters more than full automation

A lot of daily work needs a human in the loop. Project planning, content creation, strategic decisions, client communications. These tasks follow a process, but they require judgment at multiple points.

A fully automated workflow on a platform like n8n or Make can feel rigid for this type of work. You end up fighting the automation or hopping between interfaces when the task has nuance.

Skills sit in a sweet spot. They automate the repeatable parts while keeping you in control at the decision points.

Step 4: Use pre-built skills to start fast

You don’t need to build everything from scratch.

Claude Cowork comes with built-in skills. And a growing community is sharing skills publicly.

Built-in skills are found in Claude’s settings under Capabilities.

Scroll down to “Example Skills” and you’ll see what Anthropic has included out of the box. Canvas design, MCP builder, a skill creator (which helps you build new skills), and others.

Trigger any of them by telling Cowork to load the skill by name. It will read the skill’s instructions, ask you the right questions, build a plan, and execute step by step.

Community skills are where it gets interesting.

Three marketplaces have popped up as the main hubs: smithery.ai/skills, skillhub.com, and skillsmcp.com. Between them, there are thousands of user-created skills covering everything from ad copywriting and SEO analysis to financial modelling and code review.

Some of them are surprisingly good.

Tips to get this right

• Download a community skill and test it before building your own. This gives you a feel for how skills are structured and what good instructions look like.

• Most skills come as a zip file. Upload it through Claude’s settings under Capabilities and it appears in your skill library straight away.

• Community skills won’t have context about your specific business. This is where layering context makes a massive difference. Pair a community skill with your “business context” folder from Step 1.

• Give Cowork access to your ICP, voice guide, and example work alongside the skill.

• A generic “ad copywriting” skill paired with your specific business context will produce output that’s miles ahead of either one used alone.

Step 5: Build your first custom skill (the walkthrough method)

This is the most powerful approach.

Here’s the idea. Walk through one of your regular tasks with Claude Cowork, step by step, doing it manually just once. At the end, ask Cowork to save that entire process as a skill.

Next time, you trigger the skill and it follows the same process automatically. All the context baked in. Boom!

Let’s help a colleague out with this one….

Say they repurpose video content into newsletters every week. The process might look like this: get the video transcript, brainstorm subject lines, pick one, write a hook, pick one, then draft the full newsletter in a brand voice.

They can walk through this once with Cowork. At each step, tell it what to do and give it the reference materials it needs. The voice guide, newsletter examples, content strategy etc.

Have Cowork use a browser to find a video and download the transcript for you.

Each step is something they’d normally do manually. But now Cowork is learning the process as you go.

When you’re done, you say: “Save this as a skill.”

Cowork packages the entire workflow. Every step, every reference file, every decision point where it should pause and ask for your input.

Tips to get this right

• Don’t try to automate a complex workflow on your first attempt. Pick a task that has 3-5 clear steps.

• Be specific about the order of operations during your walkthrough. If you always brainstorm subject lines before writing hooks, make that explicit. The skill will follow whatever sequence you demonstrate.

• Include your reference files during the walkthrough. The skill will remember to load them each time it runs. This is the moment where all the context documents you created in Step 1 start paying off.

• After the skill is saved, test it straight away with fresh input. You’ll spot gaps in the instructions quickly. You can update the skill on the fly. Pay attention to whether the output reflects your voice and context. If it doesn’t, the fix is usually adding more specific examples or tightening the context files. Not rewriting the skill instructions.

Step 6: Convert your existing Claude Projects and custom GPTs into skills

If you’ve already built Claude Projects, custom GPTs, or system prompts in other tools, you’re sitting on a goldmine.

All the context and process knowledge embedded in those setups can be migrated into Cowork skills.

Take your existing system prompt. Grab the knowledge sources and reference files attached to it. Hand everything to Cowork and say: “Create a skill out of this.”

Cowork will package your existing setup into a skill format. All those prompts and processes you’ve refined over months of trial and error are now portable, combinable, and reusable inside a single Cowork session.

This is the fastest way to build a library of skills and (if you’re like me) you’ve been using AI seriously and probably have 5-10 custom setups scattered across Claude Projects, ChatGPT, and other tools.

Each one holds accumulated context. Your refined instructions, your curated examples, your specific preferences for that type of task.

Converting them into Cowork skills means you stop jumping between interfaces. Everything lives in one place. You can trigger any combination of skills in the same conversation.

Tips to get this right

• Copy the full system prompt from your existing Claude Project or custom GPT. Don’t paraphrase it. Cowork will use the exact instructions to build the skill.

• Include all knowledge sources: brand guides, example outputs, process documents, templates. The skill will reference these each time it runs. These context files are the reason your old setups worked well. Without them, the skill is just instructions without understanding.

• After conversion, add instructions for any software updates you want the skill to trigger through your connected tools. “After the title is finalised, update my Notion pipeline with the chosen title and move the status to ‘In Progress.’” This is something your old Claude Project couldn’t do.

• You can combine multiple old setups into a single skill. Or keep them separate and trigger them in sequence. Both approaches work. Keeping them separate gives you more flexibility to mix and match.

Step 7: Use code execution for data tasks

Claude Cowork can also run code. This opens up a whole category of tasks that conversation alone can’t handle.

This is different from Claude Code which is primarily for building applications. Code execution in Cowork is for getting specific tasks done. Data visualisation. File processing. Formatting.

The most practical use case is data visualisation. Point Cowork at a spreadsheet or CSV file and ask it to create charts, graphs, or summary tables. It writes and runs the code behind the scenes. You get the visual output without touching a code editor.

Image formatting is another common one. Need to resize a batch of images, change aspect ratios, or convert file formats?

Cowork handles it through code execution inside the same workspace where you’re doing everything else.

Tips to get this right

• Think of code execution as code in service of a task. Not building an application. Use it for data work, file processing, and formatting. For anything more complex, Claude Code is the right tool.

• Be specific about what you want to see. “Create a bar chart showing views per video from this spreadsheet” gets better results than “analyse this data.”

• You can combine code execution with skills. A reporting skill could pull data from a connected tool, run analysis code, and output formatted charts. All in one workflow.

Your next move

The shift from “chatting with Claude” to “working with Claude” happens the moment you build your first skill in Cowork.

Everything before that is just a conversation. Everything after is a workflow.

But the real win isn’t the tool. It’s the context you feed it.

The people getting the best results from AI right now aren’t the ones with the cleverest prompts.

They’re the ones who invested an afternoon building context. Filling project folders with examples of real ‘work’ - whatever that looks like. Stuff that Claude can reference on demand.

Here’s how to get started.

Spend 30 minutes creating your context folder.

Then pick one task you do every week that follows a clear, repeatable process. Walk through it once with Claude Cowork, step by step. Save it as a skill. Run it again with fresh input.

That first skill will save you time every single week going forward.

And once you see the difference context makes to output quality, you’ll find yourself converting every Gemini Gem, every custom GPT, and every repeatable task in your day into a Cowork skill.

Figure this out now and you will have a compounding advantage. Every skill you build makes the next one faster.

Every piece of context you add makes the output sharper. Every workflow you automate frees up time to think about the work that actually requires your brain.

Remember: You + AI = Superpowers.

Cheesy, but true!

By 2025, machines would write 80% of all code. Developers would become obsolete. Entire engineering teams would shrink to a handful of people.

That future hasn’t arrived. The opposite is happening.

Companies that went all-in on automated coding are now scrambling to hire back the people they let go. Some faced security disasters. Others lost millions. A few collapsed entirely.

This isn’t about whether AI and automation tools have value. They do.

This is about a fundamental misunderstanding of what these tools can actually accomplish. And why the organisations that figured this out early are now winning.

Why the Predictions Got It So Wrong

The hype machine moved faster than the technology itself.

Investors poured money into automation startups. Executives watched impressive demos. Headlines promised a coding revolution.

In March 2025, Anthropic’s CEO predicted AI would write 90% of code within 3-6 months. By late 2025, some early adopters reported 80% of their code was AI-generated. Budgets shifted accordingly.

Then reality hit.

Demos happen in controlled environments. Production environments are messy. They involve legacy systems, ambiguous requirements, and edge cases nobody anticipated.

The gap between “works in a presentation” and “works (compliantly) at scale” turned out to be enormous.

Here’s what actually happened. Productivity gains appeared in simple, repetitive tasks but vanished in complex work. Error rates climbed when tools were deployed in real settings. Security vulnerabilities multiplied, with some languages showing 70%+ failure rates. Senior engineers spent more time fixing machine-generated code than writing their own.

The core mistake was treating automation as a replacement rather than a tool.

A hammer doesn’t replace a carpenter. It helps a carpenter work more effectively. Same principle applies here.

The Hidden Costs Nobody Talks About

The selling point of automated coding tools is speed. Write code faster. Ship products quicker. Do more with less.

The hidden costs tell a different story.

Research analysing over 211 million lines of code found consistent patterns. Machine-generated code tends to be simpler, more repetitive, and less structurally diverse. These characteristics create software that’s harder to maintain over time.

The real productivity picture looks like this.

Junior developers saw 30-35% speed improvements on basic tasks. Stanford research showed up to 77% productivity gains for the least experienced developers. But senior engineers became 19% slower when using these tools. Despite believing they were 20% faster.

Experienced developers reported spending significant additional time reviewing, correcting, and rewriting automated output. 66% cited “almost right but not quite” as their biggest frustration.

And here’s the kicker. More than 90% of pilot projects failed to deliver clear returns on investment. MIT research found 95% of enterprise AI pilots failed to reach production or demonstrate measurable impact.

Think about that number. Nine out of ten attempts didn’t work.

These weren’t small experiments. They were serious investments with real resources behind them.

The tools look helpful at first glance. They suggest code completions. They generate templates. They accelerate the easy parts.

But someone still needs to debug, refine, and ship the final product. That someone is usually the most experienced (and expensive) person on the team.

MIT Technology Review found that developers spend only 20-30% of their time coding. Even substantial speed gains translate to modest overall productivity improvements.

Security Vulnerabilities Lurking in Automated Output

This is where things get serious.

One in five security leaders reported real production incidents caused directly by machine-generated code. Not theoretical risks. Actual breaches, actual emergency patches, actual financial and reputational damage.

In the United States, 43% of organisations experienced such incidents. In Europe, 20%.

The vulnerability breakdown is concerning.

Machine-generated code contains up to 45% security flaws. AI models choose insecure methods 45% of the time when presented with coding tasks. Common issues include input validation failures, improper error handling, and weak cryptographic practices.

Java shows failure rates exceeding 70% (72%). JavaScript sits at 43%. C# at 45%. Python at 38%.

Cross-site scripting vulnerabilities appear in 86% of AI-generated code. Log injection flaws occur 88% of the time.

Pull requests from automated tools contain an average of 10.8 detected issues compared to 6.4 from human developers. That’s a 1.7x increase. Severity risks range from 1.88x to 2.74x higher.

Each additional error increases review time, maintenance costs, and the likelihood of something slipping through to production.

By mid-2025, security firm Apiiro reported tracking more than 10,000 new security findings per month. That’s a 10-fold spike in vulnerabilities over just six months.

Human developers make contextual decisions. They anticipate how systems interact. They ask questions when requirements seem incomplete.

Automated tools don’t have these capabilities. They work strictly with the information provided.

Companies That Learned the Hard Way

Builder.ai raised more than $500 million in funding by promising to build complete applications with minimal human involvement. The company secured investments from Microsoft and the Qatar Investment Authority. It reached a valuation between $1.3-1.5 billion by May 2023.

The reality was different.

Much of the actual work still depended on human developers. This fact became embarrassingly public when The Wall Street Journal revealed in 2019 that the startup used human engineers rather than AI for most of its coding work.

When auditors uncovered inflated sales forecasts and “potentially bogus” revenues in early 2025, lenders seized $37 million from the company’s accounts. By May 2025, Builder.ai filed for bankruptcy.

Nearly 1,000 people lost their jobs. That’s approximately 80% of the workforce.

Another incident involved Google’s Antigravity AI development tool with deep access to operating system functions. After a user requested cache cleanup, the AI executed an incorrect command and deleted the entire contents of their D: drive.

The deletion bypassed the Recycle Bin. Recovery was impossible. Months of work vanished in seconds.

These aren’t edge cases. They’re the predictable outcomes of treating automation as more capable than it actually is.

Where Automation Genuinely Adds Value

Dismissing these tools entirely would be as wrong as blindly trusting them. The key is understanding where they help and where they create problems.

Automation performs well with generating boilerplate code and templates, autocompleting common patterns, suggesting syntax corrections, accelerating simple, well-defined functions, and helping junior developers learn common approaches.

Human judgment remains essential for designing system architecture, handling ambiguous or incomplete requirements, making security-critical decisions, integrating with legacy systems, anticipating edge cases and failure modes, and adapting when requirements change mid-project.

More than 70% of enterprise software projects experience significant requirement changes during development. Automated tools cannot anticipate these shifts. They don’t ask clarifying questions. They don’t push back when something seems wrong.

Requirements issues cause approximately 50% of project rework. 70-85% of all rework stems from changing requirements.

A function that looks simple, like processing payments, might involve dozens of business rules around refunds, taxes, and regulatory compliance. Unless every detail is explicitly specified, automation will miss the complexity.

This explains why so many automated projects end up partially rewritten by humans before release.

The Hybrid Approach That Actually Works

The organisations succeeding with these tools aren’t choosing between humans and machines. They’re combining both strategically.

Here’s what effective integration looks like.

Use automation for repetitive, well-defined tasks that don’t require judgment.

Keep humans in control of architecture, security, and complex logic. Treat automated output as a first draft requiring review, not a finished product. Invest in training developers to use tools effectively rather than replacing developers with tools. Build in mandatory human review for any code touching critical systems.

MIT research found that companies purchasing specialised AI solutions from vendors succeeded approximately 67% of the time. That compares to just 33% success rates for organisations building proprietary internal systems. The difference lies in realistic expectations and appropriate scope.

Within organisations that adopt AI coding tools strategically, productivity benefits scale with utilisation intensity. High adopters see productivity increases ranging from 44% to 77% depending on seniority and task complexity. Low adopters experience 11-15% productivity declines.

Anthropic’s internal research reveals that engineers experience a net decrease in time spent per task category but a much larger net increase in output volume. They fix more bugs, ship more features, run more experiments.

Notably, 27% of AI-assisted work consists of tasks that wouldn’t have been done otherwise. Scaling projects, building “nice-to-have” tools, and exploratory work that wouldn’t be cost-effective manually.

Think of it as power steering rather than self-driving. Power steering makes driving easier. It doesn’t mean you remove the driver.

Position Yourself for What’s Actually Coming

The hype cycle has peaked. Reality has set in. Companies are adjusting their expectations. And their hiring plans.

Recent data shows businesses planned approximately 32,000 layoffs in September 2025. By December 2025, planned layoffs had fallen to the lowest level in 17-18 months.

The mass redundancies that followed early automation enthusiasm are reversing. Big Tech engineering headcount is rising after the 2022-2023 correction. Software development roles are projected to grow 17% through 2033. That’s adding approximately 327,900 new US jobs.

Organisations need developers more than ever.

If you’re a developer:

Your skills remain valuable. Especially the judgment and problem-solving that can’t be automated. Learning to work effectively with automation tools makes you more valuable, not less. Focus on complex systems thinking, security awareness, and architectural decisions. The engineers who understand both the capabilities and limitations of these tools will be in highest demand.

If you’re a business leader:

Don’t be dazzled by speed at the sacrifice of good product strategy.

Audit any AI and automation investments for realistic returns rather than demo-day promises.

Build review processes that catch the errors automated tools introduce. Recognise that experienced developers become more critical when using automation, not less. Beware vendors selling fully autonomous development.

Make sure that compliance and information security best practices are baked-in from the beginning, before you get fragmented.

The real opportunity isn’t replacing human capability. It’s multiplying it.

The Human-Machine Path Forward

Every new technology goes through a predictable cycle. Wild predictions. Massive investment. Disappointing results. Recalibration. Genuine progress.

Automated coding tools are in the recalibration phase. The initial promises were overblown. The failures have taught valuable lessons. Now the real work begins. Figuring out how humans and machines can collaborate effectively.

Accept that human judgment and creativity cannot be automated. Not with current technology, and not soon.

• Use automation for what it does well: repetitive, well-defined, low-stakes tasks.

• Maintain human review for anything touching production systems.

• Invest in developing hybrid skills that combine technical ability with tool proficiency.

• Question any vendor or consultant promising fully autonomous development.

• Track actual productivity and error rates

The prediction that machines would write 80% of code by 2025 was wrong.

The reality, that thoughtful human-machine collaboration creates better products, is far more interesting.

And far more valuable.

---

References

Osmani, A. (2026, January 27). The 80% Problem in Agentic Coding. Substack.

Business Insider. (2025, March 13). Anthropic CEO: AI Will Be Writing 90% of Code in 3 to 6 Months.

MIT Technology Review. (2025, December 15). AI coding is now everywhere. But not everyone is convinced.

arXiv. (2025, September 15). Measuring AI’s True Impact on Developer Productivity.

Veracode. (2025, September 8). AI-Generated Code: A Double-Edged Sword for Developers.

Radware. (2026, January 27). Synthetic Vulnerabilities: Why AI-Generated Code is a Security Risk.

Future CISO. (2025, August 17). CISO alert: AI code vulnerabilities on the rise.

InfoQ. (2025, July 19). AI Coding Tools Underperform in Field Study with Experienced Developers.

GitClear. (2024, October 31). AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Duplication.

Dev Class. (2025, February 19). AI is eroding code quality states new in-depth report.

Reuters. (2025, July 10). AI slows down some experienced software developers, study finds.

The Register. (2025, July 10). AI coding tools make developers slower, study finds.

METR. (2025, July 9). Measuring the Impact of Early-2025 AI on Experienced OS Developers.

Stack Overflow. (2025, June 23). AI | 2025 Stack Overflow Developer Survey.

Fortune. (2025, August 17). MIT report: 95% of generative AI pilots at companies are failing.

Loris AI. (2025, December 14). MIT Study: 95% of AI Projects Fail. Here’s How to Be The 5%.

BCG. (2024, October 23). AI Adoption in 2024: 74% of Companies Struggle to Achieve and Scale Value.

RG Consulting. (2025, October 28). AI-Generated Code Blamed for 1-in-5 Breaches.

ITPro. (2025, October 21). AI-generated code is now the cause of one-in-five breaches.

Security Today. (2025, August 4). AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks.

Yahoo Finance. (2025, July 30). AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks.

Augment Code. (2025, October 2). AI Code Vulnerability Audit: Fix the 45% Security Flaws Fast.

LinkedIn. (2025, December 19). AI-Generated Pull Requests Have 1.7x More Issues.

Apiiro. (2025, September 7). 4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks.

Beam AI. (2026, January 26). Builder.ai’s Collapse: What It Means for the Low-Code/No-Code Landscape.

Yahoo Finance. (2025, May 27). Builder.ai’s Shocking $450M Fall: Microsoft And QIA-Backed No-Code AI Darling Files For Bankruptcy.

The Register. (2025, May 20). Builder.ai coded itself into a corner – now it’s bankrupt.

Business Cloud. (2025, October 15). Builder.ai fallout continues as 200 UK employees remain unpaid.

Windows Central. (2025, December 3). Google’s Agentic AI erased a developer’s hard drive.

Tom’s Hardware. (2025, December 2). Google’s Agentic AI wipes user’s entire HDD without permission.

The Register. (2025, November 30). Google’s vibe coding platform deletes entire drive.

Requiment. (2025, August 19). Why Do Software Development Projects Fail?

3Pillar Global. (2025, May 20). Why Software Development Projects Fail.

Anthropic. (2026, January 20). 2026 Agentic Coding Trends Report.

Reddit. (2025, October 1). ADP report: 32,000 Jobs cut for September.

LinkedIn. (2026, January 10). Layoff plans fall, offering some hope for workers.

Pragmatic Engineer. (2025, October 6). State of the software engineering jobs market, 2025.

LinkedIn. (2025, June 18). Software Developer Labor Demand & Salary Trends (2025).

Hey,

Quick one.

At the start of January I ran a free 7-day email course on AI-powered automations.

At the end, I gave away the complete guide. The full playbook for running an AI automation project from start to finish. Checklists, templates, prompts, the lot.

That guide has been free since the course launched.

Tomorrow, it goes up for sale as a paid product.

If you grabbed it already, you’re sorted. It’s yours forever.

If you haven’t, this is your last chance to get it for free.

After midday tomorrow, it’ll be a paid product on Gumroad.

No hard feelings if you don’t grab it. But I didn’t want you to miss out because the email got buried.

Speak soon,

Tim

P.S. If you missed the course entirely and want to catch up first, the emails are still available.

But the guide is the real value. Grab it while it’s free.

Yesterday we walked through the seven phases of an automation project. Discovery, scoping, design, build, testing, handover, maintenance. Now you know that running one isn’t too different from any other.

Today is our final day. Let’s talk about what happens next.

You know more than you think

Over the past week, you’ve learned:

• What an automated workflow actually is (trigger → steps → output)

• Why PMs are perfectly placed to lead this stuff

• How to break down any process into its components

• What makes a workflow AI-powered (and when you don’t need AI)

• How to spot automation opportunities in your own work

• How automation projects run from start to finish

The question now is: what do you do with it?

Three paths forward

There’s no single right way to start. Pick the path that fits where you are.

Path 1: Observer

Start noticing workflows in your daily work. When you do a repetitive task, mentally break it down. Trigger, steps, output. Where can AI help? Which bits are better suited for traditional automation? You don’t have to build anything yet. Just practice seeing your projects this way.

Path 2: Champion

Bring one small automation idea to your team. You don’t have to build it yourself. Just identify the opportunity, explain the value, and volunteer to lead a pilot. Be the person who makes it happen.

Path 3: Builder

Learn a no-code tool and create your first simple workflow. Start with something boring and low-stakes. Check out Make.com, Zapier or n8n as your new playground. Break things. Fix them. Learn by doing.

All three paths are valid. Observer builds awareness. Champion builds influence. Builder builds skills. Choose based on your situation and how much appetite you have to learn.

How to pitch an automation idea

When you’re ready to propose something internally, keep it simple.

1. Name the pain. “We spend X hours every week doing Y manually.”

2. Describe the fix. “We could automate this so it happens automatically when Z.”

3. Quantify the benefit. “That would save us X hours per week / reduce errors / speed up delivery.”

4. Propose a pilot. “I’d like to run a small test with one project / one client / one team.”

Don’t overcomplicate it. Decision-makers want to know: what’s the problem, what’s the solution, what’s the benefit.

Questions to ask before any project

Before you start building (or asking someone else to build), make sure you can answer these:

• What problem are we actually solving?

• What does the current process look like?

• What triggers the workflow?

• What’s the output we need?

• Who uses it, and what do they need to know?

• How will we know it’s working?

• What happens when something goes wrong?

If you can’t answer these clearly, you’re not ready to build yet. Go back to discovery.

Your action plan

Here’s a simple plan to keep the momentum going.

This week: Pick one process you’d like to automate. Write it down. Add it to your Ideas page.

This month: Document it as a workflow. Trigger, steps, output. Identify the AI steps vs automation steps.

This quarter: Either pitch it internally or build a simple version yourself.

Small steps. Consistent progress. That’s how this stuff actually happens.

Your Full guide to Running an AI Automation Project

You’ve got the foundations. But I’m giving you the process and tools you need to run ANY AI automation project from start to finish.

It covers everything we’ve talked about this week, plus detailed checklists, templates, and prompts.

It’s free. Just hop into Notion, and duplicate it.

EXPIRY DATE

The guide will be yours to duplicate (free) for 1 week only. After that I will be making it a paid product.

Final day is Sunday 18th January.

One last thing

For all the time I have put into this, I’d appreciate it if you could share my newsletter with just one colleague. That would mean a huge amount to me.

Thanks so much.

Tim

Share The Wash-Up

Today we zoom out. What does an automation project actually look like from start to finish?

Understanding the structure helps you plan better, communicate clearly, and avoid the mistakes that sink most projects.

Seven phases of an automation project

Every one follows roughly the same path. Some are quick, some take longer, but the phases stay the same.

1. Discovery

Understand the problem. What’s happening today? What’s painful about it? What does “fixed” look like?

This is where you dig into the current process, talk to the people involved, and get clear on what you’re actually trying to solve.

2. Scoping

Define what you’re building. What’s in, what’s out, what does success look like?

This is where most projects go wrong. Fuzzy scope leads to endless changes, missed expectations, and frustrated stakeholders. Get specific here and document it like you would with any other project.

3. Design

Map the workflow. What triggers it? What steps happen? What’s the output? Where does AI fit? What happens when things go wrong?

You’re creating the blueprint before anyone starts building.

4. Build

Create the automation. Connect the systems, configure the logic, write the prompts, test as you go.

This is the technical bit. You might do it yourself, or work with someone who does.

5. Testing

Make sure it works. Run it with real data. Check the outputs. Find the edge cases. Break it on purpose so your client doesn’t.

Never skip testing.

6. Handover

Spend time on a proper handover. Train the people who’ll use it. Document how it works. Make sure someone knows what to do when something goes wrong.

A workflow that nobody understands is a workflow that won’t last.

7. Maintenance

Keep it running. Monitor for errors. Update when things change. Fix what breaks. Improve based on feedback.

Automation isn’t “set and forget.” It needs looking after.

Where automation projects actually fail

Most automation projects don’t fail because of technical problems. They fail because of people problems.

• Poor scoping. “We didn’t realise that was included” or “We thought it would do this other thing too.” Clear scope prevents this.

• Unclear requirements. “I didn’t know you needed it to work that way.” Ask enough questions upfront. Document everything.

• No testing. “It worked fine until we used it with real data.” Always test properly before going live.

• Bad handover. “Nobody knows how this thing works anymore.” Document it. Train people. Be available for questions.

The PM’s role at each phase

You don’t have to be technical to run an automation project. But you do need to lead it.

• Discovery: Ask the right questions. Understand the real problem.

• Scoping: Define boundaries. Get agreement. Protect against scope creep.

• Design: Review the workflow. Make sure it matches requirements.

• Build: Track progress. Remove blockers. Communicate with stakeholders. Understand how it works.

• Testing: Coordinate UAT. Document issues. Confirm quality.

• Handover: Ensure training happens. Check documentation exists.

• Maintenance: Set up monitoring. Plan for ongoing support.

You know. The usual stuff you do everyday.

The key insight

This is just another digital project. They have the same risks, the same stakeholders, the same need for clear communication and proper planning.

The technical bit is important.

The PM stuff - that’s your bread and butter.

Tomorrow is our final day. We’ll wrap up with your first steps forward and how to actually get started.

And I’ll give you a detailed guide to help along your way.

Speak then,

Tim

Your course workbook

I’ve built a guide (in Notion) to go alongside these emails.

Inside you’ll find:

- Daily AI prompts to reinforce each lesson.

- Exercises to spot opportunities in your own work.

- Space to capture automation ideas as they come to you.

Complete the exercises, and you’ll be ready for the full guide on Day 7.

Sign up for Notion (it’s free and it’s awesome).

Then get your course workbook.

Today we’re getting practical. How do you actually find opportunities in your own work?

The best opportunities are hiding in plain sight

You probably pass automation opportunities every day without noticing them. They’re disguised as “just part of the job” or “it only takes a few minutes.”

But those few minutes add up. And those repetitive tasks are exactly what automation is built for.

You just need to know where to look.

Five signs, a task should be automated

When you’re looking for automation opportunities, ask these five questions:

1. Do you do it repeatedly?

Weekly, daily, every project, every client. If it happens on a regular cycle, it’s a candidate.

2. Does it follow the same steps each time?

If you could write instructions for someone else to follow, it’s predictable enough to automate.

3. Does it involve moving information between tools?

Copying from email to spreadsheet. Pulling data from one system to update another. This is automation’s sweet spot.

4. Is it low-value but time-consuming?

Important enough that it has to happen, but not the kind of work that needs your brain. Admin. Data entry. Status updates.

5. Do mistakes happen when you’re rushing or tired?

If you’ve ever made an error because you were distracted or moving too fast, automation removes that risk.

The more “yes” answers, the better the candidate.

The “hit by a bus” test

Here’s another way to spot opportunities.

If you got hit by a bus tomorrow, which tasks would be hardest to hand over? Which ones live entirely in your head with no documentation?

Those tasks are risky. They depend on you being there, remembering to do them, knowing how they work.

Automation doesn’t just save time. It reduces risk. The workflow runs whether you’re there or not.

Start boring

Your first automation should not be ambitious.

It should be boring. Simple. Low stakes.

Why? Because you’ll make mistakes. You’ll learn how the tools work. You’ll discover edge cases you didn’t think of. You’ll use real data and it will break.

Better to learn those lessons on a simple internal report than on something client-facing and high-stakes.

Save the impressive stuff for when you’ve got a few wins under your belt.

Common mistakes to avoid

• Automating something complex first. Start simple. Build confidence. Then tackle the harder stuff.

• Automating a broken process. If the process in your business doesn’t work well manually, automating it just creates more chaos. Fix it first, then automate.

• Automating things that change constantly. If the requirements shift every week, automation will just create more work for you. Look for stable, predictable processes.

• Automating for the sake of it. Not everything should be automated. If the effort is greater than the impact, it’s not worth it.

Your homework

Over the next 24 hours, pay attention. Every time you do a task, ask yourself: could this be automated?

You’ll be surprised how many times the answer is yes.

Tomorrow, we’ll look at how automation projects actually run from start to finish. Knowing the process helps you plan better and avoid surprises.

Speak then,

Tim

Don’t forget your course workbook

Inside you’ll find:

- Daily AI prompts to reinforce each lesson.

- Exercises to spot opportunities in your own work.

- Space to capture automation ideas as they come to you.

Complete the exercises, and you’ll be ready for the full guide on Day 7.

Sign up for Notion (it’s free and it’s awesome).

Then get your course workbook.

Trigger → Steps → Output.

Simple structure, infinite applications.

Today we add the AI layer and this is where things get interesting.

Traditional automation vs AI automation

Traditional automation is good at repetitive, predictable tasks. Move this file here. Send this email when that happens. Update this spreadsheet with that data.

It follows rules. If X, do Y. Every time, the same way.

But some tasks need more than rules. They need judgement.

That’s where AI comes in.

Quick interlude: When I say AI throughout this course. I mean Generative AI and Large Language Models (LLM’s) within ChatGPT, Claude, Gemini etc.

What AI can do that regular automation can’t

AI can handle tasks that require understanding, interpretation, or creativity.

Things like:

• Reading and understanding: Making sense of an email, a document, or a transcript

• Summarising: Condensing a long piece of content into key points

• Categorising: Deciding what type of thing something is (complaint vs question, urgent vs not urgent)

• Extracting: Pulling specific information out of unstructured text

• Drafting: Writing content based on inputs (emails, summaries, reports)

• Deciding: Making judgement calls based on context

These are the “thinking” tasks. The ones that used to require a human brain. In AI circles, it’s called reasoning.

Where AI fits in a workflow

AI doesn’t replace the whole workflow. It handles specific steps within it.

Look at a workflow and ask: which steps require understanding or judgement?

Those are your AI steps. Everything else can be traditional automation.

Example: Meeting follow-up workflow

Here’s a simple workflow that combines both - one you may be familiar with.

Trigger: Meeting ends (calendar event)

Steps:

1. Get the meeting transcript (automation)

2. Summarise the discussion into key points (AI)

3. Extract action items with owners and deadlines (AI)

4. Draft a follow-up email (AI)

5. Send the email to attendees (automation)

6. Create tasks in project tool for each action item (automation)

7. Log the meeting in the tracker (automation)

Steps 2, 3, and 4 need AI. They require understanding what was said and making decisions about what matters.

Steps 1, 5, 6, and 7 are pure automation. They’re just moving data and triggering actions.

When you need AI vs when you don’t

Not every workflow needs AI. Sometimes simple automation is enough.

Use AI when:

• The input is unstructured (emails, documents, transcripts)

• The task requires interpretation or judgement

• The output needs to sound human

• Rules alone can’t handle the variation

Use simple automation when:

• The input is structured (form fields, database records)

• The task follows clear, consistent rules

• You’re just moving data between systems

• The same action happens every time

Adding AI when you don’t need it just adds complexity and cost. Keep it simple where you can.

The important bit

AI is a tool, not magic. It’s very good at certain things and not so good at others.

Your job isn’t to use AI everywhere. It’s to know when AI adds value and when it doesn’t.

That judgement? That’s the human bit. And it’s not going anywhere.

Tomorrow, we’ll talk about how to spot automation opportunities in your own work. You’ll start seeing them everywhere.

Speak then,

Tim

Your course workbook

I’ve built a guide (in Notion) to go alongside these emails.

Inside you’ll find:

- Daily AI prompts to reinforce each lesson.

- Exercises to spot opportunities in your own work.

- Space to capture automation ideas as they come to you.

Complete the exercises, and you’ll be ready for the full guide on Day 7.

Sign up for Notion (it’s free and it’s awesome).

Then get your course workbook.