Below are 14 ChatGPT prompts for product managers, grouped by the work: customer research, specs and user stories, prioritization, and launches. Each one asks for a specific output, so you get a usable artifact instead of generic advice.
How to use these prompts
Every prompt is ready to copy into ChatGPT, Claude or Gemini. Replace the blanks in double braces, or keep the default after the colon: {{product:a B2B invoicing app}} means "a B2B invoicing app" unless you change it.
Two habits matter more than the exact wording. First, paste the real material: the interview notes, the backlog export, the draft spec. A model without your context fills gaps with plausible guesses, and plausible guesses are the worst kind of wrong in a PRD. Second, keep each prompt to one job. OpenAI's own ChatGPT prompting guide for work puts it plainly: "Tight scope usually beats a 'do everything' prompt." Run the synthesis prompt, read the result, then run the PRD prompt with what you kept.
Before pasting customer data, remove names and account details and check what your company allows.
Which prompts help with customer research?
1. Write an interview guide
Use it before a round of discovery calls. The rule about leading questions is the part that improves your data.
Write a 30-minute customer interview guide for {{product:a B2B invoicing app}}.
Goal of this round: {{goal:understand how finance teams chase late payments}}
Who we're talking to: {{audience:finance managers at companies with 20 to 200 staff}}
Include: a short intro script, 3 warm-up questions, 8 to 10 core questions
about past behavior (what they did last time, not what they would do), and
2 follow-up probes for each core question. No leading questions and no
questions that mention our product or a feature idea. Flag any question
that could still bias the answer.
2. Synthesize interview notes with quotes
Paste one or more transcripts. Asking for quotes first keeps every insight tied to something a customer actually said. Anthropic's guide to reducing hallucinations recommends this quote-first step for long documents.
Below are notes from {{count:5}} customer interviews about
{{topic:how they handle late invoices}}.
First, pull out word-for-word quotes that describe a problem, a workaround,
or a cost (time, money, stress). Label each quote with the interview it
came from.
Then group the quotes into themes. For each theme give: a one-line name,
how many interviews mention it, the strongest two quotes, and what we still
don't know. Only use what is in the notes. If a theme rests on a single
interview, say so.
<notes>
{{notes}}
</notes>
3. Tag a pile of feedback into themes
For support tickets, survey comments or app store reviews exported to a sheet.
Here are {{count:200}} pieces of user feedback, one per line.
Create 6 to 10 themes that cover them. Output a table with columns: theme,
description, number of items, two example items copied exactly, and
whether it reads as a bug, a missing feature, or confusion about something
that already exists. Put anything that fits no theme in an "Other" row and
list those items.
{{feedback}}
4. Competitor teardown from what you paste
Give it the competitor's pricing page, docs or changelog text. Without pasted sources, the model works from memory, which may be out of date.
Using only the material below about {{competitor:Competitor X}}, write a
teardown for a product team.
Cover: who it is for, the main jobs it does, how it prices, what it does
better than {{our_product:our product}}, where it looks weak, and three
questions we should answer with our own research. Mark anything that is
your inference rather than stated in the material with "(inference)".
<material>
{{material}}
</material>
Which prompts help write PRDs and user stories?
5. Problem statement one-pager
Write this before the PRD. If the problem doesn't fit on one page, the PRD won't fix it.
Turn my notes into a one-page problem statement for {{feature:automatic payment reminders}}.
Sections: the problem in two sentences, who has it and how often, evidence
(quote my notes), what happens today, why now, what success looks like in
numbers, and what is out of scope. Keep it under 400 words. List any claim
in my notes that has no evidence behind it.
{{notes}}
6. PRD first draft
Use it after the problem statement is agreed. The open questions list is often the most useful part.
Write a first-draft PRD for {{feature:automatic payment reminders}} in
{{product:a B2B invoicing app}}, based on the problem statement and notes
below.
Sections: summary, goals and non-goals, target users, user flows (step by
step), functional requirements (numbered), non-functional requirements
(performance, privacy, accessibility), success metrics, risks, and open
questions. Write requirements as testable statements. Do not invent
decisions I haven't made; put them under open questions instead.
{{problem_statement_and_notes}}
7. User stories with acceptance criteria
For turning a PRD section into tickets your engineers can estimate.
Break this requirement into user stories in the form "As a [user], I want
[action] so that [outcome]."
For each story, write acceptance criteria in Given / When / Then form,
including at least one error or empty state. Keep each story small enough
for one sprint; split it if not. Flag any story that depends on another.
Requirement:
{{requirement}}
8. Find the edge cases
Run it on any spec before review. It catches the states nobody designed.
Review this spec for {{feature:automatic payment reminders}} and list the
edge cases and failure states it doesn't cover.
Think about: empty and very large data, permissions and roles, time zones
and dates, network failures, duplicate actions, undo, accessibility, and
what happens to existing users when this ships. For each gap, say what
could go wrong and suggest the decision we need to make.
{{spec}}
Which prompts help with prioritization?
9. Score a backlog with RICE
RICE scores reach, impact, confidence and effort. The model is fast at the arithmetic; your team owns the inputs.
Score the backlog items below with RICE (reach, impact, confidence,
effort). Use these scales: reach = {{reach_unit:users per quarter}},
impact 0.25 / 0.5 / 1 / 2 / 3, confidence 50% / 80% / 100%, effort in
person-weeks.
Output a table sorted by score. Where I haven't given a number, propose
one, mark it "(estimate)", and explain it in one line. Then name the two
scores you are least sure about and what data would settle them.
{{backlog}}
10. Pressure-test a trade-off
For a decision between two directions, like building a feature or fixing onboarding first.
We have to choose between {{option_a}} and {{option_b}} for next quarter.
Context: {{context}}
Argue the strongest case for each option in turn. Then list the facts that
would change the decision, the cheapest way to learn each one, and what we
lose by waiting two weeks to decide. Don't pick a winner unless the
context makes one clearly better.
11. Success metrics and guardrails
Use it while writing the PRD, not after launch.
Propose success metrics for {{feature:automatic payment reminders}}.
Give: one primary metric, two or three supporting metrics, and two
guardrail metrics that would tell us we made something worse. For each,
the exact definition, where the data comes from, a realistic target for
{{timeframe:the first 60 days}}, and how we would know the change came from
this feature and not something else.
Which prompts help plan and announce a launch?
12. Launch plan
For a feature launch with several teams involved.
Write a launch plan for {{feature:automatic payment reminders}}, shipping
on {{date:the first week of next month}} to {{rollout:10% of accounts, then everyone}}.
Include a checklist by team (engineering, design, support, marketing,
sales), what has to be true before each rollout step, the rollback plan,
who to tell and when, and the first-week monitoring plan with the metrics
to watch. Format it as a table with owner and due date columns left blank.
13. Release notes users will read
Paste the ticket list. The output should read like a note to a customer, not a commit log.
Write release notes for {{audience:small business owners}} from the
shipped tickets below.
Lead with the change that matters most to them. Describe each change by
what the user can now do, in one or two plain sentences. Group small fixes
under "Also fixed". Skip internal changes. Keep it under 250 words.
{{tickets}}
14. Stakeholder update
For a weekly or monthly update that leadership actually reads.
Write a {{cadence:weekly}} update for {{audience:the leadership team}} from
my notes.
Structure: status in one line (on track, at risk, or off track, and why),
what shipped, what's next, decisions I need from them with a deadline,
and risks. Under 200 words. No jargon, no filler.
{{notes}}
How do you get better product work out of ChatGPT?
Feed it evidence and ask it to show its work. The OpenAI guide linked above suggests asking for sources, or asking the model to "quote directly from the provided material when possible", and to label anything uncertain. That habit matters most in synthesis, where a confident theme built on one interview can steer a quarter.
Put long material first. Anthropic's prompting best practices say to place long documents above your instructions and note that "Queries at the end can improve response quality by up to 30 percent in tests, especially with complex, multidocument inputs." For long transcripts in Claude, move the pasted notes or feedback above the instructions in the interview and feedback prompts; the order does no harm in ChatGPT.
Keep the judgment. The model is good at structure, coverage and first drafts. It does not know your strategy, your politics or which customer just threatened to churn. Edit every output before it goes to a stakeholder.
Make your favorite one a skill
If you run the PRD or synthesis prompt every week, turn it into a skill so Claude, Claude Code or Codex can follow it without the paste. Paste a prompt into the free SKILL.md generator and it becomes a valid SKILL.md, with each blank turned into an instruction. For writing prompts like these from scratch, see the prompt templates, and for launch copy, the marketing prompts.
To keep these one search away, save them in Kipt. Each prompt keeps its {{blanks}}, you can tag them by stage (research, specs, launch), and ⌘K finds one in a second. The library lives as Markdown in a private GitHub repo you own.