Choose by the output you need to make

ChatGPT Prompts for Product Managers

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

Role starter

Start with the task that matches your work

Choose a task, paste the real material, then copy one role-aware prompt.

Paste current workAudience and constraintsWho checks it

Ready checks3 of 3 ready

Current work is concreteReady

Paste notes, constraints, examples, or the half-finished version you already have.

Audience and constraints are clearReady

Name who will use the answer, where it appears, and what limits matter.

Who checks it is namedReady

Keep one person or review lens responsible before the answer is reused.

Prompt to run

Open full workflow

Help me start the right Product Managers workflow.
Task to use: Write PRDs: turn notes into product requirements document outline.
Paste current work: Need problem, users, goals, non-goals, user stories, metrics, risks, open questions, and acceptance criteria. PRD outline with choice 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..
Audience and constraints: PMs shaping product documents, requirements, customer signals, releases, and prioritization..
Who checks it: The review pass should catch unsupported certainty before a product requirements document outline becomes easy to copy..
Before writing, ask for anything missing that would change the write prds: turn notes into product requirements document outline output.
Return: The handoff should read like a working file, not a polished guess: facts, assumptions, missing inputs, and next action stay separate.
Stop if: Do not use the answer if it hides unsupported claims about provided context, examples, hard constraints, and the final human check or treats uncertainty as fact.

After the first answer

Save what came back, what needs fixing, and the next prompt change before moving to another task.

Answer returnedNeeds fixingNext try

0No role notes yet
Run the prompt once, check the answer, then save the problem and next try here.

Nothing saved yet

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 work to finish, 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 named human check.
Do not reuse a product managers prompt across unrelated tasks without changing inputs, constraints, and review checks.

Product Managers pages are organized by the choice a person is trying to make, not by a generic prompt collection. 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 the work in front of you

Write PRDs

Use when the next useful output is a product requirements document outline and the answer needs a product requirements document outline organized by context, output, caveats, and the next human action.

Write PRDs needs problem evidence, target users, scope boundaries, success metrics, risks, and open questions; the check focuses on product requirements document outline quality, problem framing and user story, and ready-to-use evidence, not a generic writing pass.

Write user stories

Use when the next useful output is user stories and the answer needs user stories with the usable answer first, then gaps and follow-up checks.

Write user stories needs user segment, job, pain, desired outcome, and acceptance signals; the check focuses on user stories quality, job situation and user motivation, and ready-to-use evidence, not a generic writing pass.

Define acceptance criteria

Use when the next useful output is acceptance criteria and the answer needs a scoring table with levels, observable evidence, and reviewer notes.

Define acceptance criteria needs feature goal, edge cases, roles, data states, and failure behavior; the check focuses on acceptance criteria quality, given-when-then states and edge cases, and ready-to-use evidence, not a generic writing pass.

Prioritize roadmaps

Use when the next useful output is a roadmap prioritization table and the answer needs a sequenced plan with stages, owners, timing, and choice checkpoints.

Prioritize roadmaps needs initiatives, evidence, effort, dependencies, risk, and business goal; the check focuses on roadmap prioritization table quality, evidence strength and effort, and ready-to-use evidence, not a generic writing pass.

Structure competitor analysis

Use when the next useful output is a competitor analysis and the answer needs a structured analysis table with claims, evidence, gaps, and recommended next step.

Structure competitor analysis needs competitor feature set, user workflow, pricing cues, roadmap signals, and customer jobs; the check focuses on competitor analysis quality, feature tradeoffs and user jobs, and ready-to-use evidence, not a generic writing pass.

Write release notes

Use when the next useful output is release notes and the answer needs release notes with copy-ready parts, needs-checking parts, and reuse fields.

Write release notes needs changes shipped, affected users, benefits, known limits, and upgrade actions; the check focuses on release notes quality, user impact and changed behavior, and ready-to-use evidence, not a generic writing pass.

Synthesize feedback

Use when the next useful output is a feedback synthesis and the answer needs a structured analysis table with claims, evidence, gaps, and recommended next step.

Synthesize feedback needs feedback items, segments, frequency, severity, quotes, and product area; the check focuses on feedback synthesis quality, theme frequency and segment contrast, and ready-to-use evidence, not a generic writing pass.

Plan customer interviews

Use when the next useful output is a customer interview guide and the answer needs a customer interview guide with copy-ready parts, needs-checking parts, and reuse fields.

Plan customer interviews needs research goal, participant segment, assumptions, questions, and follow-up plan; the check focuses on 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: turn notes into product requirements document outline

Use this prds workflow when product managers need to move from source notes to a shareable answer without losing the original limits. It keeps product requirements document outline quality, problem framing and user visible before reuse.

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 choice 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 provided context, examples, hard constraints, and the final human check or treats uncertainty as fact.

Write user stories Define acceptance criteria Prioritize roadmaps

Ready-to-run path

Write User Stories: review user stories

Start with this material: user segment, job, pain, desired outcome, and acceptance signals. Use the user stories workflow to create user stories, keep story set with acceptance signals visible, add reject rules, and show a product team, stakeholder, customer researcher, or release what to check next.

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 fails for user stories work because the note should become story set with acceptance signals. The next version should keep that rough note visible. This user stories work run should turn that note into user stories. For user stories work, paste the source as bullets, constraints, and audience notes so the model has enough shape for user stories with the usable answer first, then gaps and follow-up checks.
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: start from feature goal and edge cases

Turn feature goal, edge cases, roles, data states, and failure behavior into acceptance criteria with a worked input, a copyable run, and a second pass for weak sections. The reviewer checks acceptance criteria quality, given-when-then states and edge cases before reuse.

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 acceptance criteria work 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 acceptance criteria work, the supplied note becomes the base for acceptance criteria. A usable starting note for acceptance criteria work 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

Bring initiatives, evidence, effort, dependencies, risk, and business goal into the roadmap prioritization table workflow and keep evidence strength, effort, dependency, risk, and sequencing visible from the first run. product managers can check roadmap prioritization table quality, evidence strength and effort before sharing the result.

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 support, numbers, or authority that the user did not provide.

Write PRDs Write user stories Define acceptance criteria

Ready-to-run path

Structure Competitor Analysis: review competitor analysis

Use the competitor analysis page for a field-style example, runnable prompts, revision instructions, and checks for the user's notes, specific examples, constraints, and reviewer judgment. It keeps the result close to competitor feature set, user workflow, pricing cues, roadmap signals.

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 competitor analysis work 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 competitor analysis work, the supplied note becomes the base for a competitor analysis. A usable starting note for competitor analysis work 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: make release note version with user-impact rows reviewable

Use the release notes page for a field-style example, runnable prompts, revision instructions, and checks for the user's notes, specific examples, constraints, and reviewer judgment. It keeps the result close to changes shipped, affected users, benefits, known limits, and upgrade actions.

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 release notes work 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 release notes work, the supplied note becomes the base for release notes. A usable starting note for release notes work 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: use the product choice workflow for evidence context

The feedback synthesis page helps product managers turn rough notes into a feedback synthesis. It pairs the prompt with a concrete example, stop rules, and a next workflow when the task does not fit.

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 the rough request 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: check assumption and question ladder

Use the customer interview guide page for a field-style example, runnable prompts, revision instructions, and checks for true experience, measurable support, and target role fit. It keeps the result close to research goal, participant segment, assumptions, questions, and follow-up plan.

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 customer interview guide work 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 customer interview guide work, the supplied note becomes the base for a customer interview guide. A usable starting note for customer interview guide work 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 useful output is a product requirements document outline and the answer needs a product requirements document outline organized by context, output, caveats, and the next human action. Keep it separate because write PRDs needs problem evidence, target users, scope boundaries, success metrics, risks, and open questions; the check focuses on product requirements document outline quality, problem framing and user story, and ready-to-use evidence, not a generic writing pass.Write user storiesWrite user stories fits when the next useful output is user stories and the answer needs user stories with the usable answer first, then gaps and follow-up checks. Keep it separate because write user stories needs user segment, job, pain, desired outcome, and acceptance signals; the check focuses on user stories quality, job situation and user motivation, and ready-to-use evidence, not a generic writing pass.Define acceptance criteriaDefine acceptance criteria fits when the next useful output is acceptance criteria and the answer needs a scoring table with levels, observable evidence, and reviewer notes. Keep it separate because define acceptance criteria needs feature goal, edge cases, roles, data states, and failure behavior; the check focuses on acceptance criteria quality, given-when-then states and edge cases, and ready-to-use evidence, not a generic writing pass.Prioritize roadmapsPrioritize roadmaps fits when the next useful output is a roadmap prioritization table and the answer needs a sequenced plan with stages, owners, timing, and choice checkpoints. Keep it separate because prioritize roadmaps needs initiatives, evidence, effort, dependencies, risk, and business goal; the check focuses on roadmap prioritization table quality, evidence strength and effort, and ready-to-use evidence, not a generic writing pass.Structure competitor analysisStructure competitor analysis fits when the next useful output is a competitor analysis and the answer needs a structured analysis table with claims, evidence, gaps, and recommended next step. Keep it separate because structure competitor analysis needs competitor feature set, user workflow, pricing cues, roadmap signals, and customer jobs; the check focuses on competitor analysis quality, feature tradeoffs and user jobs, and ready-to-use evidence, not a generic writing pass.Write release notesWrite release notes fits when the next useful output is release notes and the answer needs release notes with copy-ready parts, needs-checking parts, and reuse fields. Keep it separate because write release notes needs changes shipped, affected users, benefits, known limits, and upgrade actions; the check focuses on release notes quality, user impact and changed behavior, and ready-to-use 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.