Claude Code for product managers: research to a reviewed PRD

When Claude Code fits PM work

Claude Code is useful when the material for a task already lives in files: interview notes, a product brief, a preferred PRD structure, and earlier decisions. Give it those inputs and ask it to expose the gaps before writing. You still own customer interpretation, scope, and the launch decision.

You need a working Claude Code installation and model access. The PM Prompt plugin is free; it does not include a Claude subscription. See Claude Code documentation for current setup and account requirements.

1. Load the free product management plugin

The repository supports loading the plugin locally. Run these commands in a terminal, then work inside the resulting Claude Code session:

git clone https://github.com/pmprompt/claude-plugin-product-management.git
cd claude-plugin-product-management
claude --plugin-dir .

The PRD skill is available as /pmprompt:prd-writer. Check the plugin README for other installation options. Loading a plugin does not automatically give it your product background.

2. Prepare the evidence and product brief

Create product-context.md and interview-notes.md in the working folder. Use the interview worksheets to organize evidence first. Keep source IDs attached to quotes and use material you are permitted to provide to the tool.

3. Ask questions before generating requirements

Reference the files in your session and resolve important questions before drafting:

Read @product-context.md and @interview-notes.md.
Identify the user problem, supporting evidence, contrary evidence, and assumptions.
Ask up to five questions that would change the feature scope or success measure.
Do not invent research, customer counts, or integrations.

Useful questions include which fields the update needs, who may see them, and how you will record the baseline. Keep unresolved questions open in the PRD.

4. Draft the PRD with the PM skill

/pmprompt:prd-writer

Use @product-context.md, @interview-notes.md, and our answers above.
Draft a PRD for a reusable weekly status draft.
Include problem, evidence, goals, non-goals, permissions, requirements,
acceptance criteria, measurement plan, dependencies, and open questions.
Keep unverified claims labeled as assumptions. Save as weekly-status-prd.md.

Inspect proposed file changes before accepting them. Compare the structure against PRD examples, keeping sections that help your team make or implement a decision.

5. Review and make the requirements testable

Review @weekly-status-prd.md against the original source files.
Find unsupported claims, permission gaps, empty states, failure states,
untestable requirements, and scope that exceeds the first test.
Quote each problematic requirement, explain the issue, and propose a revision.
Do not edit the draft until I approve the changes.

This is a teaching example, not a recorded model benchmark. Review with engineering and design, or try the browser PRD reviewer for another pass.