AI prompts for product managers

10 free prompts · tested in ChatGPT, Claude & Gemini · browse the full library

Write a one-page PRD from a fuzzy product idea

Turn a rough brief or Slack message into a structured requirements document ready for an engineering conversation.

Write a one-page product requirements document (PRD) from the idea below.

The idea: idea
Target user: target user
Why now: why now

Structure the PRD as follows:
1. **Problem statement** — what the user cannot do today, and the cost of that. No features yet.
2. **Target user segment** — who specifically, described by behavior not demographic.
3. **Success metric** — one measurable outcome. "More engagement" is not a metric.
4. **Scope: in** — what this version includes.
5. **Scope: out** — what this version explicitly does not include.
6. **Open questions** — what the team must resolve before building starts.

Rules:
- Do not list features until the problem statement is solid.
- Every item in Scope: in must connect to the success metric.
- Open questions must be answerable — no rhetorical or philosophical ones.

Why it works: PRDs built feature-first solve the wrong problem. Forcing the problem statement and success metric before scope prevents the most common PM failure mode.
What to swap: The success metric is the hardest field. If you write 'improve retention', the model will let it through — push yourself to write a number and a timeframe.

Prioritize a backlog when everything is high priority

Force a ranked order from a mixed-signal list of tickets, ideas, and stakeholder asks.

Prioritize the backlog items below.

Strategic bets my company is making right now: strategic bets

Backlog items:
backlog items

For each item, score it on:
- **User impact** (1–3): how meaningfully does this improve the experience for the target user?
- **Strategic alignment** (1–3): how directly does this advance the strategic bets above?
- **Implementation effort** (1–3): 1 = low, 3 = high

Calculate a priority score: (user_impact × strategic_alignment) ÷ implementation_effort.

Output:
1. **Ranked list** with scores and one-sentence rationale per item.
2. **Top 5 to build next**, with the specific reasoning for each.
3. **Items to cut entirely** — things that score low on impact and alignment regardless of effort.

Do not hedge. Pick the order.

Why it works: Two positive signals multiplied together, divided by cost, produces non-obvious rankings. Single-axis scoring always surfaces the obvious safe choices.
What to swap: Strategic bets is the field most people leave vague. Tie it to actual company initiatives such as 'expand enterprise' or 'reduce churn below 2%'. Abstract values produce abstract bets.

Synthesise user interviews into one actionable insight

Distil messy research notes into a job-to-be-done statement and one decision you can act on.

Synthesise the user research notes below.

Research context: research context (e.g. "5 interviews with B2B ops managers about their reporting workflow")

Notes:
"""
research notes
"""

Produce:
1. **The primary job-to-be-done** in this format: "When [situation], I want to [motivation] so I can [outcome]."
2. **The three most repeated frustrations** — verbatim quotes. Do not paraphrase.
3. **The moment current solutions break down** — the specific point in the workflow where they fail.
4. **One decision to make** based on this research. Not a theme — a concrete next step.

If the notes are too thin to support a confident synthesis, say so and list what is missing.

Why it works: Research synthesis that ends in themes produces 'interesting, but what do we do?' The forced decision at the end is the only part that changes behavior.
What to swap: Paste raw notes. The model finds signal better than you do when the material is messy, and cleaning it up first removes exactly what it is looking for.

Write an internal launch brief for a product release

Give every team a single source of truth before a launch — sales, support, and marketing in one document.

Write an internal launch brief for the release below.

What is shipping: whats shipping
What is NOT shipping in this release: whats not shipping
Target user: target user
Launch date: launch date

Produce:
1. **One-sentence summary** — what this is and who it is for.
2. **What users should feel** after using this feature for the first time.
3. **Per-team proof points**:
 - Sales: the one thing they can say to a prospect evaluating this
 - Support: the top question customers will ask and the answer
 - Marketing: the single strongest proof point for the launch post
4. **What success looks like on day 7** — one specific, observable signal.
5. **What this is NOT** — to prevent scope-creep in customer conversations.

Why it works: Launch briefs written for one audience leave gaps that surface on launch day. Forcing a per-team section reveals the briefing holes before they become customer complaints.
What to swap: 'What is NOT shipping' is as important as what is. Fill it completely — it prevents over-promising in sales calls and support tickets on day one.

Turn a customer complaint into a testable hypothesis

Convert a raw frustration signal into a structured problem you can act on.

Turn the customer complaint below into a testable product hypothesis.

The complaint (use their exact words): complaint
Where in the product this happens: location in product
How often this comes up: frequency

Produce:
1. **The underlying need** — what the user actually wants, stated as a job-to-be-done. Do not restate it as a feature request.
2. **The broken job** — which part of their current workflow this complaint reveals as failing.
3. **A falsifiable hypothesis**: "If we [change X], then [users will do Y], and we'll know it worked when [metric Z] changes."
4. **The smallest experiment** that could validate or falsify the hypothesis in two weeks or less.

Do not suggest features. The hypothesis must be falsifiable — if there is no way to measure success, rewrite it.

Why it works: Complaints arrive as feature requests. This prompt converts them into experiments, which is how good product decisions get made instead of accumulating.
What to swap: Use the customer's exact words in the complaint field — paraphrasing removes the signal that tells you whether this is a surface frustration or a deep workflow failure.

Write acceptance criteria that close the gaps

Turn a user story into criteria an engineer cannot satisfy while missing the point.

Write acceptance criteria for this user story.

Story: user story
Who uses it and in what context: user context
What must not break: invariants
Out of scope for this story: out of scope

Produce:
1. Happy-path criteria, in Given/When/Then form
2. Edge cases, grouped: empty state, maximum state, concurrent use, partial failure, permissions
3. For each criterion, the observable outcome — something testable. "Works correctly" is not testable
4. A separate list of questions the story does not answer, each with the default you would assume if nobody replies
5. What is explicitly out of scope, restated so it cannot be quietly added

Rules:
- No criterion may contain "should", "properly", "as expected", or "user-friendly".
- If a criterion cannot be verified without asking a human's opinion, mark it and say what would make it objective.

Why it works: The list of unanswered questions with stated defaults is what turns a vague story into a decision — silence becomes an answer instead of a blocker.
What to swap: Fill `invariants` with the things that quietly break: billing, permissions, existing integrations. That is where the expensive regressions come from.

Turn a roadmap into a narrative people remember

Rewrite a list of planned features as an argument about where the product is going.

Turn this roadmap into a narrative.

Planned work: roadmap items
Time horizon: horizon
Who this is for: audience
The strategic bet behind it: the bet
What we are deliberately not doing: not doing

Write:
1. The one-sentence claim about where the product is going that all this work supports
2. Two or three themes that group the work, derived from the items themselves. Any item that fits no theme should be called out; never force it into one.
3. For each theme: what a user can do afterwards that they cannot do now
4. The sequence argument — why this order and no other
5. What we are not doing, and the reasoning, stated as a deliberate choice
6. The assumption that, if wrong, invalidates the most work here

Do not list dates against individual items unless they were given. Do not describe features by their implementation.

Why it works: Point 2 catches the item that fits no theme — usually the one being built for reasons nobody wants to say out loud.
What to swap: `the_bet` is the whole input. Without it you will get the same list with headings on top.

Decide whether to kill an underperforming feature

Make the sunset-or-invest call on a feature that is not working, with a defensible reason.

Help me decide whether to kill this feature.

The feature: feature
What it was supposed to achieve: original goal
Usage now: usage data
Who still uses it, and how badly they need it: active users
Cost to keep: maintenance cost
What killing it would free up: freed capacity

Work through:
1. Did it fail at the idea, the execution, or the distribution? These have different implications — say which, with the evidence.
2. If distribution: what is the cheapest test that would establish whether the idea works when people find it?
3. Who is genuinely harmed by removal, and is there a migration path?
4. The keep case, argued as well as it can honestly be argued
5. Your recommendation: kill, sunset over a period, invest in a fix, or leave it running with no further investment. Pick exactly one
6. If killing: the removal sequence, and what to say to the users who remain

Do not recommend "monitor for another quarter" unless you name what would change in that quarter and what decision it would trigger.

Why it works: Separating idea failure from distribution failure is what stops teams killing good features that nobody ever found.
What to swap: `active_users` needs the intensity, not just the count. Ten people who would churn matters more than a thousand incidental users.

Design an experiment that can actually fail

Turn a product hypothesis into a test with a pre-committed decision rule.

Design an experiment for this hypothesis.

Hypothesis: hypothesis
What we would do if it is true: action if true
What we would do if it is false: action if false
Traffic or users available: sample available
How long we can run it: time available

Produce:
1. The hypothesis restated so it is falsifiable, with a specific direction and magnitude
2. Primary metric: exactly one, and why you picked it over the obvious alternative
3. Guardrail metrics: what must not get worse, and by how much before we stop
4. The decision rule, written before the data: what result leads to which action, including the ambiguous middle
5. Whether the available sample and time can detect the stated effect. If not, say so plainly and give the minimum detectable effect they can support instead.
6. What could produce this result without the hypothesis being true

If the honest answer is that this experiment cannot be run usefully at this scale, say so. Do not design an underpowered version.

Why it works: Point 5 is the one that saves the most time — most product experiments cannot detect the effect they are looking for, and nobody checks before running them.
What to swap: If `action_if_false` is 'we'd probably still build it', do not run the experiment. Fix that first.

Rewrite one update for three different audiences

Produce exec, engineering, and customer-facing versions of the same update without three drafts.

Take this update and produce three versions.

Raw update: raw update
What actually changed since last time: whats new
What is at risk: risks
What I need from each audience: asks

Version 1 — Executives (150 words max): the decision or risk that needs their attention, the number that moved, and the ask. No feature names unless the name is the point.

Version 2 — Engineering (no limit): what changed and why, what it means for current work, what is now unblocked or newly blocked, and which decisions are still open.

Version 3 — Customer-facing (100 words max): what customers can now do, in their language. Nothing internal, nothing about roadmap timing, no commitments beyond what has shipped.

Rules:
- The three must be consistent. If a risk is real enough to tell engineering, do not omit it from the exec version — reframe it.
- Flag anything in the raw update that should not go to a given audience, and say why.

Why it works: Requiring consistency across the three versions catches the risk that quietly disappears from the exec update every time.
What to swap: `asks` should differ per audience. If you want the same thing from all three, you probably only need one update.

Frequently asked questions

PRDs that start with the problem, not the feature. Backlogs that force a real ranking. Research synthesis that ends in a decision, not a theme. Each prompt removes the escape hatch that default AI output takes. This page collects 10 free, copy-pasteable product management prompts, each tested in ChatGPT, Claude, and Gemini with a one-line rationale and the fields you need to swap in.