Choose by the output you need to make

ChatGPT Prompts for Product Managers

PMs shaping product documents, requirements, customer signals, releases, and prioritization.

Where ChatGPT helps this role

Turn rough notes into a reviewable asset for a product team, stakeholder, customer researcher, or release owner.
Convert a recurring product managers workflow into a reusable prompt sequence.
Ask ChatGPT for clarifying questions before committing to tone, format, or evidence.
Create a quick version for routine work and a deeper version for high-stakes work.
Review an existing answer against privacy, accuracy, and role-specific constraints.
Rewrite output for a different audience without changing the underlying facts.
Build a checklist that makes the human review faster and less subjective.

Main Risks

Prompts should surface assumptions and evidence gaps instead of pretending strategy is decided.
A broad prompt can hide missing source material, so product managers should name the exact evidence before asking for output.
Over-polished wording can make weak assumptions look finished; every page links the prompt to a review step.
Copying the same prompt across tasks weakens results because product managers need different inputs for planning, review, outreach, and explanation work.

Recommended Workflow

Pick the task page that matches the decision, not just the closest job title.
Prepare the source notes, audience, constraints, and forbidden assumptions before copying a prompt.
Run the prompt once for structure, then run a review prompt against facts, tone, and missing context.
Save the final prompt with the human review checklist so the workflow can be reused without becoming automatic.

Choose the first task by situation

Start with Write PRDs when the user has source notes but does not yet know the right output structure, then move to Write user stories or Define acceptance criteria only after the audience and review owner are clear.

Choose by situation

Choose Write PRDs when the main problem is shaping raw context into something a product team, stakeholder, customer researcher, or release owner can inspect.
Choose Write user stories when the user already has a first version and needs the next artifact in the same product managers loop.
Choose Define acceptance criteria when the risk is quality control, review consistency, or a clearer handoff to another person.
Open the role guide when the user cannot name the task yet and needs to decide whether to create, revise, review, or sanitize context first.

Avoid starting with

Do not start from a broad role prompt when the user already knows the concrete task.
Do not start from a writing prompt when the missing piece is source material or reviewer approval.
Do not reuse a product managers prompt across unrelated tasks without changing inputs, constraints, and review checks.

Product Managers pages are organized by the decision a person is trying to make, not by a long list of clever prompt phrases. The role page should help the user pick the first useful task, then the task page should carry the details: source material, variable fill, example, stronger prompt, and human review boundary.

Pick the workflow by decision

Write PRDs

Use when the next decision is the shape, review path, or reuse rule for a product requirements document outline.

Write PRDs needs problem evidence, target users, scope boundaries, success metrics, risks, and open questions; its review lens is product requirements document outline quality, problem framing and user story, and decision-ready evidence, not a generic writing pass.

Write user stories

Use when the next decision is the shape, review path, or reuse rule for user stories.

Write user stories needs user segment, job, pain, desired outcome, and acceptance signals; its review lens is user stories quality, job situation and user motivation, and decision-ready evidence, not a generic writing pass.

Define acceptance criteria

Use when the next decision is the shape, review path, or reuse rule for acceptance criteria.

Define acceptance criteria needs feature goal, edge cases, roles, data states, and failure behavior; its review lens is acceptance criteria quality, given-when-then states and edge cases, and decision-ready evidence, not a generic writing pass.

Prioritize roadmaps

Use when the next decision is the shape, review path, or reuse rule for a roadmap prioritization table.

Prioritize roadmaps needs initiatives, evidence, effort, dependencies, risk, and business goal; its review lens is roadmap prioritization table quality, evidence strength and effort, and decision-ready evidence, not a generic writing pass.

Structure competitor analysis

Use when the next decision is the shape, review path, or reuse rule for a competitor analysis.

Structure competitor analysis needs competitor feature set, user workflow, pricing cues, roadmap signals, and customer jobs; its review lens is competitor analysis quality, feature tradeoffs and user jobs, and decision-ready evidence, not a generic writing pass.

Write release notes

Use when the next decision is the shape, review path, or reuse rule for release notes.

Write release notes needs changes shipped, affected users, benefits, known limits, and upgrade actions; its review lens is release notes quality, user impact and changed behavior, and decision-ready evidence, not a generic writing pass.

Synthesize feedback

Use when the next decision is the shape, review path, or reuse rule for a feedback synthesis.

Synthesize feedback needs feedback items, segments, frequency, severity, quotes, and product area; its review lens is feedback synthesis quality, theme frequency and segment contrast, and decision-ready evidence, not a generic writing pass.

Plan customer interviews

Use when the next decision is the shape, review path, or reuse rule for a customer interview guide.

Plan customer interviews needs research goal, participant segment, assumptions, questions, and follow-up plan; its review lens is customer interview guide quality, assumption and question ladder, and fairness and policy fit, not a generic writing pass.

Open a prompt workbench

Review-first run

Write PRDs: prep product team, stakeholder, customer researcher, or handoff

This prds workflow helps product managers copy the right prompt, inspect the answer, and hand off only what the source supports. prds examples stay close to a planning document where a weak assumption can become roadmap work, so the prompt has a real work setting.

Turn problem evidence, target users, scope boundaries, success metrics, risks, and open questions into a product requirements document outline for a product team, stakeholder, customer researcher, or release owner.

Bring first: Need problem, users, goals, non-goals, user stories, metrics, risks, open questions, and acceptance criteria. PRD outline with decision and risk rows would be weak without the source details, so the evidence has to stay attached. The saved version should keep the one-time details editable. Product Managers should use the note as the base for a product requirements document outline. Before product managers run this, separate facts, preferences, and limits so the finished answer does not hide assumptions.
Reject if: Do not use the answer if it hides unsupported claims about source notes, examples, constraints, and reviewer judgment or treats uncertainty as fact.

Write user stories Define acceptance criteria Prioritize roadmaps

Ready-to-run path

Write User Stories: make story set with acceptance signals reviewable

Product Managers get a user stories run sheet with real input, source checks, answer repair, and a handoff path for a product team, stakeholder, customer researcher, or release owner. user stories gives the user a concrete story set with acceptance signals to inspect, not just wording to polish.

Turn user segment, job, pain, desired outcome, and acceptance signals into user stories for a product team, stakeholder, customer researcher, or release owner.

Bring first: Need stories by user type, job-to-be-done, acceptance criteria, edge cases, and open questions. Keep implementation out. Phrase shopping in write user stories fails because the note should become story set with acceptance signals. The next version should keep that rough note visible. This write user stories run should turn that note into user stories. For write user stories, paste the source as bullets, constraints, and audience notes so the model has enough shape for user stories formatted as clear sections, bullets, and a review checklist.
Reject if: Reject the answer if it invents facts, numbers, policy claims, citations, credentials, or examples that were not in the notes.

Write PRDs Define acceptance criteria Prioritize roadmaps

Ready-to-run path

Define Acceptance Criteria: keep criteria list with pass/fail examples sourced

Turn rough acceptance criteria notes into acceptance criteria; use the prompt, sample input, rejection rules, and review checklist together. acceptance criteria review starts at the moment where acceptance criteria can sound testable while states and edge cases are still missing.

Turn feature goal, edge cases, roles, data states, and failure behavior into acceptance criteria for a product team, stakeholder, customer researcher, or release owner.

Bring first: Need Given-When-Then criteria, permissions, empty states, errors, activity log events, and edge cases for revoked access. Examples for define acceptance criteria help only when they keep the source note visible while shaping criteria list with pass/fail examples. The response should leave the source trail easy to inspect. In define acceptance criteria, the supplied note becomes the base for acceptance criteria. A usable define acceptance criteria input includes what is known, what is uncertain, and what the reviewer must verify.
Reject if: Send it back for revision if it skips examples that sound plausible but cannot be tied back to the user's source.

Write PRDs Write user stories Prioritize roadmaps

Review-first run

Prioritize Roadmaps: check evidence strength and effort

Product Managers can start prioritize roadmaps from real notes, copy a ready prompt, and check roadmap prioritization table quality, evidence strength and effort, and decision-ready evidence before using the result. prioritize roadmaps needs a human pass that can replace polished filler with source-backed lines inside a roadmap prioritization table before the answer is reused.

Turn initiatives, evidence, effort, dependencies, risk, and business goal into a roadmap prioritization table for a product team, stakeholder, customer researcher, or release owner.

Bring first: Need prioritization table with user evidence, business goal, effort, confidence, risk, dependency, and recommendation. Product Managers need more than broad ChatGPT advice here; the answer has to work against the actual note and reviewer. The answer should start from the supplied details. a product team, stakeholder, customer researcher, or release owner should still see the note while a roadmap prioritization table is being built. Prioritize Roadmaps works better when the context is in named fields, because each variable can be checked before copying.
Reject if: Stop before sharing if it cannot show proof, numbers, or authority that the user did not provide.

Write PRDs Write user stories Define acceptance criteria

Ready-to-run path

Structure Competitor Analysis: keep competitor comparison grid with evidence gaps sourced

A real-use competitor analysis page with a field note, runnable prompts, repair instructions, and checks for source notes, examples, constraints, and reviewer judgment. competitor analysis review starts at the moment where competitor notes can blur observed facts and interpretation into one confident table.

Turn competitor feature set, user workflow, pricing cues, roadmap signals, and customer jobs into a competitor analysis for a product team, stakeholder, customer researcher, or release owner.

Bring first: Need table for activation steps, friction, user promise, pricing gates, missing evidence, and opportunities. Use observed screens only. Examples for structure competitor analysis help only when they keep the source note visible while shaping competitor comparison grid with evidence gaps. The response should not turn the case into broad advice. In structure competitor analysis, the supplied note becomes the base for a competitor analysis. A usable structure competitor analysis input includes what is known, what is uncertain, and what the reviewer must verify.
Reject if: Send it back for revision if it skips examples that sound plausible but cannot be tied back to the user's source.

Write PRDs Write user stories Define acceptance criteria

Ready-to-run path

Write Release Notes: keep release note version with user-impact rows sourced

A real-use release notes page with a field note, runnable prompts, repair instructions, and checks for source notes, examples, constraints, and reviewer judgment. release notes review starts at the moment where release notes can promise value beyond shipped behavior or setup reality.

Turn changes shipped, affected users, benefits, known limits, and upgrade actions into release notes for a product team, stakeholder, customer researcher, or release owner.

Bring first: Need release notes with user benefit, who is affected, what changed, setup action, known limitation, and support link. Examples for write release notes help only when they keep the source note visible while shaping release note version with user-impact rows. The response should not turn the case into broad advice. In write release notes, the supplied note becomes the base for release notes. A usable write release notes input includes what is known, what is uncertain, and what the reviewer must verify.
Reject if: Send it back for revision if it skips examples that sound plausible but cannot be tied back to the user's source.

Write PRDs Write user stories Define acceptance criteria

Review-first run

Synthesize Feedback: turn notes into feedback synthesis

For product managers handling synthesize feedback, this page keeps the source notes, audience, output shape, and reviewer visible in one run. synthesize feedback should only be saved after someone can replace polished filler with source-backed lines inside a feedback synthesis.

Turn feedback items, segments, frequency, severity, quotes, and product area into a feedback synthesis for a product team, stakeholder, customer researcher, or release owner.

Bring first: Need themes, evidence quotes, affected segments, frequency, severity, contradictions, product areas, and recommended next questions. a product team, stakeholder, customer researcher, or release owner can be misled by polished wording, so the reviewer check needs to stay visible. The model should not smooth away the missing context. Treat synthesize feedback as first-pass evidence for a feedback synthesis. Synthesize Feedback works better when the context is in named fields, because each variable can be checked before copying.
Reject if: Discard the answer if it cannot trace which details came from the source and which details were inferred.

Write PRDs Write user stories Define acceptance criteria

Ready-to-run path

Plan Customer Interviews: keep interview guide with assumption probes sourced

A real-use customer interviews page with a field note, runnable prompts, repair instructions, and checks for true experience, measurable proof, and target role fit. customer interviews review starts at the moment where interview guides can lead the participant instead of testing assumptions neutrally.

Turn research goal, participant segment, assumptions, questions, and follow-up plan into a customer interview guide for a product team, stakeholder, customer researcher, or release owner.

Bring first: Need interview guide, warm-up, behavior questions, probes, assumption checks, avoid-leading rewrites, and note-taking format. Examples for plan customer interviews help only when they keep the source note visible while shaping interview guide with assumption probes. A careful pass should keep the user's limit visible. In plan customer interviews, the supplied note becomes the base for a customer interview guide. A usable plan customer interviews input includes what is known, what is uncertain, and what the reviewer must verify.
Reject if: Send it back for revision if it skips examples that sound plausible but cannot be tied back to the user's source.

Write PRDs Write user stories Define acceptance criteria

Where to go next

Write PRDsWrite PRDs fits when the next decision is the shape, review path, or reuse rule for a product requirements document outline. Keep it separate because write PRDs needs problem evidence, target users, scope boundaries, success metrics, risks, and open questions; its review lens is product requirements document outline quality, problem framing and user story, and decision-ready evidence, not a generic writing pass.Write user storiesWrite user stories fits when the next decision is the shape, review path, or reuse rule for user stories. Keep it separate because write user stories needs user segment, job, pain, desired outcome, and acceptance signals; its review lens is user stories quality, job situation and user motivation, and decision-ready evidence, not a generic writing pass.Define acceptance criteriaDefine acceptance criteria fits when the next decision is the shape, review path, or reuse rule for acceptance criteria. Keep it separate because define acceptance criteria needs feature goal, edge cases, roles, data states, and failure behavior; its review lens is acceptance criteria quality, given-when-then states and edge cases, and decision-ready evidence, not a generic writing pass.Prioritize roadmapsPrioritize roadmaps fits when the next decision is the shape, review path, or reuse rule for a roadmap prioritization table. Keep it separate because prioritize roadmaps needs initiatives, evidence, effort, dependencies, risk, and business goal; its review lens is roadmap prioritization table quality, evidence strength and effort, and decision-ready evidence, not a generic writing pass.Structure competitor analysisStructure competitor analysis fits when the next decision is the shape, review path, or reuse rule for a competitor analysis. Keep it separate because structure competitor analysis needs competitor feature set, user workflow, pricing cues, roadmap signals, and customer jobs; its review lens is competitor analysis quality, feature tradeoffs and user jobs, and decision-ready evidence, not a generic writing pass.Write release notesWrite release notes fits when the next decision is the shape, review path, or reuse rule for release notes. Keep it separate because write release notes needs changes shipped, affected users, benefits, known limits, and upgrade actions; its review lens is release notes quality, user impact and changed behavior, and decision-ready evidence, not a generic writing pass.How to Use ChatGPT for Product ManagersUse this when the user needs a role-level workflow before opening a single task page.