The prompt is the cheap part. The expensive part is knowing whether the answer is right, so every one of the 50 prompts below ends with a line on how to check the output.
A good prompt for a senior product manager (PM) does four things: it gives the model context, sets constraints, fixes the output format and tells the model to challenge its own answer. The model drafts. The PM decides. This guide gives you 50 prompts built that way, in six groups: discovery synthesis, PRD (Product Requirements Document) critique, roadmap and prioritisation trade-offs, metrics and experiments, stakeholder and executive communication, and AI-feature specifics such as evaluation criteria, failure modes and cost per task. They are written as plain instructions with no tool-specific features, so you can paste them into any current chat assistant.
If you only remember one line from this guide, make it this: before the model answers, make it list what it is assuming and what information it is missing, and after it answers, make it argue the opposite case. Those two instructions turn a flattering draft into something you can use in a review.
These prompts assume you already do the job. They do not teach what a good PRD or a good roadmap looks like. They give you a second reader to point at your documents: it can raise questions, argue the other side and draft the first version of the paperwork, while the judgement stays with you. If you are earlier in your career or new to prompting, start with ChatGPT Prompt Engineering: A Practical Guide and AI for Product Managers: A Practical Playbook, then come back.
Five questions senior product managers ask (quick answers)
- What makes a prompt suitable for senior work? It asks for judgement support, not text generation: critique, trade-offs, counter-arguments and gaps in the evidence. It names a role with a stake, sets limits and asks for a structure you can scan in a minute.
- Which assistant should I use? Any current chat assistant. Use the one your company approves for the kind of material you are pasting.
- Can I paste my real PRD or interview notes? Only if your company policy allows it for that tool, and only after removing personal and confidential data. See the data safety section below.
- How do I stop the model agreeing with me? Keep your preferred answer out of the prompt, ask for the strongest case against it, and ask for the review from someone who disagrees.
- How do I know the output is right? You cannot tell from the output alone. Every entry ends with a specific check, such as finding a quoted line in your source or recomputing a number.
What is in the list:
- Discovery synthesis: prompts 1 to 8
- PRD critique: prompts 9 to 17
- Roadmap and prioritisation trade-offs: prompts 18 to 25
- Metrics and experiments: prompts 26 to 33
- Stakeholder and executive communication: prompts 34 to 41
- AI-feature specifics: prompts 42 to 50
A scene you will recognise
This is an illustrative scenario, not a real company. A group product manager at a software company pastes a six-page PRD into a chat assistant late in the evening and types: "Review this PRD." The reply is a tidy summary, three strengths and a suggestion to "add more detail on edge cases". Nothing in it changes a decision in tomorrow's review.
The next morning the same PM tries again. The prompt now names a role (a sceptical staff engineer who has to estimate the work), sets a limit (only issues that block a confident estimate), fixes a format (a table with the section, the issue, why it matters and a question for the author, top five first) and adds a challenge (say what information is missing and what you assumed). The reply is a table of twelve rows. Four rows change the agenda of the review. Three are wrong, because the PRD answers the question two pages later. Five are fair but minor.
The PM keeps the four, deletes the three and spends ten minutes checking the rest against the document. The model did not review the PRD. It produced a list of questions, and the PM decided which ones were worth asking. That division of labour is the whole method.
How to prompt: context, constraint, format, challenge
Every prompt in this guide is built from the same four parts. When a prompt gives you a weak answer, one of the four is usually missing.
| Part | What to give the model | Example wording |
|---|---|---|
| Context | Who you are, who the output is for, the decision it feeds, and the material itself | "I am preparing the quarterly planning review for [audience]. The decision is [decision]." |
| Constraint | A role, a scope, a length, which sources it may use, and what it must not do | "Use only the notes below. Do not invent quotes. No more than 6 themes." |
| Format | The shape of the answer, so you can scan it and compare runs | "A table with columns: section, issue, why it matters, question for the author. Top five first." |
| Challenge | An instruction to expose gaps and argue back | "List your assumptions and the missing information first. Then argue the strongest case against your answer." |
Here is the weak version of a prompt, followed by the strong one, which is a short form of prompt 9 in this list.
Weak: Review my PRD.
Strong:
You are a staff engineer who has to estimate and build what this PRD describes. Find everything that would stop you giving a confident estimate. Output a table: section, issue, why it blocks estimation, question to ask the author. Rank the top five first and quote the exact words you are reacting to. List what you assumed and what information you would need to judge the document fully. Do not praise it. [PASTE PRD]
Two lines are worth adding to almost any prompt in the list:
Before you answer, list the assumptions you are making and the information you are missing. Do not fill gaps with guesses. After your answer, argue the strongest case against it and say what evidence would change your mind.
Five habits that matter more than any single prompt
- Paste the material, do not summarise it. Your summary hides the gaps the model could have found.
- Keep your own view out when you want a critique. A 2023 paper, "Towards Understanding Sycophancy in Language Models", found that five AI assistants consistently tailored their answers to match the views users stated. If you state a conclusion, ask for the alternative reading instead of asking whether you are right.
- Work in two passes. Ask for the analysis first. Then paste the answer back and ask the model to review it as a sceptic.
- Ask for evidence you can find. Quotes, section numbers, row numbers and formulas can be checked in a minute. Confident prose cannot.
- Save the versions that worked. Keep the prompt with its placeholders, and a note on what you changed, in a shared file. The section on team libraries near the end shows how.
How each entry is laid out
Every prompt follows the same pattern, so you can scan for the one you need: a Use it to line that says what it is for, the prompt in a block you can copy, Paste in to say what material to add, and How to check the output to say what you do before you rely on the answer. Replace every [square-bracket placeholder] before you send. Where a prompt tells the model to leave a marker such as [NEED] or [TBD], those markers are the work you still owe.
Data safety: what not to paste
Prompts like these work best with real material, and real material is where the risk sits. Before you paste anything:
- Follow your company's policy first. Use the tools your company approves for the kind of material you have. If there is no policy, ask before you paste, not after.
- Do not paste personal data. Names, phone numbers, email addresses, account and order numbers, and anything else that identifies a customer, colleague or candidate. Interview notes and support tickets often contain it. Replace people with IDs (P1, P2, T-014) and roles.
- Do not paste confidential business material you are not permitted to share. Unreleased financials, contract terms, customer lists, security details, source code, credentials and unannounced plans. Describe the structure and use dummy figures where you can.
- Prefer aggregates to rows. Paste a funnel table, not an export of user-level events.
- Read the settings of the tool you use, including whether conversations are retained or used to improve models. This varies by product and plan, so check your own.
India's Digital Personal Data Protection (DPDP) Act, 2023 applies to digital personal data. The Act defines personal data as any data about an individual who is identifiable by or in relation to that data. It applies to processing within India and, in some cases, to processing outside India that is connected with offering goods or services to people in India. The Digital Personal Data Protection Rules, 2025 were made under it. Whether and how the Act applies to what you paste into a particular AI tool depends on your facts, your role under the Act and your contracts, so check with your legal team. This is a pointer, not legal advice.
Group 1: Discovery synthesis (prompts 1 to 8)
Discovery produces more material than one person can hold in their head. These prompts help you organise it and test your conclusions. They do not replace listening to the customer. Anonymise everything before you paste: use participant IDs, not names.
1. Cluster interview notes into themes, with evidence
Use it to: turn notes from several interviews into a small set of themes, each traceable to the people who raised it.
You are a senior user researcher. Below are notes from [number] customer interviews about [topic]. Participants are identified only as P1, P2 and so on. Group the notes into no more than [6] themes. For each theme give: a one-line name, the participant IDs who raised it, one short quote copied exactly from the notes, and a count of participants. Keep what people did separate from what they said they would do. Then list: themes raised by only one participant, anything that contradicts a theme, and questions the notes cannot answer. Do not infer motives that are not in the notes. If a note only loosely fits a theme, say so instead of forcing it. [PASTE ANONYMISED NOTES]
Paste in: anonymised notes with one ID per participant. Keep context such as role and company size if it is safe to share.
How to check the output: find three of the quoted lines in your source notes, word for word. A quote that is not in the source is the clearest sign the output cannot be trusted. Recount one theme by hand. Then ask whether each theme is a real need or just the most talkative participant.
2. Extract the job, the trigger and the workaround
Use it to: see what made each customer look for a solution and what they do today instead.
Act as a researcher using a jobs-to-be-done lens. For each interview in the notes below, extract: (1) the situation that made the person look for a solution, (2) the job they were trying to get done, written as "When [situation], I want to [job], so I can [outcome]", (3) what they do today instead, and (4) what they said it costs them in time, money or risk. Give one table row per interview. Use only what is in the notes and write "not stated" where they are silent. Then list the three most common workarounds and the one that surprised you most, with one sentence on why. [PASTE ANONYMISED NOTES]
Paste in: the same anonymised notes, one interview per block.
How to check the output: count the "not stated" cells. A lot of them means your interviews did not probe the trigger, which is a gap in the research, not in the model. Confirm each workaround was described by the participant and not inferred.
3. Compare how two segments describe the same problem
Use it to: test whether a difference between two customer segments is real or an accident of who you interviewed.
You are an analyst comparing two segments: [segment A] and [segment B]. The notes below are tagged by segment. Compare how each describes [problem or workflow]: the words they use, what they treat as the main pain, what they have already tried, and what would make them switch. Output a table with one row per dimension and a column per segment. Label each cell "strong evidence" (three or more participants), "weak evidence" (one or two) or "none". Then say what extra interviews or data would confirm the three biggest differences, and give one reason each difference might not be real, such as sample size, who was recruited or how the question was asked. [PASTE TAGGED, ANONYMISED NOTES]
Paste in: notes tagged by segment and recruitment source, plus the number of participants in each segment.
How to check the output: count participants yourself to verify the evidence labels. A difference built on two interviews on one side is a hypothesis, so carry it forward as one.
4. Triage a batch of support tickets or survey comments
Use it to: sort free text into categories you can count, and surface what does not fit.
You are helping a product team categorise customer comments. Below are [number] comments, each with an ID. Create a taxonomy of no more than [10] categories based on what the comments say. Assign every comment one primary category and, where relevant, one secondary category. Output a table: ID, primary category, secondary category, one-line reason. After the table give a count per category, list the comments you were unsure about with the two categories you were torn between, and propose a category I may be missing. Do not merge categories to make the counts tidier. Do not add details that are not in the data. [PASTE ANONYMISED COMMENTS WITH IDS]
Paste in: a sample of comments with IDs, not the full history. Remove names, emails, phone numbers and order numbers.
How to check the output: label 20 comments yourself before reading the table, then compare and note the agreement rate. If it is low, tighten the category definitions and run again. Check that the counts add up to the number you pasted.
5. Critique an interview guide before you use it
Use it to: find leading questions, hypotheticals and missing follow-ups before they distort the evidence.
You are an experienced user researcher reviewing a discussion guide for [number]-minute interviews with [type of participant] about [topic]. Review the guide for: leading questions, questions that ask people to predict their own future behaviour, double-barrelled questions, jargon, and places where I am likely to talk more than the participant. For each issue, quote the question, say what is wrong and rewrite it. Then list the five most important things I will not learn from this guide and suggest a follow-up probe for each. Finish with any change to the order of questions and why. [PASTE DISCUSSION GUIDE]
Paste in: the guide, the research goal in one sentence and who you are recruiting.
How to check the output: read each rewritten question aloud as if you were the participant. Keep a rewrite only if it asks about something that happened, not something the person imagines they would do. Pilot the guide with one real person.
6. List the riskiest assumptions and the cheapest test for each
Use it to: turn an idea into a short, ranked list of beliefs that must be true.
You are a product coach. I am considering [product idea] for [customer segment]. List the assumptions that must be true for it to succeed, grouped as: desirability (do people want it), viability (does the business work), feasibility (can we build and run it) and usability (can people use it). Rank the 8 riskiest by how much the idea depends on each and how little evidence we have. For each, give the cheapest test that could run within [two weeks] without building the feature, the result that would count as evidence for, and the result that would count as evidence against. Mark any assumption where you had to guess my context. Context: [PASTE A SHORT BRIEF: the problem, what we know, what we have already tested]
Paste in: a short brief with the evidence you already have and your team's constraints.
How to check the output: cross out any test that is really a build in disguise. Ask your team which assumption they would bet money on being wrong. If it is not in the model's top three, the ranking is off.
7. Argue the opposite reading of your research
Use it to: stress-test a conclusion you are already leaning towards.
You are a sceptical research reviewer. My team's conclusion from this research is: [conclusion in one or two sentences]. Do not tell me whether it is right. Instead, build the strongest alternative interpretation of the same evidence, using only the material below. Give: the alternative conclusion; the three observations in the material that support it; the observations my conclusion has to ignore or explain away; and the specific extra evidence that would let us choose between the two readings. Finish with the one question I should ask in the next interview to tell them apart. [PASTE THE SYNTHESIS OR ANONYMISED NOTES]
Paste in: your synthesis or notes, plus your conclusion.
How to check the output: confirm every observation in the alternative reading really appears in your material. A good alternative rests on evidence you already have. If the model invented support, discard it. If the support is real, take it to the team.
8. Compare alternatives using only material you paste
Use it to: build a factual comparison table from public pages you have copied in, with no guessing about what is missing.
You are a competitive analyst. I will paste text copied from the public pages of [number] alternatives to [our product]: pricing pages, documentation and release notes. Build a comparison table with these rows: [dimensions, for example target customer, key capabilities, pricing model, limits, integrations]. Use only the pasted text. If a cell cannot be filled from it, write "not in the material". Do not use general knowledge about these companies and do not guess. Add the exact words from the text that support each cell. Then list three claims that look important but are not backed by the pasted text, and what I should look for to check them. [PASTE TEXT FOR EACH ALTERNATIVE, LABELLED]
Paste in: text copied from public pages, with the page name and the date you copied it.
How to check the output: open the source page for five cells and confirm the quoted words appear there and are current. Treat any cell without a quote as empty.
Group 2: PRD critique (prompts 9 to 17)
A PRD review is where a model is most useful and most dangerous: useful because it can be told to look for specific problems in every section, dangerous because a polite summary can pass for a review. These prompts give it a role that cannot be played by flattery. Strip company names, customer data and unreleased numbers first, or use the version your policy allows.
9. Review the PRD as a sceptical staff engineer
Use it to: find what would stop an engineer giving a confident estimate.
You are a staff engineer who has to estimate and build what this PRD describes. Find everything that would stop you giving a confident estimate: ambiguous requirements, unstated dependencies, missing edge cases, conflicting statements, and decisions that look made but are not. Output a table: section, issue, why it blocks estimation, question to ask the author. Rank the five most important issues first and quote the exact words you are reacting to. Then list what the PRD would need to include for you to judge it fully (for example expected load or data volumes) and the assumptions you made. Do not praise the document. [PASTE PRD]
Paste in: the PRD, plus a paragraph on the system it touches if you can share it.
How to check the output: read the top five against the PRD itself. Delete rows where the document already answers the question and keep the ones where it does not. Then ask your real engineer which two issues the model missed.
10. Test whether the problem statement is really a problem
Use it to: catch a solution disguised as a problem, and claims with no evidence behind them.
You are a product leader known for sending PRDs back. Read the problem statement and the evidence in this PRD. Answer: (1) Is it a problem or a solution in disguise? (2) Who has it, how often, and how do we know? (3) What kind of evidence is cited: observed behaviour, stated opinion, anecdote or data? (4) What happens if we do nothing for two quarters? (5) What is the cheapest alternative that is not what the PRD proposes? Then rewrite the problem statement twice: once in 40 words or fewer using only evidence cited in the document, and once marking every claim that needs evidence with [NEEDS EVIDENCE]. Do not add evidence that is not in the document. [PASTE PROBLEM STATEMENT AND EVIDENCE SECTIONS]
Paste in: the problem, evidence and goals sections of the PRD.
How to check the output: count the [NEEDS EVIDENCE] tags. Each is either a gap to close before the review or a claim to remove. If the model has added evidence of its own, it ignored the instruction, so run it again.
11. Check whether each requirement can be tested
Use it to: turn vague requirements into acceptance criteria and expose the ones with no measurable bar.
You are a QA (quality assurance) lead reading this PRD's requirements. For every requirement, say whether it is testable as written: "yes", "no" or "partly". For each "no" or "partly", quote the problem words (for example "fast", "intuitive", "seamless", "as needed") and explain what cannot be measured. Then rewrite the [5] least testable requirements as acceptance criteria in Given / When / Then form. Where a threshold is needed and the PRD does not give one, write [THRESHOLD NEEDED] instead of inventing a number, and list those at the end as questions for me. [PASTE REQUIREMENTS SECTION]
Paste in: the requirements section and any existing acceptance criteria.
How to check the output: take three rewritten criteria and ask whether two different engineers would write the same test from them. If not, tighten. Make sure every number in the criteria came from your document, not the model.
12. Audit the PRD against the sections you expect
Use it to: find thin or missing sections and get the list of questions you must answer.
You are reviewing a PRD against my team's expectations. A complete PRD for us has these sections: [list, for example problem, users, goals and non-goals, requirements, success metrics, risks, dependencies, rollout, open questions]. For each section, mark the PRD as: complete, thin (present but not enough to decide on), placeholder or missing. For each thin, placeholder or missing section, list the specific questions I must answer to complete it. Do not write the missing content and do not invent facts to fill gaps. End with the three gaps most likely to cause an argument in review. [PASTE PRD]
Paste in: the PRD and your team's section list.
How to check the output: compare two "complete" ratings with your own judgement. The real value is the question list: answer those questions yourself, not with the model.
13. Surface scope the PRD implies but never states
Use it to: write a non-goals section and find where scope can grow unnoticed.
Read this PRD as a stakeholder who wants more than it promises. List every piece of scope that is (a) explicitly in, (b) explicitly out, and (c) implied but never stated. For group (c), name the sentence that implies it and who is likely to assume it is included. Then draft a "Non-goals" section of at most [8] bullets, each with a one-line reason. Finally list the three places where scope could grow without anyone deciding, quoting the phrase in the document that allows it. [PASTE PRD]
Paste in: the PRD, and the names of the functions that will read it.
How to check the output: show list (c) to one engineer and one stakeholder and ask what they assumed. Every surprise is a conversation to have before the build starts, and every non-goal needs an owner who agrees to it.
14. Run a pre-mortem
Use it to: assume the feature has already failed and work backwards to the reasons, while the plan can still change.
It is [six months] after launch of this feature and it has clearly failed. Write the eight most plausible, distinct reasons it failed, drawing on the PRD below and on common product failure patterns. Cover different kinds of cause: customer behaviour, technical, organisational, market, data and dependency. For each, give: likelihood (high, medium or low), impact (high, medium or low), the earliest signal we would see, and one change to the PRD or plan that would reduce the risk. Then pick the two reasons you consider most likely and say what you assumed about our company to rank them. Do not list failures the PRD already guards against. [PASTE PRD]
Paste in: the PRD, the launch plan and any known constraints.
How to check the output: ask two colleagues to write their own five reasons before they see the list, then compare. Keep a reason only if it is specific to your context. Discard generic ones such as "poor communication".
15. List edge cases and failure states
Use it to: widen the list of cases the design and the tests must cover.
You are a product designer and a QA engineer reviewing [feature] for edge cases. Using the description below, list edge cases and failure states under these headings: first-time use, empty and error states, permissions and roles, concurrency and conflicts, scale and limits, slow or lost connectivity, accessibility, language and regional formats (for example [Indian languages, date and currency formats]), and data that arrives late or wrong. For each, state what the user would experience if we did nothing and the behaviour you would specify. Star the 10 most important and say why. Flag every case where the right behaviour depends on a business decision I need to make. [PASTE FEATURE DESCRIPTION]
Paste in: the feature description, the user roles and any limits already known.
How to check the output: walk through the starred cases against the real design or build. Ask engineering which are already handled. Remove cases your product cannot reach.
16. Build a dependency and risk register
Use it to: extract every dependency in the PRD, with owners and dates, and expose the unknowns.
From the PRD below, extract every dependency on another team, a vendor, a data source, legal or compliance review, or a decision not yet made. Output a table: dependency, type, what we need, owner (write "unknown" if the PRD does not name one), needed-by date (write "unknown" if the PRD does not state one), and what happens to the plan if it is late. After the table, list the dependencies with unknown owners and the three that look most likely to delay launch. Do not invent owners or dates. [PASTE PRD]
Paste in: the PRD and the team or vendor names you can share.
How to check the output: count the "unknown" cells, because they are your first-week work. Send the table to each named owner to confirm. Search the PRD for words such as "after", "once", "requires" and "depends" to catch dependencies mentioned only in passing.
17. Argue against shipping it
Use it to: prepare for the review by hearing the strongest case against the plan.
You are a principal product manager asked to argue against building this PRD in the coming quarter. Write a one-page argument against, using only what is in the document and general product reasoning. Open with your single strongest objection. Then give three more: an opportunity-cost argument, a risk argument and a timing argument. Mark every point that depends on an assumption about our company, and say what evidence would defeat each objection. Finish with what you would do instead with the same capacity. Be direct. Do not hedge or add praise. [PASTE PRD OR ONE-PAGE SUMMARY]
Paste in: the PRD or a one-page summary, plus the quarter's other priorities if you can share them.
How to check the output: rank the objections yourself. If the strongest one is something you cannot answer from evidence today, you have found work to do before the review. Use the output to prepare for an argument, not to win one.
Group 3: Roadmap and prioritisation trade-offs (prompts 18 to 25)
Prioritisation arguments are usually arguments about assumptions, not about scores. These prompts make the assumptions visible and test how fragile a ranking is.
18. Score with RICE (Reach, Impact, Confidence, Effort), then break the scores
Use it to: get a RICE table, a scoring model that Intercom described publicly in 2018, with the arithmetic shown and a test of how fragile the ranking is.
You are a product operations analyst. Score the initiatives below using RICE: score = (Reach x Impact x Confidence) / Effort. Use these scales: Reach = [users or accounts per quarter], Impact = [0.25, 0.5, 1, 2 or 3], Confidence = [percentage], Effort = [person-months]. Use only the numbers and notes I give. Where an input is missing, do not guess: write [MISSING] and leave that score blank. Show the formula with the actual numbers for each row so I can check the arithmetic. Then rank the initiatives and run a sensitivity check: for the top three, say which single input, changed by 30%, would change their order, and which score depends most on my own guess. Initiatives and inputs: [PASTE TABLE]
Paste in: a table of initiatives with your estimates and a note on where each estimate came from.
How to check the output: recompute two rows by hand or in a spreadsheet, and do not trust the arithmetic. Mark which inputs came from data and which from opinion. A ranking that flips on a 30% change is a conversation, not a result.
19. Sequence initiatives against capacity and dependencies
Use it to: draft a two-quarter plan and see what falls off it.
You are a delivery-minded product director. Given the initiatives, dependencies and team capacity below, propose a sequence for the next [two] quarters. Capacity: [engineers, designers, and fixed commitments]. Output a quarter-by-quarter table of what starts and finishes, what is left out, and the dependency or capacity reason for each placement. Then list the three assumptions that would break the plan most easily (for example an estimate that is a guess, or a dependency owned by another team) and the first sign we would see of each. If the information is not enough to place something, say what is missing instead of guessing an effort. [PASTE INITIATIVES, ESTIMATES, DEPENDENCIES]
Paste in: initiatives with estimates, dependencies and the capacity you really have, including leave and support load.
How to check the output: add up the effort in each quarter against capacity. Check that nothing is scheduled before the dependency it needs. Ask your engineering lead to challenge the two least certain estimates.
20. Write the "not now" list with cost-of-delay notes
Use it to: decline or defer requests with a reason the requester can understand.
I have to decline or defer these requests: [list]. For each, write a "not now" note with: what the requester is trying to achieve; what delaying it costs them and us (be specific about who is affected and when); what we are choosing instead; what would make us reconsider; and an interim workaround. Rank the requests by cost of delay, highest first, and label each as fixed deadline, rising over time, steady or fading. Use only the facts I supply and label every cost estimate as an assumption. Keep each note to 80 words, in a respectful, direct tone. Context and what we know: [PASTE]
Paste in: the requests, who made them, their stated reasons and what you are doing instead.
How to check the output: make sure each cost-of-delay label rests on a fact you supplied. Share one draft with a person who would receive it and ask how it lands. Edit every "no" yourself before it goes out.
21. Compare one big bet with several small ones
Use it to: see what would have to be true for each option to win.
We have capacity of [X] for the next [period]. Option A is one large bet: [describe]. Option B is [three] smaller bets: [describe]. Compare them on: value if it works, probability of working (say where your estimate is a guess), time to first learning, reversibility, fit with [our goal], and effect on team focus and morale. Output a table. Then say what would have to be true for A to be the better choice and what would have to be true for B. Finish with the single piece of evidence that would most reduce the uncertainty between them and the cheapest way to get it within [two weeks]. Context: [PASTE GOALS AND CONSTRAINTS]
Paste in: the options, the goal they serve and the constraints.
How to check the output: look at the probabilities and values the model assumed and replace them with your own. If the preference flips, the decision depends on that number, so go and find evidence for it.
22. Triage inbound feature requests for patterns
Use it to: turn a pile of requests into underlying problems and the questions to ask each requester.
You are a product manager's analyst. Below are [number] feature requests from sales, customer success and customers, each with the requester's team and stated reason. Group them into: (1) repeated requests pointing at the same underlying problem, (2) one-off requests, (3) requests that describe a solution when the underlying problem is unclear, and (4) requests that conflict with each other. For groups 1 and 3, name the underlying problem in one sentence and write the question I should ask the requester to find out what they are really trying to do. Count the requests in each group. Do not rank by who asked loudest. [PASTE ANONYMISED REQUESTS]
Paste in: requests with the team that raised each and the stated reason. Remove customer names.
How to check the output: spot-check a few counts. Take one "underlying problem" back to a requester and see whether they agree it is the problem.
23. Review the roadmap through three sceptical lenses
Use it to: prepare answers to the objections each function is likely to raise.
You are three reviewers of the draft roadmap below, one after the other: the head of finance, the head of sales and an engineering manager. For each, list the three objections they are most likely to raise, the question they would ask first, what they would want to see that is missing, and the part they would support without argument. Then identify the objection that appears in more than one lens and write a two-sentence answer I could give in the meeting. Base everything on the roadmap and the context I give you. Label anything that depends on guesses about these people. Roadmap: [PASTE ROADMAP] What I know about each function's priorities: [PASTE]
Paste in: the roadmap and what you know about each function's priorities.
How to check the output: compare it with what the real people said to you last time. The model works from roles, and real stakeholders have history. Treat the output as questions to prepare for, not a forecast.
24. Frame a build, buy or partner decision
Use it to: compare the three routes on the same criteria and list the questions to ask each side.
We need this capability: [describe]. Evaluate three options: build in-house, buy a product or service, and partner. Use these criteria: time to value, total cost over [three] years, control and differentiation, integration effort, risk if a vendor fails or changes terms, and what we learn by doing it ourselves. Output a comparison table, then recommend one option with a confidence level (low, medium or high) and say what would change your recommendation. I have not given you vendor prices. Where an estimate needs them, write [NEED QUOTE] and do not invent figures. End with the five questions I should ask vendors and the three I should ask our own engineers. Context: [PASTE REQUIREMENTS, CONSTRAINTS, WHAT WE KNOW]
Paste in: requirements, constraints and any real quotes you already hold.
How to check the output: every [NEED QUOTE] is work to do. Replace them with real quotes and run the comparison again. Check that the "control and differentiation" rating reflects how central the capability is to your strategy, which only you can judge.
25. Write the trade-off memo for a hard call
Use it to: put a decision on one page with the cost of choosing it and the signal that would reverse it.
Write a decision memo of no more than 500 words for [audience] on this decision: [the decision]. Use this structure: the decision needed and by when; options (three at most) with one sentence each; the criteria that matter and their weight; a recommendation with a confidence level; what we give up by choosing it; whether the decision is easy or hard to reverse; and the signal that would make us reverse it, and when we will look. Use only the facts below. Flag every claim you could not support from them with [UNSUPPORTED]. After the memo, write the strongest objection to the recommendation in 100 words, from the point of view of the person most affected by it. Facts: [PASTE FACTS, CONSTRAINTS, OPTIONS]
Paste in: the facts, constraints and options, and who will decide.
How to check the output: search the memo for [UNSUPPORTED]. Each one is evidence to find or a sentence to cut. Test the "easy or hard to reverse" call with engineering. If you can, read the objection to the person it is written from.
Group 4: Metrics and experiments (prompts 26 to 33)
Give the model definitions, designs and aggregates, not raw customer rows. These prompts help you design and question analysis. They cannot see your data unless you paste it, and they should never be the one to declare a winner.
26. Break a goal into a metric tree
Use it to: connect a goal to the inputs a team can move, and see which inputs you cannot measure yet.
You are a product analytics lead. Break this goal into a metric tree three levels deep: [goal, for example "increase weekly active teams"]. Level 1 is the goal, level 2 is the 3 to 5 drivers that multiply or add up to it, and level 3 is the specific inputs a product team can move. For each node give: a plain-language definition, the formula, the likely data source, whether we measure it today (write [UNKNOWN] if you cannot tell from my context) and one way it could be gamed. Mark the three nodes where the team has the most leverage and the three with the weakest measurement. Do not assume we have any data I have not listed. Context: [PASTE PRODUCT, USERS, WHAT YOU TRACK TODAY]
Paste in: a description of the product and users, and a list of the metrics you already track.
How to check the output: check that the maths works: do the children actually combine into the parent? Take the tree to your analyst and ask which nodes are measured the way the formula says.
27. Find the guardrail metrics for a target
Use it to: list the ways a target metric can improve while the product gets worse.
Our team's target metric is [metric], and the goal is [change]. Describe ten realistic ways this metric could improve while the product gets worse for users or the business, including changes to who is counted, how events are logged and what behaviour the team might be tempted to push. For each, name a guardrail metric that would reveal it, how to define it, and the kind of threshold to set (for example "must not fall by more than [X]%"). Do not invent thresholds; leave [X] for me. End with the three guardrails I should add to the goal or experiment document first, and why. Context: [PASTE METRIC DEFINITION AND RECENT CHANGES]
Paste in: the metric definition, how it is logged and any recent product or tracking changes.
How to check the output: pick the two ways of gaming the metric that your team could do by accident and check whether any existing dashboard would catch them. Set thresholds with your analyst from historical variation, not by feel.
28. Review an experiment design before launch
Use it to: catch design problems while they are still cheap to fix.
You are a senior experimentation analyst reviewing my A/B test plan. Check it for: a clear hypothesis; one primary metric; guardrail metrics; the unit of randomisation (user, account or session) and whether it fits the feature; interference between groups; the baseline rate, MDE (minimum detectable effect) and power I assumed; a duration that covers full weekly cycles; novelty effects; and how an SRM (sample ratio mismatch) check will be run. Output a table: item, finding (ok, risk or missing), what to change. List the numbers you cannot assess because they are missing. Do not calculate the sample size; tell me which inputs you need and why. Finally write the decision rule I should record before launch. Plan: [PASTE EXPERIMENT PLAN]
Paste in: the experiment plan, the primary metric definition and the traffic available.
How to check the output: calculate sample size and duration with your own tools or your analyst, not from the model. Confirm the decision rule was written before results were seen. Ask the analyst whether the unit of randomisation matches how the feature is really used.
29. Read experiment results sceptically
Use it to: list the ways a good-looking result could be misleading, and the cuts of data to request.
You are a statistician who distrusts good news. Here are the aggregated results of an experiment: [PASTE TABLE: variant, users, metric value, dates]. Without assuming the result is real, list the reasons it could be misleading: a mismatch between the planned and observed split of users, a novelty or primacy effect, a change in who entered the test over time, looking at results early, many metrics or segments inspected, seasonality, and a bug that affects only one variant. For each, say which number in my table would show it and which extra cut of data I should request from my analyst. Then say what you can and cannot conclude from the numbers as given. Do not declare a winner and do not run significance tests; tell me which tests an analyst should run. Context: [PASTE HYPOTHESIS, PRIMARY METRIC, PLANNED SPLIT, PLANNED DURATION]
Paste in: aggregated results only, with the plan they should be compared against.
How to check the output: compare the observed split of users across variants with the planned split yourself. A gap that chance does not explain is an SRM, which is a data-quality warning (see the Microsoft Research paper in the sources). Send the extra cuts you decide on to an analyst.
30. Write the hypothesis and the decision rule before the test
Use it to: commit to what counts as a win before you see any numbers.
Help me write a testable hypothesis and a decision rule before we run this experiment. Idea: [change]. Customer problem: [problem]. Draft: (1) a hypothesis in the form "If we [change], then [users] will [behaviour], because [reason], measured by [metric]"; (2) the primary metric and why; (3) two guardrails; (4) a decision rule with three outcomes, ship, iterate or stop, using placeholders for thresholds that I will set with my analyst. Then critique your own hypothesis: which part of the "because" is an assumption without evidence, and what alternative explanation would produce the same metric movement? Say what we would do if the result is flat. Context: [PASTE WHAT YOU KNOW]
Paste in: the idea, the problem, the evidence you have and the metric definition.
How to check the output: the "because" must be something you could be wrong about. If it only restates the change, push back. Put the decision rule in the experiment document and get your analyst and a stakeholder to agree it before launch.
31. Investigate a metric that moved
Use it to: get an ordered list of checks, cheapest first, instead of a story.
Weekly [metric] changed from [A] to [B] between [period 1] and [period 2]. I do not know the cause. Generate hypotheses in these groups: an instrumentation or data pipeline change, a change in user mix or acquisition channel, a product or pricing change, an external or seasonal factor, and a real change in user behaviour. For each hypothesis give: why it would produce this pattern, the fastest check (the cut of data, the log or the person to ask), and what result would rule it out. Order the checks so the cheapest and most likely come first. Do not state a cause as fact; where you need information I have not given, list it as a question. Context: [PASTE RECENT RELEASES, CAMPAIGNS, DATA CHANGES, BREAKDOWNS IF AVAILABLE]
Paste in: the release log, campaigns and tracking changes for both periods, plus any breakdowns you already have.
How to check the output: run the first three checks in order before you accept any explanation, and keep a note of what you ruled out. Start with instrumentation and release notes: if the data changed, the behaviour story does not matter yet.
32. Diagnose a funnel from aggregate numbers
Use it to: find where a funnel changed and which breakdowns to run.
Here is a funnel with aggregate counts per step for two periods: [PASTE]. You are a product analyst. Compute the step-to-step conversion for each period and show the arithmetic. Identify the step where conversion changed most. List possible explanations by category: product change, traffic mix, measurement and external factors. For each, say which breakdown I should run to test it (for example by device, channel, country, or new versus returning users). Do not guess at causes beyond the numbers. If the numbers are inconsistent (for example a later step larger than an earlier one), say so and stop to ask me. Context: [PASTE STEP DEFINITIONS AND ANY CHANGES SHIPPED IN THE PERIOD]
Paste in: aggregate counts for each step and period, with the definition of each step.
How to check the output: recompute at least two conversion rates in a spreadsheet. Confirm the step definitions match how events are actually logged. Run the suggested breakdowns on your own data.
33. Write a metric definition everyone can agree on
Use it to: end the argument about what a metric means, with a worked example.
Write a one-page definition of the metric [metric name] for our team's metrics dictionary. Include: a plain-language definition; the formula; which events and tables count and which are excluded (test accounts, bots, refunds, internal users, duplicates); the time window and time zone; the unit (user, account or session); known limitations; and the owner. Add a worked example with five made-up users and their events, showing step by step how the metric is calculated. Finally list the three questions on which two reasonable people could define the metric differently, with the choice you recommend for each and the trade-off. Mark anything I must confirm with [CONFIRM]. What I know about how it is calculated today: [PASTE]
Paste in: how the metric is calculated today and the questions people have asked about it.
How to check the output: compare the worked example with how your dashboard calculates the same five cases. Any difference is a bug in the definition or in the dashboard. Get the metric's owner to sign off.
Group 5: Stakeholder and executive communication (prompts 34 to 41)
Writing for executives is writing under constraint: little time, little patience for hedging and a high cost if you are wrong. Models can compress text and adjust tone quickly, but they cannot know what is true about your company, so give them the facts and ask them to mark whatever they inferred.
34. Turn a long document into a one-page pre-read
Use it to: compress a long document into a page a busy reader can act on.
You are a chief of staff preparing a pre-read for [audience, for example the leadership team] that will be read in five minutes before a meeting about [topic]. Turn the document below into one page of no more than 350 words with these headings: the decision we need (one sentence), our recommendation, the three reasons, what could go wrong, what we need from the reader, and what happens if we do nothing. Use only claims that are in the document and keep every number exactly as written. After the page, list any statement in the document that is not supported by its own evidence, and any number you were unable to include. [PASTE DOCUMENT]
Paste in: the full document, with confidential figures removed or replaced if your policy requires it.
How to check the output: compare every number in the pre-read with the source. Hand the page to a colleague who has not seen the document and ask them to state the decision back to you.
35. Prepare for the ten hardest questions
Use it to: find where your pre-read is weak before the meeting does.
You are [role, for example the head of finance] at a company like ours, reading the pre-read below. Write the ten hardest questions you would ask in the meeting, ordered from most to least likely to derail the discussion. For each, give the best honest answer using only the facts in the pre-read and my notes, and rate how well the pre-read supports that answer (strong, partial or weak). Mark the questions where the honest answer is "we don't know yet" and suggest what we could do before the meeting to be able to answer. Do not write confident answers where the material is thin. Pre-read: [PASTE] My notes and background facts: [PASTE]
Paste in: the pre-read and your own notes and facts.
How to check the output: rehearse the weak answers with a colleague. For every answer the model gave confidently, check the fact against your notes. Never repeat an answer in the room that you have not verified.
36. Rewrite a technical update for a different audience
Use it to: translate an update without changing what it promises.
Rewrite the update below for [audience, for example the sales leadership team], who care about [what they care about] and have [two minutes] to read it. Lead with the effect on them. Remove jargon or define it in a few words. Keep every number, date and name exactly as in the original. After the rewrite, list everything you changed that goes beyond wording: dropped details, merged points and shifts in tone. Also list any sentence in your version that a reader could take as promising more than the original does. [PASTE ORIGINAL UPDATE]
Paste in: the original update and a line on what the new audience cares about.
How to check the output: compare the two versions number by number. Read the "promising more than the original" list carefully: an update that promises more than the original is the failure to look for.
37. Respond to a stakeholder who wants something added
Use it to: draft a reply that states the trade-off instead of a yes or a flat no.
A stakeholder, [role], has asked for [request] to be added to [project], which is due [date]. Their reason: [reason]. Our constraints: [capacity, dependencies, risks]. Draft two replies of no more than 150 words: one direct and one more diplomatic. Each should acknowledge the underlying need, state the trade-off in plain terms (what we would drop or delay), and offer two options with a recommended one. After each draft, say how it could be misread and give one question I should ask them before I reply. Do not promise dates or scope that I have not stated. Background: [PASTE]
Paste in: the request, the project's status and constraints, and what you know about the stakeholder's real need.
How to check the output: read it as the recipient. Remove any sentence that sounds like a promise you have not agreed with engineering. Choose the version that matches your relationship, then edit it until it sounds like you.
38. Draft a "we are going to be late" update
Use it to: deliver bad news plainly, with a date range and a clear ask.
Draft a status update to [audience] saying that [project] will miss its date of [date]. Facts: new estimated date or range [new date], cause [cause], what is affected [impact], what we are doing about it [plan], what I need from them [ask]. Structure: lead with the change and the new date; then the cause in two sentences; then the impact, the plan and the support needed. Constraints: no more than 180 words, no blame and no spin. State how confident we are in the new date and what would move it again. After the draft, mark any sentence that sounds defensive or vague and rewrite it. Facts and context: [PASTE]
Paste in: the facts above, in your own words, and your engineering lead's estimate.
How to check the output: check every date and number against your plan. Make sure the confidence statement is something you believe and not something the model added to sound reassuring. Show the draft to your engineering lead before it goes out.
39. Map the room before a high-stakes meeting
Use it to: prepare for each attendee's likely position and the one disagreement to defuse early.
I am meeting [attendees, by role] about [topic]. Here is what I know about each: [PASTE YOUR NOTES: their goals, past positions, concerns]. For each person, give: their likely position, what they need to hear to support it, what they will worry about, and one question I could ask that helps them engage. Treat every item as a hypothesis built only from my notes. Then identify the one disagreement most likely to surface and suggest how I could pre-wire it with the right person before the meeting. List the two things I know least about and how to learn them in advance.
Paste in: your notes on each person's goals and concerns. Use roles instead of names, and leave out personal or sensitive remarks about colleagues.
How to check the output: correct each hypothesis with what you know. The output is a list of questions to prepare for, not a prediction of how people will behave.
40. Draft a one-page strategy narrative
Use it to: test whether your strategy reads as a set of choices or a wish list.
Using the material below, draft a one-page product strategy of no more than 400 words for [audience], in this order: where we are now (a diagnosis, with the evidence), the choice we are making and why, what we are deliberately not doing, what must be true for this to work, the first three actions, and how we will know it is working within [90 days]. Use only the facts I give. Where the material does not support a section, write [NOT SUPPORTED] and say what we would need. After the draft, write the strongest argument against this strategy in 100 words and say which assumption it attacks. Material: [PASTE]
Paste in: your diagnosis, evidence, options considered and constraints.
How to check the output: remove every adjective and see whether the strategy still reads as a choice. A strategy with no "not doing" list is a wish list. Check each "must be true" item against evidence.
41. Turn meeting notes into decisions and actions
Use it to: separate what was decided from what was only discussed.
From the notes below, extract: decisions made (and who made them), actions (owner, action, due date), open questions, and disagreements left unresolved. Write "not stated" for any owner or date the notes do not give; do not guess. Keep the original wording of each decision, in quotes. Then list anything in the notes that could be read two ways, with the clarifying question I should send to attendees. Draft a foll