101 ChatGPT and Claude Prompts for Product Managers: Copy-Paste Templates for PRDs, Research, and Roadmaps

You are a senior product manager. A stakeholder sent this request:
[paste the request word for word]

Rewrite it as a problem statement. Include:
1. Who has the problem
2. What they are trying to get done
3. What happens today and why it falls short
4. How we would know the problem is solved

Then list the five questions I should ask the stakeholder before anyone writes a spec.

Use it when: A feature request arrives with the solution already decided.

Make it better: Paste the original message word for word. The model spots hidden assumptions better in the raw text than in your summary of it.

Here is a product idea: [describe the idea].

List every assumption it depends on, grouped under four headings:
1. Value: will people want it?
2. Usability: can they figure it out?
3. Feasibility: can we build it?
4. Viability: does it work for the business?

Rate each assumption as high, medium or low risk, and suggest the cheapest test that could prove it wrong.

Use it when: Before you commit a sprint to an idea everyone is excited about.

Make it better: Ask for the riskiest assumption first. Testing that one kills bad ideas fastest, and it's usually a value assumption.

Based on these interview notes:
[paste notes]

Write three jobs-to-be-done statements in this format: "When [situation], I want to [motivation], so I can [outcome]."

For each statement, quote the line from the notes that supports it. Flag any statement the notes only weakly support.

Use it when: After a round of customer interviews, when you need the underlying job instead of a list of feature requests.

Make it better: Requiring a supporting quote for every claim keeps the model from inventing needs your users never expressed. That's hallucination in research form.

Our desired outcome is: [outcome metric].
Here are the customer problems we've heard, with how often each came up:
[paste list]

Organize them into an opportunity solution tree:
1. The outcome at the top
2. Opportunities (customer needs or pain points) underneath
3. Two or three solution ideas under each opportunity

Mark which opportunities have the most evidence behind them.

Use it when: Your backlog is a flat list of ideas and nobody can say which outcome each one serves.

Make it better: The format comes from Teresa Torres's opportunity solution tree. Paste real evidence counts if you have them, or the model will guess at frequency.

Help me estimate how big this problem is: [describe the problem].

Build a simple estimate from these known inputs: [paste the numbers you have].
Show every assumption on its own line with the number you used. Give a low, likely and high estimate. Tell me which assumption moves the result the most.

Use it when: A leader asks how many people actually have this problem and you need an answer by the afternoon.

Make it better: Say which numbers are real and which are guesses, and ask the model to keep the two visibly separate in its answer.

I plan to solve [problem] by building [solution].

Act as a skeptical head of product. Give me:
1. The five strongest arguments against this solution
2. Two alternative solutions that don't use [technology or feature]
3. The evidence that would change your mind

Use it when: Right before you pitch an idea you're personally attached to.

Make it better: Tell the model to be blunt. By default models lean agreeable, a behavior called sycophancy, and a polite critique is a useless one.

Here is a user problem: [describe the problem].

Compare three ways to solve it:
1. Plain software rules
2. A traditional machine learning model
3. An LLM feature

For each, describe the build effort, the cost per use, the risk of failure and the data we would need. Recommend one, and say what would make you choose differently.

Use it when: Someone says "let's add AI" and nobody has asked why yet.

Make it better: Add your real constraints, like budget or response time. The recommendation changes a lot once the model knows them.

Below are [number] recent support tickets:
[paste tickets with names and emails removed]

Group them into problem themes. For each theme give:
1. A one-line name
2. The number of tickets
3. Two representative quotes
4. The likely root cause

Sort themes by ticket count. Put tickets that fit no theme in a separate "unclear" group.

Use it when: Once a month, to see what is really breaking for customers.

Make it better: Ask for the result as a table so it pastes straight into a doc, and keep the "unclear" group. It's often where a new problem starts.

I'm interviewing [type of user] about [topic].

Write a 30-minute interview guide with:
1. A short warm-up
2. Questions about the last time they faced [problem]
3. Questions about how they work around it today
4. A close

Use open questions only. Avoid anything that pitches our product or leads the answer.

Use it when: The day before interviews, while the research goal is fresh in your head.

Make it better: Paste your own draft questions and ask the model to flag the leading ones. That review is often more useful than a fresh guide.

Write a one-page problem brief from these notes:
[paste notes]

Sections: the problem, who it affects, the evidence we have, what we don't know yet, why now, and what success looks like.
Keep it under 400 words, in plain language, with no solution proposals.

Use it when: To align engineering and design on the problem before anyone opens a design file.

Make it better: Keeping solutions out of the brief is deliberate. Teams agree on a problem much faster than on a solution.

Here are notes from [number] user interviews, each labeled with a participant ID:
[paste notes]

Give me the five most important insights. For each:
1. The insight in one sentence
2. How many interviews support it (list the IDs)
3. Two direct quotes
4. One question it raises for the next round

Leave out anything only one person said, unless it describes a severe problem.

Use it when: After every research round, before you write up findings.

Make it better: Label each interview clearly so the model can count support per participant. Without IDs, it tends to overcount a single loud voice.

Review these research notes:
[paste notes]

Find places where users contradict each other, or where what users said contradicts what they did. List each contradiction with the evidence on both sides, and suggest how we could resolve it.

Use it when: When findings feel a little too neat.

Make it better: Contradictions usually point to different user segments. Ask the model to propose the segments that would explain each one.

Using only the evidence below, draft a lightweight persona for [segment]:
1. Their goals
2. Their main frustrations
3. The tools they use today
4. A typical week, in their own words

Mark every trait with the source line it comes from. Don't add demographic details the evidence doesn't contain.

Evidence:
[paste notes, quotes or data]

Use it when: When the team argues about who the user is and nobody points to data.

Make it better: Invented demographic details make personas feel real and quietly mislead the team. Ban them explicitly, as this prompt does.

Here are open-text survey responses, each with its score from 0 to 10:
[paste responses]

Split them into three groups: 9 to 10, 7 to 8, and 0 to 6. For each group, list the top three themes with counts and one quote each. Then tell me which theme from the 0 to 6 group would be cheapest to fix.

Use it when: After every survey wave, so the comments don't sit unread in a spreadsheet.

Make it better: Ask for counts, not percentages, when your sample is small. A percentage from forty responses looks far more certain than it is.

Here are [number] app store reviews with star ratings and dates:
[paste reviews]

Extract every specific complaint or request. Merge duplicates, count them and rank them by count. For the top five, write a one-line ticket title an engineer would understand.

Use it when: Before a planning cycle, or right after a release that changed ratings.

Make it better: Keep the dates in. Asking "what got worse after [release date]?" catches problems that a single release introduced.

Write a moderated usability test script for [feature or prototype].

Include:
1. An intro that tells participants we're testing the product, not them
2. Five realistic tasks written as scenarios
3. One follow-up question per task
4. A short wrap-up

The tasks must not mention button names or labels from the interface.

Use it when: A day or two before a usability study.

Make it better: Describe your prototype's screens or flow in the prompt so the tasks match what actually exists.

Here's a transcript of a usability session:
[paste transcript]

For each task, report:
1. Completed or not
2. Where the participant hesitated or got stuck
3. What they said at that moment (quote it)
4. The likely design cause

End with the three most severe issues from this session.

Use it when: Straight after each session, while you still remember the context.

Make it better: Run this once per session, then use prompt 11 across all the summaries. One giant prompt over every transcript loses detail.

Here's a sample of [number] customer feedback items:
[paste items]

Propose a tagging scheme with 8 to 12 tags that covers most items. Give each tag a one-line definition and one example. Then tag the sample and report how many items didn't fit any tag.

Use it when: When feedback piles up in several tools and nobody can see trends.

Make it better: If lots of items end up untagged, the scheme needs another pass. Iterate until fewer than one item in ten falls outside it.

Compare feedback from two segments. Every item is labeled A or B.
Segment A: [describe]
Segment B: [describe]
[paste labeled feedback]

Answer:
1. What do both segments want?
2. What does each want that the other doesn't?
3. Where do their needs conflict?
4. Which segment should we prioritize for [goal], and why?

Use it when: When one roadmap has to serve two kinds of customers.

Make it better: Label every item before pasting. Mixed-up labels produce comparisons that sound confident and are simply wrong.

I need to learn [research question] within [timeframe], with [budget or people available].

Propose a research plan:
1. The method (interviews, a survey, data analysis or a test)
2. Who to recruit and how many
3. What we'd ask or measure
4. Which decision the findings will change

Then give me the fastest version of the same plan.

Use it when: When a question keeps coming up in meetings and nobody owns finding the answer.

Make it better: Always name the decision the research serves. Research without a decision tends to end as a deck nobody reads.

Write a 10-question survey to learn [goal] from [audience]. Use mostly multiple choice, with one or two open questions.

For each question, note which decision it informs. Then review the list and rewrite any question that is leading, asks two things at once, or is hard to answer honestly.

Use it when: Before sending any survey to customers.

Make it better: Ask the model to predict the likely answers. If it can predict all of them, the survey won't teach you much.

Here are summaries of our past research studies:
[paste summaries]

Build an index with: study name, date, method, main finding and product area. Then list the questions about [product area] that our research has never answered.

Use it when: When you join a new team, or before a big planning cycle.

Make it better: The gap list is the valuable part. It shows you where the team has been guessing.

Compare [our product] with [competitor 1], [competitor 2] and [competitor 3] for [target user].

Use only this public information:
[paste pricing pages, feature lists and reviews]

Build a table with rows for: target customer, core job, pricing model, main strengths, main weaknesses and AI features. Mark anything you inferred rather than read in the sources.

Use it when: Before a strategy review or a positioning workshop.

Make it better: Paste the sources. From memory, models mix up old pricing plans and invent features that were never shipped.

Here are screenshots or step-by-step notes of [competitor]'s onboarding, in order:
[upload or paste]

Evaluate it:
1. Time to first value
2. Friction points
3. What they ask users for, and why
4. How they explain their AI features
5. One idea we should borrow

Be specific to the steps shown.

Use it when: When your activation rate lags and you want to see how others get users to value.

Make it better: Both ChatGPT and Claude read screenshots. Upload them in order and number the steps, or the analysis gets jumbled.

Here are the homepage headlines and taglines of five products in [category]:
[paste]

What promise does each one make? Which customer or job does nobody address clearly? Suggest three positioning angles we could own, each with a one-line headline.

Use it when: Before a rebrand, a launch or a new landing page.

Make it better: Give the model your product's real strengths first, and ask only for angles you could back up with proof.

Summarize this report for a product team:
[upload or paste the report]

Give me:
1. The five findings most relevant to [our product]
2. The numbers behind them, quoted exactly, with page references
3. What the report doesn't cover
4. One implication for our roadmap

Use it when: When a long industry report lands and nobody has time to read it.

Make it better: Page references let you check every number in seconds. Always check before a number goes into a deck.

Estimate the total, serviceable and obtainable market for [product] in [market].

Use a bottom-up method: number of target customers, times price, times likely adoption. Show each input, where it could come from and a range for it. Keep the facts I gave you separate from your assumptions.

Facts: [paste what you know]

Use it when: For a business case, an investor question or a new market bet.

Make it better: Leaders trust bottom-up estimates more than top-down ones because the math is visible. Keep it visible in the final doc too.

Create a sales battlecard against [competitor] using these inputs:
[our strengths, their strengths, win and loss notes]

Include:
1. When we win
2. When we lose
3. Three discovery questions that expose their weak spots
4. Answers to their two most common attacks on us
5. Proof points

Keep it honest. Sales teams stop using cards that overclaim.

Use it when: When sales keeps losing deals to one competitor.

Make it better: Real win and loss notes from deals make this far better than feature lists. Ask sales for five of each.

Here are [competitor]'s release notes from the last quarter:
[paste]

Group the changes by theme, say what strategy the pattern suggests, and flag anything that threatens our position with [segment].

Use it when: Once a quarter, as a standing ritual.

Make it better: Reuse the exact same prompt every quarter so the summaries stay comparable over time.

Do a SWOT analysis for [product] using only this evidence:
[paste]

Cite the evidence behind each point. Skip generic points that would apply to any company. Then turn the analysis into three strategic questions for leadership.

Use it when: Before a planning offsite or a board update.

Make it better: The "skip generic points" line matters. Without it, a SWOT fills up with lines like "strong team" that nobody can act on.

Draft three versions of a product vision for [product]:
1. One focused on the user
2. One focused on the market
3. One focused on the technology

Each under 30 words. Context: [who we serve, the problem, where we want to be in three years].
Then critique each version in one line.

Use it when: At the start of a planning cycle, or when the old vision no longer fits.

Make it better: Pick the strongest version and ask for five variations of only that one. Iterating on a winner beats generating more options.

Write a one-page strategy memo for [initiative] using these notes:
[paste notes]

Structure:
1. The situation
2. The main challenge
3. Our guiding approach
4. Three actions that fit together
5. What we will not do

Plain language, no buzzwords.

Use it when: Before you ask leadership to fund an initiative.

Make it better: The "what we will not do" section is where the strategy lives. Push back if the model leaves it vague or empty.

Write an internal press release as if [feature] launched today. Include:
1. A headline
2. A one-paragraph summary
3. The customer problem
4. How the feature solves it
5. An imagined customer quote, clearly marked as imagined
6. How to get started

Then write the five hardest questions a skeptical executive would ask, with answers.

Use it when: Before any big build, to test whether the idea is worth the effort.

Make it better: This is the working backwards format popularized at Amazon. If the release is boring to write, the feature probably is too.

Here's our strategy:
[paste]

Run a pre-mortem. Imagine it's 18 months from now and the strategy failed. Write:
1. The five most likely reasons it failed
2. The early warning sign for each
3. What we could do now to reduce each risk

Use it when: Right before a kickoff, while the plan can still change.

Make it better: Share the output with the team before the kickoff meeting. People raise risks more freely when failure is framed as hypothetical.

Our product: [description]. Our users: [who they are].

Identify five places where AI could create real user value. For each:
1. The user job
2. The AI capability needed
3. The data we'd need
4. The main risk
5. A rough value and effort rating

Rank the five. Then list two places where AI would be a bad idea for us, and why.

Use it when: When leadership asks for an AI strategy and the team has only a list of demos.

Make it better: The "bad idea" list keeps the analysis honest, and it's a strong talking point in AI PM interviews.

Assess how defensible [product] is. For each factor below, rate us strong, medium or weak with one reason:
1. Proprietary data
2. Workflow depth
3. Distribution
4. Network effects
5. Switching costs
6. Brand

Then suggest two moves that would most improve our position against a competitor using the same AI model we use.

Use it when: When someone calls your product "just a wrapper."

Make it better: Interviewers ask this exact question about AI products. The glossary entry on moats covers the answers that hold up.

Turn this strategy into one objective with three or four key results for next quarter:
[paste strategy]

Key results must be measurable outcomes, not shipped features. For each key result, name the baseline we'd need and how we'd measure it. Flag any key result a team could hit without helping users.

Use it when: At quarterly planning.

Make it better: The flagged key results are vanity metrics in disguise. Replace them before the quarter starts.

Rewrite this strategy for three audiences, each under 150 words:
1. Engineers: focus on why, and on the constraints
2. Sales: focus on what customers get, and when
3. Executives: focus on business impact and risk

Strategy: [paste]

Use it when: Before an all-hands or a roadmap review.

Make it better: Read the three versions side by side. If they contradict each other, the strategy itself isn't clear yet.

Write a PRD draft for [feature] from these notes:
[paste notes, research and constraints]

Sections:
1. Problem and evidence
2. Goals and non-goals
3. Users and use cases
4. Requirements (must, should, could)
5. Success metrics
6. Risks and open questions

Mark anything you had to assume with [ASSUMPTION].

Use it when: When you have scattered notes and need a first full draft.

Make it better: The [ASSUMPTION] tags are your review list. Resolve every one before the draft goes to engineering.

For an AI feature that [describe what it does], write the model behavior section of the PRD:
1. Ten example user inputs with the ideal output for each
2. Five inputs the feature must refuse or hand to a human
3. Tone rules
4. What the feature does when it isn't confident

Format it as a table.

Use it when: Any time a spec says "the AI will answer questions" and nothing more.

Make it better: These examples double as your first eval cases. Keep them in sync with the eval set as the feature changes.

Break this feature into user stories:
[feature description]

Use the format "As a [user], I want [goal] so that [reason]." For each story, write three to five acceptance criteria in Given, When, Then format. Flag stories that are too big for one sprint.

Here is one good story from our backlog to match: [paste example]

Use it when: During backlog refinement.

Make it better: The pasted example is few-shot prompting at work. One good example fixes format faster than a paragraph of instructions.

Here's a feature spec:
[paste spec]

List every edge case you can find, including empty states, errors, permissions, unusual data, slow networks, several people editing at once, and first-time versus returning users. Suggest the expected behavior for each.

Use it when: Before engineering estimates the work.

Make it better: Ask engineering to review the list. They'll add cases the model missed and remove ones that can't happen in your system.

Review this PRD as a skeptical staff engineer:
[paste PRD]

Point out unclear requirements, missing constraints, hidden complexity, and the questions you'd ask before estimating. Quote the lines you're questioning.

Use it when: Before you share a PRD with the wider team.

Make it better: Run a second pass as a designer and a third as a lawyer. Each role finds different gaps.

For [feature], write non-functional requirements for performance, reliability, security, privacy, accessibility and cost.

Make each one measurable, such as "95 percent of responses in under 2 seconds." Ask me for any number you need instead of inventing it.

Use it when: When a spec covers what the feature does but not how well it must do it.

Make it better: "Ask me instead of inventing it" works well in both ChatGPT and Claude. Add it to any prompt that needs real numbers.

From this meeting transcript:
[paste transcript]

Extract:
1. Decisions made, and who made them
2. Open questions
3. Action items with owner and due date
4. Anything that contradicts decisions already recorded in this doc: [paste doc]

If an owner or date isn't stated, write "unassigned" instead of guessing.

Use it when: After every planning or review meeting.

Make it better: This is the core of the meeting-to-execution copilot, one of the five AI PM portfolio projects. Build it once and you have a portfolio piece.

Write release notes for [feature] from this spec or ticket list:
[paste]

Write two versions:
1. For customers: what's new, why it helps, how to try it
2. For support: what changed, known limits, and what to tell customers who ask about [issue]

Use it when: On release day.

Make it better: Paste real customer wording from tickets. Release notes written in customers' own words get read.

Explain this technical document to me as a product manager:
[paste document]

Cover:
1. What the system does
2. Its limits
3. The product decisions it forces
4. What I should ask the engineers

Define any jargon in one line.

Use it when: When an architecture doc or design review lands in your inbox.

Make it better: Follow up with "quiz me on this document." It's the fastest way to check you actually understood it.

Write an experiment spec for testing [change]. Include:
1. Hypothesis
2. Primary metric
3. Guardrail metrics
4. Audience and split
5. A minimum sample size estimate, with the assumptions behind it
6. Duration
7. The decision we'll make for each possible result

Use it when: Before any A/B test goes live.

Make it better: Deciding in advance what you'll do if results come back flat is the most skipped step. The A/B testing entry explains why AI experiments need bigger samples.

For [feature], write an event tracking plan:
1. Event names, using our convention: [convention]
2. When each event fires
3. Properties to capture
4. The question each event answers

Include events for failures and abandonment as well as success.

Use it when: Before development starts, so tracking ships with the feature.

Make it better: Tracking failures is what lets you debug adoption later. Most tracking plans only cover the happy path.

This spec is too long:
[paste spec]

Cut it to what an engineer needs to start building. Keep the requirements and constraints, plus the open questions. Move background and rationale into a short appendix. Tell me exactly what you cut.

Use it when: When a spec has grown past the point anyone reads it end to end.

Make it better: The "tell me what you cut" line lets you catch anything important the model dropped.

Score these ideas with RICE (reach, impact, confidence, effort):
[paste ideas with any data you have]

Use a table. Explain every score in one line, mark scores that are guesses, and sort by final score. Then tell me which guesses I should validate first because they change the ranking most.

Use it when: Before quarterly planning, when the idea list is too long.

Make it better: RICE was introduced by Intercom's product team. The last question in this prompt tells you where to spend research time before you commit.

Here's the full scope for [feature]:
[paste scope]

Sort it into Must have, Should have, Could have and Won't have for an MVP that must launch by [date] with [team size]. Justify every Must have with the user problem it solves.

Use it when: When a launch date is fixed and the scope isn't.

Make it better: For AI features, add "guardrails and fallbacks count as Must have." See the MoSCoW entry for why.

Turn this backlog into a now, next, later roadmap:
[paste backlog]

Group items by the outcome they serve, not by team. For each outcome, name the metric it should move. Keep the "later" column deliberately loose.

Use it when: When a date-based roadmap keeps slipping.

Make it better: Outcome-based roadmaps survive change better than date-based ones, especially for AI work where model results can reshape the plan.

A [role] asked us to build [request]. We won't prioritize it this quarter because [reason].

Write a reply that:
1. Acknowledges their goal
2. Explains the trade-off with what we're doing instead
3. Offers an alternative or a date to review it again
4. Stays warm

Under 150 words.

Use it when: When you need to decline without damaging the relationship.

Make it better: Tell the model what the stakeholder actually cares about. A good no speaks to their goal, not to your roadmap.

We're choosing between [option A] and [option B] for [goal].

Build a decision matrix with 5 to 7 weighted criteria that matter for this decision. Score both options and show the math. Then argue for the losing option as strongly as you can.

Use it when: When a decision is close and the meeting keeps going in circles.

Make it better: The case for the losing option often surfaces a criterion you forgot to weight.

Here are next quarter's initiatives with their owning teams:
[paste list]

Identify dependencies between them, the critical path, and which items can run in parallel. Flag any initiative that depends on a team not on this list.

Use it when: While building the quarterly plan.

Make it better: Share the output with engineering leads. They'll catch dependencies that exist only in people's heads.

Before I ask engineering to estimate [feature], help me:
1. Break it into components
2. List the unknowns that will make estimates uncertain
3. Say which unknowns a one-day technical spike could resolve

Use it when: The day before a sizing session.

Make it better: You're not replacing engineering estimates. You're making the estimation meeting shorter and better informed.

Write a roadmap update for [audience] from these notes:
[paste notes]

Cover:
1. What shipped last quarter and its measured impact
2. What changed in the plan, and why
3. The top three priorities for next quarter

Be direct about anything that slipped, and put that in the first half.

Use it when: At the end of every quarter.

Make it better: Leaders trust updates that report slips plainly. Buried bad news costs you more credibility than the slip itself.

For [product], propose three candidate North Star Metrics. For each:
1. Why it reflects user value
2. How it connects to revenue
3. How it could be gamed
4. The two input metrics that drive it

Recommend one.

Use it when: When a team's goals feel disconnected from what users get.

Make it better: The "how it could be gamed" question separates a real metric from a vanity one. More in the North Star entry.

Build a metric tree for [goal metric] in [product].

Break it into input metrics a team could influence directly, two or three levels deep. For any AI feature, include at least one quality metric and one cost metric.

Use it when: When you set team goals, or when a top-line metric moves and nobody knows why.

Make it better: Ask which branches you have no data for yet. That list is your instrumentation backlog.

[Metric] dropped [amount] starting [date].

Give me a structured investigation plan:
1. Data checks (tracking bugs, seasonality)
2. Internal changes (releases, pricing, experiments)
3. External factors
4. Segments to break the data down by

Order the steps from fastest to check to slowest.

Use it when: The morning a dashboard turns red.

Make it better: Paste the release log for that week. The answer is often a release nobody connected to the drop.

Write a SQL query for [Postgres, BigQuery, Snowflake or another database] that answers: [question].

Tables and columns:
[paste schema]

Explain each step in a comment. Then list the assumptions the query makes about the data.

Use it when: When you need an answer today and the data team's queue is a week long.

Make it better: Always paste the real schema. See the SQL entry for why PMs are still expected to read and write it.

Explain what this SQL query does, line by line, in plain English:
[paste query]

Then point out any risk of wrong results, such as double counting from joins, time zone issues or missing filters.

Use it when: Before you trust a number someone else pulled.

Make it better: Double counting from joins is the most common analytics mistake. This check catches it in seconds.

Here are A/B test results:
[paste metrics, sample sizes and confidence intervals]

Our hypothesis before the test was: [hypothesis].

Tell me whether the result is statistically significant, whether it's large enough to matter, what could explain it, and what decision you'd make. Flag any warning signs, like a sample ratio mismatch.

Use it when: When an experiment finishes and the team wants to ship the winner.

Make it better: Including the original hypothesis stops the model from hunting for any metric that happened to move. See statistical significance.

I want to know whether [feature] improves retention.

Design a cohort analysis:
1. How to define the cohorts
2. Which retention measure to use
3. The comparison group
4. Confounders to watch for
5. The chart that would show the answer

Then write the SQL for [database] using these tables: [paste schema]

Use it when: A few weeks after a launch, when "did it work?" becomes the question.

Make it better: Ask how self-selection could fool the analysis. Users who try new features first are often your most engaged users already.

Here are this week's metrics, with last week's for comparison:
[paste]

Write a five-bullet summary for the team: what moved, what didn't, the most likely reason for each change, and one question worth investigating. Don't restate a number without saying why it matters.

Use it when: Every week, before the team sync.

Make it better: Paste the previous summary as well, so the model can call out trends instead of reacting to one week of noise.

For an AI feature that [describe it], define five metrics:
1. User value
2. Output quality
3. Safety
4. Cost
5. Latency

For each, describe how we'd measure it and what would count as good at launch.

Use it when: While writing the PRD for any AI feature.

Make it better: Usage alone hides quality problems. The task success and cost per task entries show what to track instead.

Write precise definitions for these metrics: [list].

For each:
1. The formula
2. The time window
3. What counts and what doesn't
4. The data source
5. One example calculation

Flag any metric two teams could plausibly calculate differently.

Use it when: When two dashboards show different numbers for the same metric.

Make it better: Metric fights in executive meetings usually come from two definitions behind one name. This doc prevents them.

Write a scoring rubric for evaluating the outputs of [AI feature].

Use 3 to 5 criteria, each scored 1 to 5, and describe what a 1, a 3 and a 5 look like. Include one criterion for accuracy against the provided sources and one for tone. Then score two example outputs against the rubric:
[paste two real outputs]

Use it when: Before you run any evaluation, human or automated.

Make it better: Test the rubric by having two teammates score the same ten outputs. If their scores differ, tighten the descriptions. The AI evals guide shows the full process.

Generate 30 test cases for [AI feature], which is meant to [purpose]:
1. 15 typical requests written the way real users write, with typos and vague wording
2. 10 edge cases
3. 5 adversarial inputs

For each, give the input and what a good response must do or avoid. Output a table.

Use it when: When you need an eval set before you have real user data.

Make it better: Swap generated cases for real user inputs as soon as you have them. Synthetic data is a starting point, not a finish line.

List the ways [AI feature] could fail its users. Group the failures:
1. Wrong answers
2. Harmful answers
3. Privacy leaks
4. Bad actions, if it can take actions
5. Poor experience (slow, confusing or overconfident)

Rate each failure's severity and likelihood, and propose a safeguard for it.

Use it when: While writing the risk section of an AI PRD.

Make it better: Put the top five failures into the PRD with a safeguard and an owner for each. Reviewers look for exactly that.

Act as a red teamer testing [AI feature]. It's supposed to [purpose] and must never [forbidden behaviors].

Write 20 test inputs that try to break those rules, including prompt injection hidden inside documents, role-play jailbreaks, requests for other users' data, and attempts to trigger actions the user didn't approve. For each, state the correct behavior.

Use it when: Before launch, and after any big model or prompt change.

Make it better: Run these only against your own product in a test environment. The OWASP Top 10 for LLM applications lists more attack types to cover.

We want [AI feature] to [goal]. Our data is [describe it and how often it changes].

Compare three approaches for this use case: prompting alone, RAG, and fine-tuning. Cover quality, cost, freshness, effort and risk. Recommend one approach and the smallest experiment that would validate it.

Use it when: At the start of any AI feature, and in interviews.

Make it better: This is the most common AI PM interview question in disguise. The RAG guide and the glossary's mix-ups table cover the reasoning.

Draft a system prompt for an assistant that [purpose] for [users]. Include:
1. Its role
2. What it can and can't help with
3. How to use the provided documents
4. How to cite sources
5. What to do when it doesn't know
6. Tone rules
7. Output format

Keep it under 400 words.

Use it when: When a prototype moves toward production.

Make it better: Version it from day one and record eval results for every version. See prompt versioning.

Review this system prompt:
[paste prompt]

Find contradictory instructions, ambiguous rules, cases it doesn't cover, and places a user could exploit. Suggest a revised version and explain each change.

Use it when: Whenever someone edits the production prompt.

Make it better: Pair this with prompt 72. Every weakness it finds should become a red-team test case.

For [AI feature], design the human review process. Decide which outputs:
1. Need review before users see them
2. Can be spot-checked afterward
3. Can be fully automated

Base each decision on risk. Describe the reviewer's screen, the decision options, and how reviews feed back into our evals.

Use it when: When an AI feature touches money, health, legal matters or customer trust.

Make it better: Ask how to keep reviewers from rubber-stamping. Automation bias quietly defeats most review steps.

We're building an agent that can: [list tools and actions].

For each action, decide whether it is:
1. Allowed without approval
2. Allowed with user confirmation
3. Not allowed

Justify each choice by the cost of a mistake and whether the action can be undone. Add logging requirements.

Use it when: Before an agent gets access to any real system.

Make it better: "Can it be undone?" is the single best question for agent permissions. The AI agents guide goes deeper.

Estimate the monthly cost of [AI feature] from these inputs:
1. Monthly active users: [number]
2. Requests per user per month: [number]
3. Average input and output tokens per request: [numbers]
4. Model price per million input and output tokens: [prices]

Show the math, the cost per task and the cost at ten times the usage. Then suggest three ways to cut cost without hurting quality, such as model routing, caching or shorter prompts.

Use it when: Before launch, and before any pricing conversation.

Make it better: Take prices from your provider's current pricing page, because model prices change often. See inference cost.

Write in-product copy for [AI feature] that tells users it's AI-generated, what it's good at, what it may get wrong, and how to check or report a bad answer.

Give two versions: a tooltip under 25 words and a help-center version under 120 words.

Use it when: Before any AI feature reaches users.

Make it better: Plain, honest limits build more trust than legal disclaimers. Test both versions with a handful of users.

Here are [number] AI conversations that users rated poorly:
[paste conversations]

Do an error analysis. Put each failure into one root cause: retrieval missed the right source, wrong reasoning, unclear instructions, missing data, an unnecessary refusal, or other. Count each cause and suggest a fix for the largest one.

Use it when: Every week after launch.

Make it better: This is the highest-value prompt in the group. Error analysis tells you what to fix next, in order.

Write a risk assessment for launching [AI feature] to [audience]. Cover:
1. Harm to users
2. Bias across user groups
3. Privacy
4. Security
5. Legal and regulatory exposure, including the EU AI Act if we serve EU users
6. Reputation
7. Cost overruns

For each: likelihood, impact, mitigation and owner.

Use it when: Before a governance or legal review, ideally before they ask for it.

Make it better: Arriving with this document turns a review into a conversation. See AI risk assessment.

Turn these notes into a weekly update for [audience]:
[paste notes]

Format:
1. A one-line summary
2. What shipped
3. What's next
4. Risks or blockers, and the help I need
5. One metric trend

Under 200 words. Put blockers where a busy executive will see them.

Use it when: Every Friday.

Make it better: Paste last week's update too. A consistent format week to week makes updates easy to skim.

I'm meeting [person and role] about [topic]. They'll probably push back on [issue].

1. List the five hardest questions they could ask
2. Give a short, honest answer to each
3. Tell me what data to bring
4. Then play that person and ask me the first question

Use it when: The night before a meeting you're dreading.

Make it better: Role-play works well in both ChatGPT and Claude. Answer out loud before you read the model's next reply.

Summarize this document for an executive who has two minutes:
[paste document]

Lead with the decision or the ask, then the three reasons, then the risk of doing nothing. Under 150 words. Skip background they already know.

Use it when: Before any document goes to leadership.

Make it better: Tell the model what this executive cares about most, such as revenue, risk or speed, and have the summary lead with it.

Explain this trade-off to [audience] without jargon:
[describe it, such as a faster model versus a more accurate one]

Use an everyday analogy, state what each option costs the business, and end with a recommendation and the reason for it.

Use it when: When non-technical leaders have to make a technical call.

Make it better: Ask the model where the analogy breaks down. Every analogy does somewhere, and you want to know where before your audience does.

Write a decision document for [decision] from these notes:
[paste notes]

Sections:
1. Context
2. Options considered, at least three, including doing nothing
3. Criteria
4. Recommendation
5. What we're giving up
6. How we'll know if we were wrong

Use it when: For any decision that will be questioned later.

Make it better: The last section turns the document into something you can revisit in three months and learn from.

We'll miss [deadline] for [project] by [time] because [reason].

Write a message to [stakeholders] that states the new date, explains the cause without making excuses, describes what we're doing about it, and asks for any decision we need from them.

Use it when: As soon as you know a date will slip.

Make it better: Send bad news early. Ask the model to cut any sentence that sounds defensive.

Summarize this Slack or email thread:
[paste thread]

Give me:
1. The question being discussed
2. The position each person took, by name
3. What was decided
4. What's still open
5. Who needs to act next

If nothing was decided, say so plainly.

Use it when: When you come back from time off to a 200-message thread.

Make it better: The last line stops the model from inventing a consensus that never happened.

Write an agenda for a [length] meeting about [topic] with [attendees].

Start with the decision we need to make. List the pre-reads. Give each item a time box and an owner. End with a two-minute recap of decisions and owners.

Use it when: When you schedule any meeting longer than 30 minutes.

Make it better: Send the agenda and pre-reads a day ahead. Meetings that name the decision up front tend to end on time.

Draft a go-to-market plan for [feature] aimed at [segment]. Include:
1. Positioning and the key message
2. Channels
3. Launch sequence: internal, beta, then general availability
4. Enablement for sales and support
5. Launch metrics

Context: [paste context]

Use it when: Four to six weeks before a launch.

Make it better: For AI features, add a line on expectations: what users can trust and what they should double-check. See GTM.

Create a launch readiness checklist for [feature] covering product, engineering, design, support, sales, marketing, legal, data and monitoring.

If it's an AI feature, also include: evals passed, guardrails tested, fallback ready, kill switch working and cost alerts set.

Use it when: Two weeks before launch.

Make it better: Give each checklist item an owner's name. A checklist without owners gets skimmed and ignored. See kill switch.

Write a launch announcement for [blog, email or in-app message] about [feature].

Open with the user problem, show the feature solving it in one concrete example, and end with how to try it. Stay under [number] words and skip hype words.

Use it when: Launch week.

Make it better: Give the model your own list of words to avoid. Every company has favorites that readers have learned to skim past.

Write a support brief for [feature]:
1. What it does
2. Who has access
3. The five questions customers will ask, with answers
4. Known limitations
5. How to troubleshoot the top three issues
6. When to escalate to the product team

Use it when: A week before launch.

Make it better: For AI features, include how to respond when a customer reports a wrong answer. Support needs a script for that on day one.

Design a beta program for [feature] on one page:
1. Who to invite, and how many
2. What we want to learn
3. How we'll collect feedback
4. The criteria for moving to general availability
5. How we'll wind the beta down

Use it when: When a feature is ready for real users but not for everyone.

Make it better: Set the graduation criteria before you invite anyone. Otherwise betas drift on for months.

Write a blameless post-launch review for [feature] from these inputs:
[paste metrics, feedback and incidents]

Cover goals versus results, what went well, what didn't, surprises, and three changes for next time.

Use it when: Four to six weeks after launch.

Make it better: Ask the model to separate what the data shows from what the team believes. Reviews often blur the two.

Rewrite these resume bullets for an AI Product Manager role:
[paste bullets]

Use this format: action, what you did, measurable result. Keep every fact true to what I wrote, and ask me for missing numbers instead of inventing them. Match relevant keywords from this job description where they're true for me:
[paste job description]

Use it when: Before every application batch.

Make it better: The "ask me for numbers" line stops invented metrics, which interviewers catch fast. The AI PM resume guide has bullet formulas that work.

Compare my resume with this job description.
Resume: [paste]
Job description: [paste]

List:
1. Requirements I clearly meet, with the evidence
2. Requirements I partly meet
3. Gaps

For each gap, suggest a portfolio project or experience that could close it within 30 days.

Use it when: When a role looks like a stretch and you want a plan instead of a guess.

Make it better: The AI PM resume keywords guide shows how to prove each keyword once you've closed the gap.

Act as an interviewer at [company] hiring an AI Product Manager. Ask me one product sense question about an AI product, then wait for my answer.

After I answer, score it from 1 to 5 on user focus, structure, AI trade-offs and metrics, and tell me what a 5 would have included. Then ask the next question.

Use it when: In the two weeks before an interview loop.

Make it better: Type your answer the way you'd say it out loud. Don't polish it. The 50 AI PM interview questions give you more material to practice with.

Here's something I did at work: [describe it].

Turn it into a STAR story (situation, task, action, result) that answers "[behavioral question]." Keep it under two minutes spoken. Make the result specific and measurable, and add one sentence on what I learned. Don't add details I didn't give you.

Use it when: While building your story bank for behavioral rounds.

Make it better: Write eight to ten STAR stories, then ask the model which common behavioral questions none of them answers well.

Write five LinkedIn headline options and a 150-word About section for me.
Target role: [role]
Proof I have: [projects and results]
Tone: direct and specific, no buzzwords.
Each headline must be under 220 characters.

Use it when: When you start applying, or after you finish a portfolio project.

Make it better: Headlines that name a specific result get more profile views than job titles alone. The LinkedIn guide has examples.

I received an offer for [role] at [company]: [offer details].
Market data I found: [paste ranges and sources].

Help me plan the negotiation:
1. My target number and my walk-away number
2. What to ask for beyond base salary
3. A script for the call

Then play the recruiter and push back on my first ask.

Use it when: The day you get an offer, before you reply.

Make it better: Use real market data, not the model's memory. The negotiation guide and the AI PM salary guide have 2026 ranges.