Turn Recurring PM Work into Checked Prompt Systems

Workflow area: Systems Leverage · Tier: Core · Hands-on time: ~40 minutes

The difference between a PM who "uses AI" and a PM with systems leverage is what happens on Monday morning. The first re-explains their product to a chatbot and gets a generically competent draft. The second opens a Claude Project that already knows the product, the metrics, the audience and the format, pastes this week's inputs, and gets a draft that's 90% right — with the system itself flagging what a human must still verify. The second PM built something once; the first pays the setup tax weekly, forever.

When to use — and when not to

• Use it for anything you've prompted from scratch three timesthe third repetition is the signal; the recurring artifacts (weekly update, release notes, triage, synthesis, exec pre-reads) are where systemization pays compound interest.
• Use it for work you want consistent across the teama shared prompt system is a quality floor: every PM's release notes come out with the same sections and the same checks.
• Use it for work you might delegatea prompt system with embedded quality checks is a training document that executes.
• Skip it for genuinely one-off worksystemizing a task you'll do once is procrastination wearing a productivity costume.
• Skip it for judgment itselfyou can systemize drafting the prioritization sheet; you cannot systemize deciding. Any "system" that outputs decisions without a human override step is product-management theater with better tooling.

The recipe

1. 1.

   Pick one workflow and write down how you actually do it. Ten minutes, five bullets: inputs (where they come from), the transformation, the output format, who consumes it, and — critically — what you always have to fix in a naive AI draft. That last list becomes the embedded quality checks.

2. 2.

   Build the system container. In Claude Projects (or a Custom GPT), create one project per workflow and load the standing context: product one-pager, audience notes, format template, terminology, and two or three examples of past outputs you were proud of. Context that travels automatically is the whole point — it's what you'll never paste again.

3. 3.

   Write the system prompt with the checks inside. A weekly-update system, as a pattern:

   Copy

   You draft my weekly product update. Standing context is in this
   project (product, audience, format). Each week I will paste:
   metrics snapshot, shipped list, notable events.
   
   Produce the update in our template, then ALWAYS append a
   "VERIFY BEFORE SENDING" section listing:
   - every number in the draft, with where I should check it
   - every claim about a team or person (I confirm before naming)
   - anything you inferred rather than found in my inputs, marked
     [INFERRED]
   - the "so what" paragraph marked [REWRITE IN YOUR VOICE]
   
   Rules: never carry forward last week's numbers as this week's;
   if an input is missing, say so rather than filling the gap;
   flat or negative metrics get reported, not spun.
   

   The verify-section is what makes this a checked system rather than an automation you'll slowly stop reading.

4. 4.

   Run it three cycles and tune the failure modes. Keep a running "what I had to fix" note. Each fix becomes a new rule in the system prompt: the update that spun a bad metric gets the no-spin rule; the triage that hallucinated a ticket ID gets a quote-the-source rule. Three cycles of tuning turns a decent prompt into an instrument.

5. 5.

   Chain systems only where checks survive. With n8n or Zapier you can wire triggers — transcript lands, extraction runs, draft appears in Notion. The rule: automation may move drafts to you, never past you. Every chained system ends at a human review step, and the draft arrives with its verify-section intact. Auto-sending is where prompt systems become incident reports.

6. 6.

   Version the library. Keep the system prompts in one place — a Notion database or a git repo — with a changelog line per revision. When a teammate asks "how do you do your updates so fast," you hand them a link, and the team's floor rises.

Make it yours

• The personal top five: most PMs' highest-yield systems are the weekly update, meeting-transcript-to-actions (pb-13), interview extraction (pb-01), backlog dedupe/triage (pb-08), and the exec pre-read (pb-12) — build one per week for five weeks rather than all at once.
• Custom GPTs for team distribution: if your org lives on ChatGPT, publish the tuned system as a Custom GPT with the checks in its instructions — teammates get the system without needing to understand prompt design.
• n8n for the ambient inputs: use automation to gather (pull the week's shipped PRs, new tickets, metric snapshot into one doc) and the prompt system to draft — separating collection from transformation keeps each piece simple and debuggable.

Quality check

• Every system has an embedded verify-sectiona system that outputs only the artifact, with no checklist of what to verify, is an unchecked automation.
• [INFERRED] content is actually markedtest by feeding an incomplete input and confirming the system says so instead of inventing.
• The human-judgment steps are outside the systemdecisions, so-what paragraphs and anything with a name attached carry an explicit rewrite/confirm marker.
• No chain sends output anywhere without youaudit your automations for any path from AI draft to another human's inbox that skips your review.
• Systems are versioned and dateda system prompt nobody has revised in three months is either perfect or unread; check which.
• The fix-log is liverecurring manual fixes that haven't become rules mean the system has stopped learning.