Claude for Product Managers: The Leverage Is in the Writing

Feedback synthesis at scale

500 support tickets, 40 sales-call notes, a quarter of NPS verbatims — pasted in, clustered by underlying job-to-be-done rather than surface keyword, with representative quotes attached. A week of intern work in twenty minutes, and better organized.

PRDs that survive engineering review

Claude drafts the spec, but its higher value is adversarial: 'find the underspecified edge cases an engineer will ask about' catches the gaps before sprint planning does — empty states, permissions, failure modes, migrations.

Prioritization with the politics removed

Score the backlog against stated criteria, surface the items where scores and gut disagree, and articulate the case for cutting things. Claude has no pet features and no stakeholder to please — use that.

The translation layer

The same decision explained to engineering (tradeoffs), execs (bets and numbers), sales (what to promise), and customers (what changed) — four documents, one source of truth, native tone for each.

Strategy sparring

Red-team the roadmap, steelman the competitor's approach, war-game 'what does the market leader do if we ship this?' The thinking partner every PM wants and few get.

Monday: the synthesis

Dump the week's customer signal (tickets, calls, reviews) into Claude. Cluster by job-to-be-done, quantify, attach quotes. The output feeds the priority discussion instead of the loudest-voice anecdote.

Wednesday: the spec

Draft the PRD with Claude from your bullet points, then flip it adversarial: unhandled edge cases, unstated assumptions, the questions engineering will ask. Fix on paper — where fixes are free.

Friday: the comms

One decision, four artifacts: eng brief, exec summary, sales enablement note, changelog entry. Claude drafts all four from the PRD; you fact-check the promises before they ship.

Feedback synthesizer

Here is raw user feedback from [sources]:
[paste it — more is better]

Synthesize:
1. Cluster by underlying user need, not keyword. Name each cluster by the job the user was trying to do.
2. For each: frequency, severity (blocks work vs. annoys), representative verbatim quote.
3. What are users asking for vs. what problem they actually have? Flag any cluster where the popular request is probably the wrong fix.
4. The three questions I should investigate next, given what's here.

PRD adversary

Review this PRD as a skeptical tech lead seeing it for the first time:
[paste PRD]

1. Every edge case and failure mode left unspecified — empty states, permissions, concurrent edits, what happens to existing data.
2. Requirements that are actually solutions in disguise (spec says HOW where it should say WHAT).
3. What's unmeasurable in the success criteria as written?
4. The question you'd ask in sprint planning that this document can't answer.

The cut list

Our capacity this quarter: [rough person-weeks]
The candidate list: [features with one-line descriptions and rough sizes]
Strategy context: [what the company must be true by year-end]

1. Score each against strategy contribution vs. cost. Show your reasoning, not just numbers.
2. Draw the cut line at 80% of capacity. Argue FOR cutting each item below it — the strongest honest case.
3. Which cut will generate the loudest internal objection, and what's the response that respects the objector?