Where AI actually fits in a PM week
Product management is four different jobs sharing one calendar. You read a lot (feedback, tickets, transcripts, analytics exports), write a lot (specs, updates, briefs), analyze a bit (funnels, cohorts, survey results), and persuade constantly. Each of those rewards a different model, which is why a single AI subscription covers roughly two thirds of the work and leaves the rest feeling like a fight.
| PM task | Best model | Why |
|---|---|---|
| PRD narrative, problem statements, product updates | Claude | Holds a long argument, writes prose an engineer will actually read |
| Feedback theming, ticket clustering, structured extraction | GPT | Reliable at strict output formats and consistent category labels |
| Discovery research, competitor scans, market context | Gemini | Best on recent web material, returns sources you can open |
| Long transcripts, research decks, 100 page reports | Gemini | 1M token context window, so the whole corpus fits in one pass |
| Spec critique and edge case hunting | Any model that did not write the spec | An independent reader catches what the author cannot |
None of this replaces judgment about what to build. It compresses the distance between having the inputs and having something written down, which is where most PM weeks actually leak time. The switching is cheap, too: on Whizi Pro a Claude Sonnet 5 message spends 10 credits of a 2,000 credit monthly allowance, a GPT-5.6 Luna extraction spends 1, and Gemini 3.7 Flash reads transcripts at 2 credits a message.
Writing a PRD an engineer will not send back
Most AI written specs fail on the same thing: they describe a feature rather than a decision. Engineering does not need a paragraph about why the customer matters. It needs the states, the edge cases, and what happens when the call fails. Prompt for that explicitly and the output changes character.
Prompt: problem statement first
Write the problem statement section of a PRD. Evidence I have: [paste support tickets, analytics, interview quotes]. Do not propose a solution. Return: who has the problem, how often, what they currently do instead, what it costs them, and what we would expect to change if it were solved. Mark any claim not supported by the evidence I pasted as ASSUMPTION.
Prompt: the spec body
Turn this into a specification for an engineering team. Feature: [description]. User states to cover: [list]. Return: user stories with acceptance criteria, every state including empty, loading, error, and permission denied, the behaviour when a dependency is unavailable, analytics events with their properties, and open questions. Do not invent requirements I did not state. List anything you had to assume in a separate section at the end.
Prompt: the critique pass
Act as a staff engineer reviewing this spec before estimation. List only the problems: undefined behaviour, missing states, requirements that conflict, hidden migration work, and anything that will produce a follow-up question in refinement. Do not rewrite the spec.
Run that third prompt in a model that did not write the spec. It reliably surfaces the three questions your team would otherwise raise in refinement, and answering them beforehand is the difference between a 20 minute grooming session and a 50 minute one.
Turning raw feedback into something you can prioritize
The highest leverage AI task in product management is not writing. It is reading 400 pieces of feedback in a form you can act on. Done manually this is a half day. Done well with a model it is 20 minutes, and the quality depends almost entirely on whether you force stable categories.
Prompt: first pass theming
Here is raw customer feedback. Cluster it into themes. For each theme return: a label, the count of items, the severity implied by the language, a representative verbatim quote copied exactly, and whether the theme is a bug, a missing capability, a usability problem, or an expectation mismatch. Do not merge themes that have different root causes even if the wording is similar. Do not paraphrase quotes. Feedback: [paste].
Prompt: second pass against a fixed taxonomy
Re-classify the same feedback using only these categories: [paste your existing taxonomy]. Anything that does not fit goes into UNCLASSIFIED with an explanation. Return a table of category, count, and percentage.
The two pass structure matters. The first pass tells you what is actually in the data. The second makes the result comparable to last quarter, which is what makes it usable in a prioritization conversation rather than just interesting.
| What to ask for | What you get | What it is good for |
|---|---|---|
| Themes with counts | A ranked list of problem areas | Roadmap input, quarterly planning |
| Verbatim quotes only | Unedited customer language | Copy, positioning, exec persuasion |
| Severity and frequency split | A 2x2 of pain against volume | Deciding what to fix first |
| Contradictions | Where segments want opposite things | Catching a false consensus early |
That last row is worth a standing prompt: Where in this feedback do different users want incompatible things? Name the segments and the tradeoff. A theme list flattens disagreement, and disagreement is usually the most useful thing in the data.
Discovery, competitors, and the research you never have time for
Discovery is the work that gets cut first when a release is late, which is precisely when a bad decision is most expensive. Model assisted scanning does not replace talking to customers, but it does replace the excuse for going into a decision blind.
Prompt: competitor teardown
Build a teardown of how [competitor] handles [job to be done]. Cover: their stated positioning in their own words, the flow as documented in their help centre, pricing where it is public, what changed in the last 12 months with dates, and the complaint themes visible in public reviews. Cite every claim with a URL. Separate what the company states from what third parties observe.
Prompt: interview synthesis
Read these interview transcripts. Return: the jobs users are trying to accomplish, the workarounds they have built, the moments where they expressed frustration with exact quotes, and any place where what a user said contradicts what they described doing. Do not generalise beyond the transcripts. If a pattern appears in fewer than three interviews, label it as a single observation rather than a pattern.
That last constraint is the one PMs most often forget. Models are eager to produce clean patterns, and a clean pattern from two interviews is how a roadmap ends up serving a customer who does not exist. Ask for counts alongside every claim.
Executive narrative and launch comms
The same content has to exist at four altitudes: a spec for engineering, an update for the team, a paragraph for the leadership review, and a launch note for customers. Rewriting between altitudes is the most mechanical work in the job and the easiest to hand off.
Prompt: altitude change
Rewrite this for [audience]. They care about [specific concerns]. They have [level] context on this product area. Keep every factual claim identical. Length: [constraint]. Lead with the decision or outcome, not the background. Draft: [paste].
Prompt: the leadership paragraph
Compress this update into 120 words for an executive who will read it once. Structure: what changed, what it means for the metric we committed to, what we need from them, and the single risk worth their attention. No adjectives that are not measured.
Prompt: the pre mortem
Assume this launch failed six months from now. Write the three most plausible explanations, ordered by likelihood, using only what is in the plan below. For each, state the early signal we could watch for. Plan: [paste].
Keep all four altitudes in the same Whizi thread. The launch note inherits the context from the spec and the feedback analysis, so you stop re-explaining the feature every time you change audience.
Where AI misleads product managers specifically
Three failure modes matter more in this job than in most others.
Fabricated verbatims. If you ask for representative quotes without pinning the model to the source text, you will sometimes get a plausible sentence no customer said. Always instruct copy quotes exactly, do not paraphrase, and spot check three of them against the raw data before any quote reaches a slide.
False confidence from small samples. A model will theme eight support tickets with exactly the same assurance it themes eight hundred. Ask for counts on every theme, and treat anything under a handful of instances as an observation rather than a signal.
Roadmap theater. Asking a model to prioritize your backlog produces a confident ranking derived from nothing but the words in your tickets. It has no access to your strategy, your capacity, your technical debt, or the deal that closes next quarter. Use it to structure the tradeoff, never to make the call.
- Save a PRD prompt template in Claude and a critique prompt to run in a different model
- Save a feedback theming template in GPT with your existing taxonomy pasted in
- Save a competitor scan template in Gemini that demands a URL for every claim
- Always ask for counts alongside themes, and treat small counts as observations
- Instruct the model to copy verbatims exactly, then spot check three against the source
- Run a pre mortem on every launch plan before the launch review, not after
- Keep spec, feedback, and launch comms in one thread so context carries across
Frequently asked questions
Can I paste customer interviews?
Yes. For long transcripts use Gemini: its 1M token context window holds roughly 2,000 pages of text, so a full set of interviews fits in one pass rather than being chunked. Strip names, emails, and company identifiers first. Roles and segments are all the analysis needs, and removing the rest keeps you clear of most internal data policies.
Does Whizi integrate with Jira or Linear?
Not natively yet. In practice the workflow is to generate the structured output in Whizi (user stories with acceptance criteria, a table of themes with counts) and paste it into your tracker, which takes seconds because the format is already what the tracker expects. Ask for the output as a Markdown table or as one issue per block if you want to paste them individually.
Which model writes the best PRD?
Claude for the narrative sections, meaning the problem statement, the rationale, and anything a human has to be persuaded by. GPT for the structured sections, meaning user stories, acceptance criteria, state tables, and analytics event definitions. Splitting the document between the two takes one extra model switch and noticeably reduces the editing pass.
Is it safe to paste internal roadmap or revenue data?
Whizi does not train on your conversations, and each provider’s data policy is available before you enable that model. Your company policy is usually the stricter constraint. A reliable habit is to index sensitive figures rather than pasting absolutes, since analysis of relative movement works identically and the numbers stop being sensitive.
Can AI prioritize my backlog?
It can structure the tradeoff, which is genuinely useful: score items against criteria you define, surface where two items depend on each other, and show which segments a given choice serves. It cannot make the call, because it has no visibility into your strategy, your team capacity, or the commercial context. Treat any ranking it produces as a prompt for discussion.