Claude CoWork for AI Product Managers

Q: What This Looks Like in Your Week?

**Monday** — Sprint planning in three hours. You paste the last 30 days of NPS verbatims and Zendesk tags into the feedback synthesis workflow. You walk into planning with three ranked Opportunity Cards instead of a wall of sticky notes.

Q: What to Avoid?

**Letting Claude collapse legal gates.** The regulatory workflow surfaces risk. It does not assess compliance. Every P0 item in the Risk Register goes to your legal and compliance team before you launch. Full stop.

What is Claude CoWork?

Claude CoWork is the practice of using Claude as a persistent, context-aware co-worker embedded in your AI product workflow. Not a one-off prompt you paste into a chat window. A configured workspace that knows your product domain, your company's AI governance posture, and the regulatory environment you ship into — so every session produces a usable artifact, not a generic response.

Claude-native prompts. The prompts in this guide use Claude's native XML tag structure (<context>, <instructions>, <format>, <avoid>) for more precise, consistent output. These tags help Claude parse your intent with less ambiguity. They work in ChatGPT too, but are optimized for Claude.

AI PMs in enterprise environments are navigating a genuinely new role: owning products where the system behavior is probabilistic, the regulatory surface is actively moving, and the failure modes are harder to anticipate than in deterministic software. You are writing specs for features that do not yet have established evaluation playbooks, doing regulatory analysis you were not trained for, and synthesizing user signals from tools your sprint process was not designed to absorb. Claude is useful precisely because it moves fast on the structured parts — spec drafting, regulatory checklists, rollout framing — so you can spend your limited time on the judgment calls no one else can make.

This guide shows you how to configure Claude for AI product work, the five workflows that clear the most cognitive backlog, and the gates you must not let Claude collapse for you.

Install the AI Product Manager Plugin

This guide works on three Claude surfaces. The plugin is the fastest path on two of them. Pick whichever you use:

If you're on Cowork (desktop or mobile app)

Claude Cowork is Anthropic's agentic workspace — Claude completes work autonomously and returns finished deliverables. The AI Product Manager plugin packages the workflows below as native skills and slash commands.

Open the Cowork plugin directory in your desktop app.
Filter by Cowork, search for "AI Product Manager", and click Install.
The plugin's slash commands and ambient skills are now available in any Cowork task.

If you don't see the plugin in the directory yet, install via custom marketplace: paste https://github.com/alexclowe/awesome-claude-cowork-plugins in your Cowork plugin settings.

If you're on Claude Code (CLI)

Install from your terminal:

claude plugin add alexclowe/awesome-claude-cowork-plugins/product-manager-ai

The plugin's slash commands and skills load on next session.

If you're on Claude.ai (web chat only)

Plugins aren't directly installable on the web chat surface. You have two options:

Use the prompts in this guide directly in a Claude Project (covered in the next section). Same outputs, more typing.
Upload the plugin's skills as a zip via Settings → Features → Custom Skills (Pro/Max/Team/Enterprise plans). Higher friction; only worth it if you want the auto-activating skills, not the slash commands.

What the plugin gives you (any surface)

Slash command	What it does
`/draft-ai-spec`	Generate a product spec for an AI feature with scope, acceptance criteria, eval plan, and risk mitigations
`/evaluate-ai-risk`	Assess a feature against EU AI Act high-risk categories, FINRA agent rules, and FDA classification; flag gates
`/plan-rollout`	Design staged rollout: cohort selection, success metrics, kill criteria, comms plan
`/analyze-user-feedback`	Cluster AI-related issues from tickets and Slack; recommend the next sprint's top 3 fixes

Auto-activating skills (no command needed — Claude applies them when relevant):

AI Readiness Assessment — Audit internal infrastructure for AI launch (data quality, governance, ML platform, security review SLA)
Competitive Benchmarking — Scan competitors' AI launches, flag feature gaps, benchmark pricing and positioning

The plugin works standalone for one-off tasks. Pair it with the surface-specific setup below for persistent context across every task — that combination is the full Claude CoWork setup.

Setting Up Claude for AI Product Manager Work

Surface note: The Project setup below is for claude.ai web users. Cowork users have their own task-context mechanism (set context once when starting a Cowork task). Claude Code users get the plugin's ambient skills automatically — no Project setup needed. The workflows themselves are surface-agnostic — paste the prompts wherever you're working. Step 1: Create an AI PM Project. In Claude, go to Projects and create one called "AI Product Work" or name it by product area. This is your persistent workspace — context loads automatically with every conversation you start inside it.

Step 2: Set your custom instructions. In the Project settings, add:

You are my AI product management assistant. Here is my context:

<product-profile>
- Role: AI Product Manager
- Company size: [1K–5K employees / 5K–50K / 50K+]
- Product domain: [GenAI features / AI-assisted workflows / Autonomous agents / Other]
- Stack signals: Linear (issue tracking), Notion (specs), Figma (design), Statsig or Eppo (experimentation), Slack (async comms)
- Verticals affected: [FinTech / HealthTech / Enterprise SaaS / Consumer / Other]
- Regulatory environment: [EU AI Act / FINRA / FDA SaMD / SEC / None flagged yet]
- Deployment model: [SaaS / Internal tooling / Embedded in customer product]
</product-profile>

<rules>
- All specs are drafts for human review. Append: "DRAFT — PM AND LEGAL REVIEW REQUIRED."
- Never make claims about regulatory compliance. Flag risk areas; compliance determination requires legal and compliance team sign-off.
- Do not generate content that embeds real user PII, proprietary model weights, or confidential roadmap details.
- Kill criteria and risk mitigations in specs are placeholders — engineering and safety teams must validate them.
</rules>

Step 3: Upload product context documents. Add your team's spec template, your current AI risk framework or governance policy, any existing eval rubrics, and your company's responsible AI guidelines. Claude references these when drafting.

Step 4: Start every session inside this Project. The rules and product profile load automatically. Never do spec or regulatory work in the default Claude chat — you lose your compliance guardrails.

Step 5: Save your eval rubric template. After you develop an evaluation rubric for an AI feature (accuracy, latency, harm avoidance, business metric), save it to the Project. Reuse and evolve it rather than rebuilding it for every feature. Your eval library compounds in value.

Five High-Leverage Workflows

1. AI Feature Spec

Writing a spec for an AI feature is structurally different from writing one for deterministic software. The acceptance criteria must account for probabilistic behavior, and the risk section cannot be a checkbox. Claude drafts the framework; you supply the judgment on what ships.

<context>
Feature name: [e.g., AI-assisted email triage in customer support console]
User problem: [One sentence — e.g., Support agents spend 40% of their time routing and categorizing inbound tickets before they can start resolving them]
Proposed AI behavior: [e.g., Model classifies ticket by topic and urgency, suggests routing, and drafts an opening response]
Constraints: [Latency budget, cost ceiling, model provider, data access rules]
Success metric: [e.g., 30% reduction in time-to-first-response; agent acceptance rate > 70%]
</context>

<instructions>
- Draft the full spec: Problem Statement, Proposed Solution, Scope (in/out), Acceptance Criteria, Eval Plan, Risk Mitigations, Kill Criteria
- Acceptance criteria must address: accuracy threshold, latency p95, graceful degradation when model is unavailable, human-override mechanism
- Eval Plan: define offline eval (held-out labeled dataset), online eval (A/B via Statsig or Eppo), and qualitative review cadence
- Risk Mitigations: at minimum cover hallucination risk, bias in routing, data retention for model inputs, and PII exposure
- Kill Criteria: specific, measurable — e.g., "Agent acceptance rate falls below 50% in Week 2" or "Escalation rate increases >15%"
- Include a Model Card placeholder section for the underlying model
</instructions>

<format>
Standard spec format with H2 section headers. Acceptance Criteria as a numbered list. Risk Mitigations as a table: Risk | Likelihood | Mitigation | Owner. Kill Criteria bolded. Append DRAFT disclaimer.
</format>

<avoid>
Vague acceptance criteria like "performs well"; omitting the human-override requirement; collapsing kill criteria into a single qualitative statement; making compliance claims.
</avoid>

Before Claude: 3–4 hours writing a structurally complete AI spec from scratch. After Claude: 45 minutes to input context, 1 hour to review and sharpen judgment calls.

2. Regulatory Risk Assessment

AI PMs at enterprise companies are now expected to assess regulatory exposure before features ship, regardless of whether they have a legal background. Claude helps you build the risk surface map. Legal and compliance make the determination.

<context>
Feature: [One-sentence description of the AI feature]
Verticals affected: [e.g., Consumer lending decisioning / Clinical decision support / Trading recommendation / HR screening]
Geography: [EU / US / both / other]
User populations: [e.g., Retail consumers / Licensed clinicians / Institutional investors / Job applicants]
Data inputs to the model: [e.g., Credit history, health records, behavioral data, resumes]
Consequential decisions: [Yes/No — does this feature influence hiring, credit, healthcare, or law enforcement?]
</context>

<instructions>
- Map the feature against EU AI Act high-risk categories (Annex III): list which categories apply and why
- If FinTech: flag FINRA Regulatory Notice 24-09 on autonomous agents — specifically the "human in the loop" and customer disclosure requirements
- If HealthTech: assess against FDA Software as a Medical Device (SaMD) framework — is this a clinical decision support tool that requires 510(k)?
- Apply NIST AI RMF GOVERN, MAP, MEASURE, MANAGE functions: identify which are not yet implemented for this feature
- Output a Risk Register: regulatory body | risk area | current posture | recommended action | owner
- Flag which risks require legal/compliance sign-off before launch vs. which are PM-resolvable
</instructions>

<format>
Risk Register as a table. Followed by a prioritized Action List: P0 (legal gate — must resolve before launch), P1 (should resolve before GA), P2 (post-launch monitoring). Append DRAFT disclaimer with explicit note that this is not legal advice.
</format>

<avoid>
Asserting that a feature is compliant; predicting regulatory outcomes; omitting the not-legal-advice disclaimer; conflating NIST AI RMF with binding regulation.
</avoid>

Before Claude: 2–3 hours researching applicable regulations from scratch per feature. After Claude: 30 minutes to input feature context, 1 hour to review and schedule legal review for P0 items.

3. Staged Rollout Plan

Shipping AI features requires a staged approach that most traditional PM rollout templates do not account for — model behavior changes with distribution shift, and you need kill criteria that execute before damage compounds.

<context>
Feature: [Name and one-line description]
Target population: [e.g., All B2B customers on Enterprise plan, approximately 2,400 accounts]
Rollout tool: [Statsig / Eppo / LaunchDarkly / Internal flag system]
Success metrics: [List 2–3 primary metrics with targets]
Risk profile: [Low / Medium / High — based on Workflow 2 output]
Timeline: [Target GA date; hard blockers if any]
</context>

<instructions>
- Design a 4-stage rollout: (1) Internal dogfood, (2) Closed beta — specific cohort criteria, (3) Limited GA — % rollout with guardrails, (4) Full GA
- For each stage: cohort selection criteria, duration, success thresholds to advance, kill criteria to halt, and communications owner
- Cohort selection for beta: recommend criteria that maximize signal while minimizing harm exposure (e.g., power users, internal teams, design partners who opted in)
- Success metrics must be measurable in Statsig or Eppo — define experiment design (holdout %, randomization unit, MDE)
- Kill criteria must be automatic where possible: e.g., "If error rate exceeds 5% for 30 minutes, feature flag auto-disables"
- Communications plan: who gets notified at each stage gate, and what is the user-facing messaging template
</instructions>

<format>
Rollout table: Stage | Cohort | Duration | Success Threshold | Kill Criteria | Comms Owner. Followed by Experiment Design section and Communications Templates (2–3 draft messages for customer-facing stages).
</format>

<avoid>
Collapsing to a binary launch / no-launch; omitting kill criteria; designing cohorts that are too small to generate statistical significance; skipping the comms plan.
</avoid>

Before Claude: 2–3 hours building a staged rollout doc with experiment design. After Claude: 30 minutes to input feature context, 45 minutes to review with engineering and data science.

4. User Feedback Synthesis

AI PMs are drowning in qualitative signal from support tickets, Slack channels, NPS verbatims, and session recordings. The sprint is Tuesday. Claude structures the signal into actionable priorities.

<context>
Feature or product area: [e.g., AI writing assistant in the product's editor]
Feedback sources available: [e.g., Zendesk tickets — 200 this month; Slack #product-feedback — 40 posts; NPS detractor verbatims — 35; UserVoice requests — 120]
Sprint focus: [What the team is trying to decide — e.g., whether to prioritize accuracy improvements, latency reduction, or UX changes in the suggestion panel]
Time window: [Last 30 days / Last sprint / Since launch]
</context>

<instructions>
- Synthesize feedback into the top 3 actionable themes, ranked by frequency and severity
- For each theme: evidence summary (quote patterns, not individual users), affected user segment, business impact hypothesis, and a recommended next action for the sprint
- Apply Teresa Torres continuous discovery framing: express each theme as an opportunity, not a solution (e.g., "Users lose trust when the AI suggestion is wrong and there is no way to see why" — not "add an explanation button")
- Flag any themes that suggest a safety or compliance issue — these escalate outside the sprint
- Note what is not in the feedback that should be: underrepresented segments, missing signal sources
</instructions>

<format>
Three Opportunity Cards: Theme | Evidence | Affected Segment | Business Impact | Recommended Action. Followed by a Signal Gaps section. All in plain language suitable for a sprint planning doc.
</format>

<avoid>
Treating any single piece of feedback as representative; generating fake user quotes; collapsing safety signals into backlog items without escalation; recommending specific solutions in the opportunity framing.
</avoid>

Before Claude: 3–4 hours tagging and synthesizing feedback before sprint planning. After Claude: 30 minutes to paste or attach feedback, 30 minutes to review and pressure-test the framing.

5. Competitive AI Feature Benchmarking

A competitor just shipped an AI feature. Your leadership wants to know where you stand by end of day. Claude structures what you know from public sources into a benchmark framework.

<context>
Competitor: [Company name]
Feature shipped: [Description based on public sources — press release, product blog, demo video, changelog]
Your equivalent or planned feature: [Description]
Evaluation dimensions: [e.g., Accuracy / Speed / UX / Transparency / Regulatory posture / Pricing model]
Audience for this brief: [Leadership / Engineering leads / Design / Board]
</context>

<instructions>
- Build a side-by-side benchmark on each evaluation dimension based only on public information
- For each dimension: current competitive position (Leading / Parity / Behind / Unknown), evidence from public sources, and implication for your roadmap
- Identify which gaps are closeable in one sprint, one quarter, and one year
- Include a "What they got right" section — what product or UX decisions are worth studying
- Flag any dimensions where you cannot assess without proprietary data — label these [SIGNAL NEEDED] rather than guessing
- End with a recommended response: ignore, monitor, accelerate, or differentiate — with the one-sentence rationale
</instructions>

<format>
Competitive benchmark table: Dimension | Competitor | You | Gap | Closeable In. Followed by What They Got Right (3–5 bullets), Signal Gaps, and Recommended Response. Keep to under 600 words for leadership consumption.
</format>

<avoid>
Speculating beyond what is publicly available; presenting [SIGNAL NEEDED] gaps as known weaknesses; recommending feature parity as a default response without considering differentiation; using confidential information from any source.
</avoid>

Before Claude: 2–3 hours compiling a competitive brief from scattered public sources. After Claude: 20 minutes to input public information, 30 minutes to review and add strategic framing.

What This Looks Like in Your Week

Monday — Sprint planning in three hours. You paste the last 30 days of NPS verbatims and Zendesk tags into the feedback synthesis workflow. You walk into planning with three ranked Opportunity Cards instead of a wall of sticky notes.

Tuesday — Legal asks about the AI Act exposure on the new credit-decisioning feature before they'll approve the launch brief. You run the regulatory risk assessment workflow, produce a Risk Register, and identify the two P0 items that need legal sign-off. The conversation goes faster because you arrive with a framework, not a question.

Wednesday — Engineering wants to align on the staged rollout before the Friday feature-flag review. You use the rollout workflow to draft the four-stage plan with kill criteria and Statsig experiment parameters. The meeting is 30 minutes instead of 90.

Thursday — A competitor shipped an AI summarization feature in your space. Slack is noisy. You run the competitive benchmarking workflow against their public changelog and demo video and send leadership a 600-word brief by noon. The noise settles.

Friday — New AI feature request from a major enterprise customer. You open your AI PM Project, run the spec workflow, and have a draft skeleton with eval plan and kill criteria before end of day. Monday's kickoff starts from a working draft.

What to Avoid

Letting Claude collapse legal gates. The regulatory workflow surfaces risk. It does not assess compliance. Every P0 item in the Risk Register goes to your legal and compliance team before you launch. Full stop.

Vague kill criteria. "Pause if things look bad" is not a kill criterion. Claude will draft specific, measurable thresholds if you ask — use them. The cost of a vague kill criterion is always paid in production.

Treating feedback synthesis as qualitative research. Claude organizes signal you provide. It cannot tell you about the users who never filed a ticket. Design partner interviews, session recordings, and contextual inquiry are not replaceable. Use this workflow to organize the signal you have, not to substitute for gathering it.

Over-indexing on competitor parity. The competitive benchmarking workflow defaults to gap analysis. That is useful. But "we are behind on dimension X" is not automatically a reason to build it. Differentiation is a valid response — make Claude flag it explicitly.

Starting specs without governance alignment. If your company has an AI review board, responsible AI team, or model risk management function, the spec workflow output is input to that process — not a substitute for it. Configure your Project instructions to reflect your company's actual governance gates.

Resources

Explore the AI Product Manager plugin for prompt workflows tuned to AI feature work
Browse the AI Product Manager profession hub for career and skill development resources
Run an AI readiness audit for AI PMs to assess your current AI product practice
Reference the NIST AI RMF at airc.nist.gov, EU AI Act Annex III at eur-lex.europa.eu, and FINRA Regulatory Notice 24-09 at finra.org — Claude cites these by name, but primary sources govern