30 ChatGPT Prompts for Product Managers (That Work as Well in Claude)

Most PMs have a folder of ChatGPT prompts they reuse. You drop in a feature idea, get a draft back, spend twenty minutes rewriting it, and ship something that's 80% there. It works. It's also leaving most of the value on the table.

The issue isn't your prompt phrasing. It's that a prompt by itself can only go so far. When ChatGPT has no idea what your product does, who your users are, or who you compete against, even a perfectly worded prompt returns something generic. You burn half your effort describing your situation and the other half fixing what came back.

Below are 30 prompts that consistently produce sharper output than the average PM gets from AI. (Want the short version? Here's a scannable 25-prompt cheat sheet you can keep open in a tab.) But the prompts aren't the real story. The real story is what sits underneath them — the context and the repeatable structure.

The most common pattern I see is a PM copying a prompt, pasting it into a chat box, having a back-and-forth, then copying the result into a doc somewhere else. That's not leverage — that's using a reasoning engine like a search bar. The jump from one-off prompts to repeatable systems is where the time actually comes back.

Why Prompts Hit a Ceiling

A prompt is a single instruction with no memory. A skill is that same instruction plus your context, plus a proven framework, plus a fixed output shape that comes out the same way every time. That gap is the whole game.

Every prompt in this guide runs in ChatGPT. It also runs in Claude, and most PMs find the results cleaner there — especially inside Claude Code, where context files keep your product details loaded so you stop re-explaining yourself on every prompt. Same prompt, less typing, better answer.

Treat these prompts as the on-ramp. They're useful today, and they preview what stops being manual once you've set up the infrastructure underneath them.

Discovery Prompts (1-6)

1. Turn Interviews Into Themes

Below are notes from [N] customer interviews about [topic]:
[paste notes or transcripts]

Pull this apart into:
- The 3-5 strongest themes, each backed by a direct quote
- Where the data reinforces what we already assumed about [persona]
- Where the data contradicts our current thinking
- The one finding that should change what we do next

Don't give me "users want it to be easier." Give me "5 of 7 abandoned
checkout at the address step and two of them said the form was confusing."

2. Pressure-Test a Problem

My hypothesis: [target persona] struggles with [problem statement].

The evidence I have so far:
[paste tickets, survey results, interview snippets, or gut signals]

Stress-test it for me:
- On a 1-10 scale, how strong is this evidence, and why?
- What's the most likely alternative explanation I'm ignoring?
- What single piece of new data would most change your confidence?
- Bottom line: real problem worth solving, or noise?

Be blunt. "This is three loud customers, not a pattern" is more useful
to me than a balanced overview.

3. Extract the Job to Be Done

Read these interview notes and surface the underlying jobs to be done.
Use this format: "When [situation], I want to [motivation], so I can
[expected outcome]."

Notes:
[paste notes]

For each job:
- Tag it functional, emotional, or social
- Mark whether it's directly stated or something you inferred
- Cite which interview backs it up
- Name the gap in how today's tools handle it

4. Build a Persona From Real Signals

Draft a user persona from the raw inputs below. Don't invent details —
work only from what I give you and flag anything you're assuming.

- Role / title: [job title]
- Company size: [range]
- Behaviors I've actually seen: [list]
- Pains pulled from interviews: [list]
- Tools in their stack today: [list]

Give me: a short bio, their top goals, what frustrates them, how they
work today, what they weigh when choosing a tool, and one realistic
scenario from their week. Make it concrete enough that my team can
say the persona's name in a review and picture a real person.

5. Write a Survey That Could Prove Me Wrong

I'm fielding a survey to test [hypothesis] with [audience].

- Decision this survey will inform: [decision]
- Target responses: [N]
- Channel: [in-app, email, etc.]

Write 8-12 questions that:
- Blend rating-scale and open-ended formats
- Use neutral wording — no leading the witness
- Include at least two questions capable of disproving my hypothesis
- Close with a question that flags people open to a follow-up interview

6. Mine a Feedback Pile

Here are [N] pieces of raw customer feedback from [source — support
tickets, reviews, NPS verbatims, sales notes]:
[paste feedback]

Work through it and tell me:
- The themes that repeat, ordered by how often they show up
- The emotional intensity behind each (blocked vs. mildly annoyed)
- Which are feature asks, which are bugs, which are workflow friction
- Whether one segment is over-represented in the complaints
- The single thing worth fixing this sprint, and why that one

Strategy Prompts (7-12)

7. Draft OKRs That Hold Up

Help me write OKRs for [team/product] for [quarter].

- Company priorities this quarter: [list 2-3]
- What my team is focused on: [list 2-3]
- Real constraints: [headcount, dependencies, tech debt I owe]

Give me 2-3 Objectives, each with 3-4 Key Results. Every KR must be:
- A number, not a verb ("reach 40% adoption," not "increase adoption")
- Set at roughly 70% confidence — a stretch, not a fantasy
- A leading indicator wherever possible, not only a lagging one

Then point out any two objectives that quietly fight each other.

8. Find Where I Win vs. a Competitor

- My product: [one-line description]
- Who I build for: [persona]
- The competitor I'm worried about: [name + one line]

Map out the head-to-head across these axes:
- Core promise to the customer
- Depth on a few things vs. breadth across many
- Pricing and how it's packaged
- How much our target markets overlap
- What makes switching painful for each of us

Take a side. "They both do roadmapping" tells me nothing. I need
"they own enterprise approvals; you own getting a 10-person team
live in an afternoon."

9. Rate the Risk Before I Commit

I'm deciding whether [problem] is worth solving for [audience].

What I know today:
[paste research, signals, or data]

Run it through the four product risks and rate each HIGH / MED / LOW
with a reason I can defend:
- Value — will anyone actually want this?
- Usability — can they figure out how to use it?
- Feasibility — can we realistically build it?
- Viability — does it make sense for the business?

End with the single riskiest assumption I should go validate first.

10. Write the Strategy Narrative

I'm presenting product strategy to [board / exec team / eng org].

- Strategy in plain words: [2-3 sentences]
- The bets we're making: [list]
- What we're deliberately NOT doing: [list]
- Evidence behind the direction: [data, customer signals]

Write a 500-800 word narrative that:
- Opens with the market shift that makes this strategy the obvious move
- States our position clearly, including the trade-offs we accepted
- Ties the strategy to specific moves this quarter
- Closes with a vivid picture of what winning looks like in 12 months

11. Spin Up a Lean Launch Plan

We're shipping [feature/product] within [timeframe].

- Who it's for: [audience]
- What it does for them: [core value]
- Channels I can actually use: [list]
- Budget reality: [number or "basically zero"]
- What counts as a win: [success metric]

Give me a go-to-market plan: positioning line, messaging (one headline
plus three supporting bullets), a sequence for pre-launch / launch day /
the week after, channel priorities, and the one metric I should watch
obsessively.

12. Recommend a Price, Not Three Options

I'm pricing [product/feature].

- Today's model: [free / freemium / paid]
- Buyer: [persona + company size]
- What competitors charge: [list]
- Roughly what it costs us to serve: [if known]
- The outcome the customer actually gets: [value]

Recommend one pricing structure using value-based pricing (reference
Van Westendorp if it helps). Give me the price point(s), the tier
breakdown if tiers make sense, and a tight paragraph on why this
number fits this buyer. Pick a lane — don't hand me a menu.

Specs & Documentation Prompts (13-18)

13. Generate a First-Draft PRD

Write a PRD for [feature name].

- Problem it solves: [user problem]
- Who it's for: [persona]
- Definition of success: [measurable outcome]
- Constraints: [tech, timeline, resourcing]
- What it connects to: [existing features]

Structure it as:
- Why this matters right now
- User stories with acceptance criteria
- Scope — what's in v1, what's explicitly cut
- Success metrics, split into leading and lagging
- Open questions and edge cases
- Dependencies

Skip implementation detail unless it shapes the product experience.
This is the handoff doc between me and engineering, not a tech design.

14. Split a Story Into Shippable Pieces

Here's a chunky user story:
"As a [role], I want to [action] so that [outcome]."

Break it into 4-8 smaller stories that could each ship on their own.
For every one:
- Keep the same "as a / I want / so that" format
- Add 3-5 acceptance criteria, in Given/When/Then where it fits
- Note any story it depends on
- Size it Small / Medium / Large with a one-line reason

15. Translate a PRD for Engineering

Here's a section of my PRD:
[paste excerpt]

Turn it into a technical spec outline an eng lead can react to:
- Which systems or components this touches
- Any data model changes
- New API surface, if any
- The key technical decisions still open
- Performance or scale considerations
- A short list of questions for engineering

I'm a PM, not an engineer. Keep it readable, but precise enough that
eng isn't guessing what I actually meant.

16. Draft Customer-Ready Release Notes

We shipped this:
[paste changelog, PR titles, or bullets]

- Audience: [customers / internal / both]
- Voice: [polished / casual / minimal]

Write release notes that:
- Lead with the benefit, not the feature name
- Group by impact: headline changes, smaller improvements, fixes
- Drop anything internal-only that users never see
- Keep each item to one sentence

17. Surface the Edge Cases I'm Missing

I'm speccing [feature]. The happy path looks like this:
[describe the intended flow]

List 15-20 edge cases I should plan for, grouped as:
- Input — empty states, max limits, weird characters, pasted junk
- State — two people editing, offline, interrupted mid-flow
- Permissions — wrong role, expired session, shared logins
- Integrations — a third-party API times out, sync fails, data conflicts

For each one, add a one-line note on what should happen instead.

18. Document an API Endpoint

Help me document this endpoint for our developer docs:

- Endpoint: [method + path]
- What it does: [purpose]
- Auth: [how it's secured]
- Request body: [schema or sample]
- Response: [schema or sample]

Produce docs with: a plain-English description, the auth model,
a parameter table (type + required/optional), a sample request,
a sample response, the error codes it can return, and rate limits.

Analysis Prompts (19-24)

19. Run a RICE Pass

Prioritize these candidates for next quarter:
[list 5-10 features, one line each]

Score every item with RICE:
- Reach — how many users hit this per quarter?
- Impact — 3 (massive), 2 (high), 1 (medium), 0.5 (low), 0.25 (tiny)
- Confidence — 100% (solid), 80% (decent), 50% (shaky)
- Effort — person-months

Show your math and call out any score that rests on an assumption I
should verify. Rank by RICE, then add a "gut check" column flagging
anything the formula is probably mispricing.

20. Diagnose a Leaky Funnel

Here's our conversion funnel:
[paste stages with numbers]

Walk me through:
- The biggest drop in absolute users
- The biggest drop in percentage terms
- A rough benchmark for each stage in our space
- Which stage has the most leverage on revenue if we fix it
- Three hypotheses for the worst drop-off
- What I'd measure to confirm or kill each hypothesis

21. Design a Clean A/B Test

I want to test [hypothesis].

- What exists now: [current state]
- What we'd change: [the variant]
- Primary metric: [what we measure]
- Traffic to this surface: [monthly users]

Lay out the experiment:
- Null and alternative hypotheses, stated plainly
- Sample size needed, with your assumptions shown
- Roughly how long until we'd hit significance
- Guardrail metrics that must not get worse
- Any segments worth analyzing separately
- The decision rule: what result means ship vs. iterate vs. kill

22. Build a Metrics Tree

I need a metrics framework for [feature/product area].

- North Star: [metric]
- Business goal it serves: [goal]

Construct the hierarchy:
- The single North Star
- 3-5 input metrics that move it (leading indicators)
- 3-5 health metrics that can't be allowed to slide
- 2-3 metrics specific to this feature

For each: a one-line definition, how it's measured, a target, and its
data source. Flag anything that needs instrumentation we don't have yet.

23. Structure a Churn Investigation

We're at [churn rate] monthly churn. Here's what I've got:
[paste cohort data, cancel reasons, usage patterns]

Help me structure the dig:
- Slice churn by cohort, plan tier, and acquisition source
- Name the most plausible drivers given the data
- Propose three retention experiments, ranked by expected return
- For each experiment, define the metric that tells me it's working

24. Frame a Build vs. Buy Call

We need [capability]. I'm torn between building it and buying
[vendor/tool].

Build path:
- Estimated effort: [person-months]
- Our team's depth here: [high / medium / low]
- Ongoing maintenance: [expected drag]

Buy path:
- Vendor: [name]
- Cost: [pricing]
- Integration lift: [high / medium / low]
- Switching risk later: [how locked in we'd be]

Run a build-vs-buy analysis with total cost of ownership at 12 and 24
months. Then recommend one path and defend it in three sentences.

Communication Prompts (25-30)

25. Write a Status Update Nobody Skims Past

Here's the raw week on [project]:
[paste bullets, notes, dumps]

Turn it into a stakeholder update with:
- What shipped, framed by user impact (not feature names)
- What's in flight, with expected landing dates
- What's blocked, and exactly what would unblock it
- Any decision I need from this group
- Metric movement worth flagging

Under 300 words. Lead with the thing that matters most. No "the team
made great progress this week" filler.

26. Compress It Into an Executive Summary

Summarize [document / analysis / research] for [CEO / board / VP Eng].

Source:
[paste or describe the full thing]

Write a 200-400 word summary that:
- Opens with the "so what" for this specific reader
- Lands the 3-5 findings or recommendations that matter
- Closes with a clear next step or ask
- Speaks their language — revenue for the CEO, capacity for the VP Eng,
  market position for the board

27. Align Stakeholders Over Email

I need [stakeholders] to get behind [decision].

- Background in one breath: [context]
- What I'm recommending: [the call]
- What we'd give up: [trade-offs]
- Who has to nod, and what each worries about: [list]

Write an email that:
- States the decision in the first two sentences
- Names each stakeholder's likely objection before they raise it
- Backs the recommendation with the evidence that matters to them
- Asks for specific feedback by [date]
- Stays under 500 words

28. Announce a Feature Internally

We shipped [feature]. Write the internal announcement for
[Slack / email / all-hands].

- What it does: [user-facing description]
- Why we built it: [the strategic reason]
- Who it touches: [segments]
- How to try it: [steps or link]
- What it doesn't do yet: [known gaps]
- Who built it: [credit]

- Tone: [celebratory but useful / matter-of-fact]
- Length: [Slack ~150 words / email ~300 words]

29. Prep for a Hard Conversation

I have to talk to [stakeholder role] about [topic], and it'll be tense.

- The situation: [what's going on]
- Where they're probably coming from: [their likely view]
- Where I stand: [my read on the right move]
- The actual friction: [where we'll clash]

Coach me through it:
- An opening line that acknowledges their side first
- My core points, in the order I should make them
- Questions that surface the constraints they're under
- A realistic outcome to aim for (not the dream scenario)
- A recovery move if it starts going sideways

30. Write the Board-Deck Product Section

Draft the product section of our board deck.

- Quarter: [Q]
- Wins: [list]
- Misses: [list]
- Metrics vs. targets: [list]
- Next quarter's priorities: [list]

Write a 500-700 word narrative that:
- Opens with where the product sits strategically
- Owns the wins without inflating them
- Faces the misses head-on, with root cause and the fix
- Weaves the metrics into the story instead of dumping numbers
- Pivots to next quarter with real conviction

From Prompts to a System

These 30 prompts deliver. Used well, they beat what most PMs are pulling out of AI today. But they're still prompts — every single time, you're setting the context, specifying the format, and policing the quality yourself.

These prompts run fine in ChatGPT. Where the manual work disappears is when the context and the framework stop living in a prompt you paste and start living in skills that load automatically — and that's what runs inside Claude Code. Same prompt, zero setup, consistent output. It's less about which tool is "better" and more about where the leverage compounds.

The path looks like this:

1. Set up context files — so the AI already knows your product, users, and competitors before you type a word.
2. Learn how to use Claude as a product manager — so the framework, format, and context loading happen for you, not by you.

The prompts here are the starting line. The system is where you stop re-explaining yourself.

Primary takeaway: prompts are the cheapest way to get value from AI today. Browse the free PM skills → to see what they look like once the context and frameworks come built in.

FAQ

Do these prompts work in ChatGPT and Claude?

Yes. Every prompt here is tool-agnostic — paste it into ChatGPT, Claude, or any capable chat assistant and it works. The variable is context: the more your AI knows about your product and users, the better the output. That's why these prompts tend to shine inside Claude Code, where context files stay loaded and you don't re-explain your product on every prompt.

What's the best ChatGPT prompt for a PRD?

Prompt #13 in this guide. The trick is filling in every bracket — the problem, the persona, the definition of success, the constraints, and what the feature connects to. A PRD prompt with rich inputs returns a draft you can edit in minutes; a vague one returns a generic template you'll rewrite from scratch.

How do I get better output?

Add context. The single biggest lever is telling the AI who your users are, what your product does, and who you compete with — every time, or once via context files so it's always there. Beyond that: ask for specifics over summaries ("name the segment, cite the quote"), and tell it to take a position instead of listing options.

Are there ready-made versions of these prompts?

Yes. The recurring ones — PRDs, competitive profiles, research synthesis, OKRs — exist as free PM skills that bundle the prompt, the framework, and your context into a single command. Browse the free PM skills → and download whichever maps to the work in front of you.

About the Author

Ron Yang is the founder of mySecond — he builds and manages PM Operating Systems for product teams. Prior to mySecond, he led product at Aha! and is a product advisor to 25+ companies.

Browse the skills directory →

Prefer Claude? 30 prompts tuned for it →