How to Use Claude as a Product Manager: Interviews, PRDs, Priorities and Stories With Acceptance Criteria

9 min di lettura KissMySkills

Claude is useful for the paper side of product management: turning interview notes into evidence you can point at, finding ambiguity in a PRD before engineering does, auditing a prioritisation score, and writing user stories with testable acceptance criteria. It is weak where the job is human. It has never met your users, does not know your codebase, and will hand you a confident spec that hides every decision you have not made. Work in four passes (evidence, spec, priority, stories), make it quote your own notes, and treat every number it produces as an input to challenge.

Su questa pagina
  1. What do you give it before it touches a spec?
  2. How do you turn interview notes into evidence, not opinions?
  3. How do you find the holes in a PRD before engineering does?
  4. How do you stop prioritisation scores from being fiction?
  5. What does a user story with real acceptance criteria look like?
  6. What changes when the feature is AI?
  7. Where does Claude fail at this?
  8. Which product skill fits which job?
  9. How do you install a product management skill in Claude?
  10. All-in-one: every skill, one price
  11. Related guides
  12. Frequently asked questions
The skill this guide is built on
Prompts for Product Managers
Prompts for Product Managers
$9this skill, one-time

Prompts for Product Managers

Get Prompts for Product Managers →

What do you give it before it touches a spec?

Four inputs change every result more than prompt wording does. The decision the work feeds ("should we build bulk edit this quarter" beats "help with bulk edit"). Raw evidence, not your summary: a summary already contains your conclusion and Claude will agree with it. Constraints you already know, such as team size, deadline, platform limits and things already tried, because it cannot see your architecture. And what a wrong answer costs, since a reversible UI tweak and a pricing change need different caution. For a wider catalogue of prompts by task, see our roundup of Claude prompts for product managers; this guide runs four workflows in order.

How do you turn interview notes into evidence, not opinions?

The classic discovery mistake is remembering the quotes that agree with you. Ask a model for "the main themes" and it returns fluent themes whether or not your notes support them. Force a split between what people did and said and what you infer, with a quote on every claim. (Synthesis is only as good as the interviews: ask about specific past behaviour, not "would you use this", and keep your solution for the end.)

Synthesise these user interviews for a product decision. Use ONLY the notes below, not general knowledge about what users want. Decision: [DECISION]. Participants: [NUMBER], [SEGMENTS]. Notes (labelled by participant ID): [PASTE] Produce: 1. OBSERVATIONS: what people did or said, with IDs and a verbatim quote of 25 words or fewer. No interpretation. 2. PATTERNS: observations from at least [3] participants (list IDs); fewer goes under "single mention". 3. WORKAROUNDS: any hack or manual process described. 4. CONTRADICTIONS: disagreements, or said-versus-done conflicts. 5. INTERPRETATIONS: each tagged with its supporting observations and low/medium/high confidence. 6. WHAT THIS CANNOT TELL US, including whether [NUMBER] people is enough. Delete any claim with no supporting quote.

Check two or three quotes against your notes word for word, since tidied or fabricated quotes are the model's most dangerous habit here. Section 6 will often say a handful of interviews is not statistics. Take that as the point: this is direction, not proof.

How do you find the holes in a PRD before engineering does?

Drafting the first PRD is the least valuable thing Claude does; reviewing one is the most. Give it the role of a sceptical senior engineer and ask for questions, not a rewrite.

Act as a sceptical senior engineer reviewing this PRD before sprint planning. Find what is missing or ambiguous; do not rewrite it. PRD: [PASTE]. Constraints: [PLATFORMS, DEADLINES, DEPENDENCIES] Return: 1. AMBIGUITIES: each requirement readable two ways; quote it, give both readings and the question that resolves it. 2. UNDEFINED BOUNDARIES: unstated limits, empty state, first-time user, permissions, concurrency. 3. MISSING ERROR STATES. 4. HIDDEN WORK: migrations, backfills, admin tooling, analytics events, support training. 5. UNTESTABLE WORDS (fast, easy, intuitive, robust) with no threshold: ask me for the number; do not invent one. 6. TEN QUESTIONS for the author, ranked by cost of finding the answer late. Mark every guess as ASSUMPTION.

Section 5 earns its keep: "fast" in a requirement is a promise nobody can verify, and models love to supply "under 200 ms" with no basis. Send the top five questions to the people who can answer them and you have likely saved a planning session.

How do you stop prioritisation scores from being fiction?

RICE (Reach, Impact, Confidence, Effort) looks rigorous because it outputs numbers, but asked to score items a model supplies plausible inputs with no basis. Use it as a critic of your scores instead.

I scored these items with RICE. Audit my scoring; do not re-score or invent numbers. Scales: Reach = [PEOPLE PER QUARTER]; Impact = [0.25-3]; Confidence = [%]; Effort = [PERSON-MONTHS]. Table: ITEM | REACH | IMPACT | CONFIDENCE | EFFORT | EVIDENCE FOR EACH [PASTE] 1. Label each input MEASURED, ESTIMATED FROM DATA or GUESS, using only my evidence column (empty means GUESS). 2. Rank by my scores, then re-rank treating every GUESS as plus or minus 50 percent. Show which items swap. 3. Name any item where one GUESS drives the result and the single piece of evidence that would settle it. 4. Flag effort estimates under [0.5] that may be too low. 5. Give three questions to the team that would most change the ranking. Do not recommend a roadmap.

The sensitivity re-rank is the persuasive part: if your top item wins only when the guesses go your way, gather one more data point first. The pack above contains a RICE prompt that likewise asks which inputs are guesses.

What does a user story with real acceptance criteria look like?

"As an admin I want to export data" passes review and fails testing, because nothing in it can be tested. Good criteria describe observable behaviour, include unhappy paths, and are specific enough for a tester who skipped the meeting. Given/When/Then (the Gherkin convention many teams use) forces that.

Write user stories with acceptance criteria. Do not add scope. Feature: [DESCRIPTION]. Roles and permissions: [LIST]. Out of scope: [LIST]. Constraints: [PLATFORM, VOLUME, COMPLIANCE] Per story: title; "As a [ROLE], I want [ACTION], so that [OBSERVABLE OUTCOME]"; criteria in Given/When/Then covering a happy path, a validation failure, a permission failure and an empty or maximum case; a "NOT covered:" line; and an INVEST check naming any failing letter. Afterwards list open questions you could not resolve and mark each criterion that depends on one. Split any story over [3] days.

An illustration of the format (invented feature):

Story 4: Download invoice list as CSV. As a finance admin, I want to download the filtered list as CSV, so that I can reconcile it in a spreadsheet. AC1 Given filters are applied, when I click Download CSV, then the file has exactly the rows shown. AC2 Given the list is empty, when I open the menu, then CSV is disabled with a message. AC3 Given I lack the Finance role, then no download control shows and the endpoint rejects the request. AC4 Given more than [LIMIT TO BE CONFIRMED] rows, then [BEHAVIOUR TO BE CONFIRMED]. NOT covered: scheduled exports. Open question blocking AC4: maximum export size?

The bracketed AC4 is what you want: a visible hole for a human, not a number quietly made up.

What changes when the feature is AI?

The workflows hold, but model output is probabilistic: the question becomes how often it is wrong and what a wrong answer costs the user. Put three things in the spec before building: today's baseline for the metric you want to move, the quality bar to clear before shipping and how you will measure it, and whether you need a custom model or an existing service with good interface design. Irreversible actions deserve a human confirmation step. A one-line executive request is a scoping job first.

Another way in: a second skill for a different job
AI & Data Product Manager AI Skill - Cassius
AI & Data Product Manager AI Skill - Cassius
$19this skill, one-time

AI & Data Product Manager AI Skill - Cassius

Get AI & Data Product Manager AI Skill - Cassius →

Where does Claude fail at this?

It invents the user. Ask for "key user needs" without evidence and you get a list from general knowledge. Every need should trace to a participant or ticket; if it cannot, strike it.

It agrees with your hypothesis. State a favoured solution and it finds reasons it works. Give a kill condition up front and ask it to argue the opposite.

It treats a small sample as proof. Eight interviews find problems and poorly size them. Make it state the sample size next to each claim.

It writes specs that look finished. Fluent prose hides undecided questions. A PRD with no open questions is a bad sign.

It does not know your system. It cannot tell that a change touches a legacy module or that two engineers are available, so effort estimates are guesses.

It tests the happy path. Require validation, permission and empty-state criteria explicitly.

It cannot manage stakeholders. Who objects, and what was promised last review, is not in the chat.

Which product skill fits which job?

SkillBest forPrice
Prompts for Product ManagersThe weekly cycle: discovery, PRD, stories, prioritisation, roadmap, launch (24 prompts)$9
AI & Data Product Manager AI Skill - CassiusScoping an AI or data initiative: brief, metrics, build-versus-buy$19
All-in-oneBoth, plus every other skill in the catalog$12/mo or $69/yr

How do you install a product management skill in Claude?

With an All-in-one subscription there is nothing to download. Open Customize → Connectors, click +, choose Add custom connector and paste https://mcp.kissmyskills.com/mcp. Sign in with your email, then ask for a skill by name, for example "load Cassius". The same connector works in ChatGPT, Claude Code, Codex and Cursor; setup steps are on the connector page. Signing in is free, and your first skill call starts a 7-day free trial with every skill.

Bought a single file? The skill is a .skill file, a ZIP archive with SKILL.md inside. In Claude, turn on code execution under Settings → Capabilities, then Customize → Skills → + → Upload a skill, and toggle it on. The prompt pack is a plain text file to paste into a chat or Claude Project. In ChatGPT or Gemini, paste the SKILL.md contents into custom instructions.

All-in-one: every skill, one price

All-in-one is $12 a month or $69 a year, with 7 days free and every skill included, and a 30-day money-back guarantee. Read why a subscription, see the All-in-one plan, or open the connector setup.

Frequently asked questions

Is there a Claude skill for product managers?

Yes. Prompts for Product Managers is a pack of 24 prompts covering discovery, PRDs, user stories and acceptance criteria, prioritisation, roadmap communication and launch metrics. For AI and data initiatives, AI & Data Product Manager AI Skill - Cassius ($19) scopes the brief and routes work to the right specialist. Both are included in the $12/month All-in-one plan.

Can Claude write a PRD?

It can draft one, but its better use is reviewing one. Ask it to act as a sceptical engineer and list ambiguous requirements, undefined limits, missing error states and untestable words like fast or intuitive, each with the question that resolves it. A draft with no open questions is a warning sign.

Can Claude write user stories with acceptance criteria?

Yes, if you require specifics: Given/When/Then criteria covering a happy path, a validation failure, a permission failure and an empty or maximum case, plus a line stating what the story does not cover. Ask it to mark anything that depends on an unanswered question rather than invent a limit.

Can Claude analyse user interviews?

Yes, from transcripts you provide. Make it separate observations (what people did and said, with a verbatim quote and participant ID) from interpretations, then check a few quotes against your notes. It cannot run the interview, and a small sample points to problems rather than sizing them.

What is Claude bad at for product management?

It invents user needs when it has no evidence, agrees with the hypothesis you state, treats small samples as proof, writes finished-looking specs that hide undecided questions, and cannot see your codebase, team capacity or stakeholder politics. Its effort estimates and prioritisation inputs are guesses until the people who build and measure confirm them.

Skill · SKILL.md · Works with Claude & ChatGPTPrompts for Product Managers

Prompts for Product Managers

$9
Get Prompts for Product Managers →

Or get it with every other skill in All-in-one: $12/month, 7 days free, every skill.