Document automation without losing ownership
Claude can draft any document a project manager produces. Meeting summaries, project briefs, status updates, stakeholder communications, proposals, risk registers. The output arrives in seconds and looks finished.
The question is whether that draft represents your understanding or Claude's pattern-matching from training data that does not know your client, your project history, or the specific context that makes this document different from the last one.
The answer depends entirely on what you do with the draft.
Documents that automate well
Meeting summaries. Actions, decisions, and discussion points — structuring what happened. The content exists in the recording or the notes. Claude organises it. Your review confirms accuracy and catches what got missed. Light edit, send. This is a strong automation candidate.
Status report drafts. The structure of a status report is predictable: what is done, what is in progress, what is blocked, what is next. Claude generates this structure from your data. You add the interpretation — what these numbers mean for the project, what the steering group needs to know. Medium edit, specific additions, send.
Action item lists. From a meeting summary or a planning session, Claude pulls and formats a clean action item list. Assign owners, confirm due dates, send. Minimal edit.
Internal briefings. Context documents for team members joining a project. Background documents for a new stakeholder. First-pass research summaries. These are useful as starting points. Review for accuracy, add project-specific context, send.
Documents that require significant rewriting
Client proposals. A proposal is not just a description of what you will do — it is evidence that you understand the client's situation, priorities, and constraints. Claude produces a generic proposal structure. You rewrite it to reflect the conversation you had, the specific concern the client raised last week, the approach you know fits their organisational culture. The difference between a generic proposal and a winning one is entirely in that specific knowledge. Claude cannot access it.
Risk assessments. Risk registers from Claude are complete in structure and generic in content. "Key person dependency" appears as a risk in every project. Whether it is a significant risk in your project depends on your knowledge of the team, the client, and the delivery approach. A risk assessment that does not reflect that knowledge is a template, not a professional judgment.
Scope change documentation. A scope change request requires the PM to assess impact on timeline, cost, dependencies, and the client relationship — and to frame that assessment in a way that serves the project. Claude can draft the form. The assessment is yours.
Anything with legal, contractual, or regulatory implications. In the Swedish professional context: procurement responses, financial statements, employment documentation, compliance reports. The content of these documents carries obligations. An error is a liability. Human review is mandatory regardless of who produced the first draft.
The silent risk: delegating the thinking
There is a risk in document automation that is harder to see than an obvious error. It is the risk of producing the document without doing the thinking.
When a PM writes a project brief from scratch, the writing process is also a thinking process. Deciding what to include forces a decision about what is important. Structuring the context requires understanding the context. Framing the recommendation requires a view on what should happen.
When Claude generates the brief from bullet points, that thinking does not automatically happen. The document gets produced. The PM reads it, makes small edits, approves it. But the deep understanding that comes from working through the structure — that is sometimes missing.
This matters most for documents that will be referenced repeatedly: project charters, delivery plans, risk frameworks. If the PM who signed off on the document does not deeply understand it, that gap surfaces in every follow-up conversation.
The fix is not to stop using Claude for these documents. It is to treat the draft as a starting point for your thinking, not as the finished product. Read it with the question: what do I know that is not in here?
The revision test
Before any Claude-drafted document goes to a client or senior stakeholder, apply this test:
Can you find at least three specific things to change — not formatting corrections, but changes to the substance, the framing, or the claims?
If yes, you have engaged with the document. The revisions are evidence of review.
If no, one of two things is true: either the document is genuinely complete and perfectly accurate for this specific situation (unlikely), or you have not engaged with it at the level the accountability requires.
A well-revised Claude draft is a document you own. An unrevised Claude draft with your name on it is a risk.
A practical workflow
For a client-facing deliverable:
- Provide Claude with the specific inputs — not generic instructions but the actual context: what this client needs, what the project situation is, what outcome this document should produce.
- Read the draft with the question: what do I know that is not here? Write that in.
- Read again with the question: what claims here might not be accurate for this situation? Verify those.
- Make at least three substantive changes. If you cannot find three, read again.
- Add the interpretation that only you can add — the insight about this client, this project, this moment.
- Send with your name on it, able to defend every material claim.
Next in this series: Part 4 — Governing AI decisions across your team