These 11 prompts cover the real product management job: turning raw discovery into validated problems, writing PRDs and specs engineers can build from, prioritizing with a defensible framework, and communicating roadmap decisions up and across. Each one is built around the artifacts a B2B PM actually ships. Fill in the placeholders, paste into Claude, and edit the output instead of starting from a blank page.
You are helping a B2B product manager synthesize customer discovery. Below are notes from [NUMBER] customer interviews about [PROBLEM AREA / FEATURE]. Interview notes: [PASTE RAW NOTES OR TRANSCRIPTS] Do the following: 1. Extract every distinct problem, pain point, or unmet need mentioned. For each, quote the actual customer language verbatim and note which interview it came from. 2. Cluster these into 4-7 themes. Name each theme in the customer's words, not internal jargon. 3. For each theme, tell me: how many of the [NUMBER] customers raised it, the severity they expressed (workaround, painful, blocker), and whether it ties to a job-to-be-done or just a feature request. 4. Flag anything that is a stated solution rather than a real problem, and reframe it as the underlying need. 5. Call out the 1-2 themes with the strongest signal that I should validate further, and the questions I still cannot answer from this data. Do not invent quotes or fill gaps. If the data is thin on something, say so.
Act as a skeptical product leader reviewing an opportunity I want to pursue. Your job is to find the weak points, not to cheerlead. Opportunity: [DESCRIBE THE FEATURE OR INITIATIVE] Who it is for: [TARGET SEGMENT / PERSONA] Problem I believe it solves: [PROBLEM STATEMENT] Evidence I have so far: [INTERVIEWS, TICKETS, USAGE DATA, SALES REQUESTS, ETC.] What success would look like: [METRIC AND TARGET] Walk through: 1. Is this a real, frequent, expensive problem, or an edge case dressed up as a trend? Challenge my evidence. 2. What would have to be true for this to move [SUCCESS METRIC]? List the assumptions, and rate each as validated, weakly supported, or untested. 3. Who does this NOT serve, and could it create new problems for them? 4. What is the cheapest experiment to de-risk the biggest assumption before we write a line of code? 5. Give me a clear recommendation: pursue now, validate first, or drop. Defend it in 3 sentences. Be direct. I would rather be wrong now than after a quarter of engineering.
Write a first-draft PRD for the initiative below. Use my inputs; where I leave something out, write [TODO: ...] rather than guessing. Working title: [FEATURE NAME] Problem and evidence: [WHAT PROBLEM, FOR WHOM, AND WHY WE BELIEVE IT] Target users / segments: [PERSONAS OR ACCOUNTS] Business goal and success metric: [GOAL + METRIC + TARGET] Known constraints: [TECH, LEGAL, TIMELINE, RESOURCING] What I already know we will NOT do: [OUT OF SCOPE] Structure the PRD as: 1. Summary (3 sentences a busy exec can absorb) 2. Problem and the evidence behind it 3. Goals and non-goals 4. Target users and the primary job-to-be-done 5. Proposed solution at a high level (no UI prescriptions unless I gave them) 6. Functional requirements as a numbered list, each testable 7. Success metrics and the counter-metric we will watch for regressions 8. Open questions and risks 9. Dependencies and rough sequencing Keep it tight. Engineers and designers should be able to ask sharper questions after reading it, not need a translation.
Break the feature below into user stories ready for our backlog. Feature: [FEATURE NAME AND SHORT DESCRIPTION] Primary persona(s): [WHO] Key requirements from the PRD: [PASTE OR SUMMARIZE] Known edge cases or states to handle: [LIST IF ANY] For each story: 1. Write it in the form: As a [persona], I want [capability], so that [outcome]. 2. Add acceptance criteria in Given / When / Then format. Be specific about states, inputs, and expected results. 3. List explicit edge cases and error states to handle (empty, max, permissions, offline, partial failure as relevant). 4. Note dependencies on other stories or systems. 5. Suggest a relative size (S / M / L) with one line of reasoning. Sequence the stories so we could ship a thin end-to-end slice first, then layer on the rest. Flag any requirement that is ambiguous enough that I should clarify it before handing this to engineering.
Review the spec below as a senior engineer and a QA lead would, looking for what will break or get questioned. Spec: [PASTE SPEC OR PRD SECTION] Produce: 1. Ambiguities: anything that could be interpreted two ways by an engineer. Quote the line and state both interpretations. 2. Missing states and edge cases: empty, loading, error, permissions, concurrency, rate limits, large inputs, internationalization, accessibility, whatever applies. 3. Unstated assumptions about data, systems, or user behavior. 4. Failure and rollback questions: what happens when a dependency is down or a write half-completes? 5. Metrics and instrumentation gaps: what would we be unable to measure post-launch as written? 6. The 3 questions most likely to derail spec review, with a suggested answer or a note that I need to decide. List findings by severity (blocker / should-fix / nice-to-have). Do not rewrite the spec; just expose the gaps.
Help me prioritize the backlog items below using RICE (Reach, Impact, Confidence, Effort). Treat your scores as a starting point I will adjust, and show your reasoning. Context: [PRODUCT, TARGET SEGMENT, CURRENT QUARTER GOAL] Scale notes: Reach = [HOW WE COUNT, e.g. accounts or users per quarter]. Effort = [PERSON-WEEKS OR T-SHIRT]. Backlog items (each with whatever evidence I have): [ITEM 1: description + any data] [ITEM 2: ...] [ITEM 3: ...] For each item: 1. Estimate Reach, Impact (0.25 to 3), Confidence (%), and Effort, and compute the RICE score. 2. State the single biggest assumption behind your Impact and Confidence scores. 3. Note where my evidence is too thin to score honestly, and what data would tighten it. Then output a ranked table, and call out: which 2-3 items clearly belong this quarter, which are tempting but under-evidenced, and any item whose score is misleading because of strategic value RICE does not capture.
I am deciding how to deliver [CAPABILITY] for [PRODUCT / SEGMENT]. Help me reason through build vs buy vs partner. What we need it to do: [CORE REQUIREMENTS] Strategic importance: [IS THIS A DIFFERENTIATOR OR TABLE STAKES?] Constraints: [TIMELINE, ENGINEERING CAPACITY, BUDGET, COMPLIANCE] Options I am aware of: [ANY VENDORS OR APPROACHES] For each path (build, buy, partner): 1. Time to first value and time to production quality. 2. Total cost of ownership over 2-3 years, including maintenance and the hidden costs PMs usually miss. 3. Control, flexibility, and switching cost. 4. Risk to roadmap, security, and the customer experience. 5. What it signals about where we invest engineering. Close with a recommendation tied to the strategic importance I gave you, the top 2 risks of that choice, and the one fact I should confirm before committing.
Help me write a clear, respectful response explaining a prioritization decision. Who I am writing to: [ROLE / RELATIONSHIP, e.g. AE, CSM, exec, customer] What they asked for: [THE REQUEST] Why it is not prioritized right now: [REAL REASON: capacity, evidence, strategy, dependency] What we ARE doing instead and why: [CURRENT PRIORITIES] What I can honestly offer: [WORKAROUND, REVISIT DATE, INPUT INTO NEXT PLANNING, OR NOTHING YET] Write a reply that: 1. Acknowledges the request and the underlying need specifically, so they know I actually heard it. 2. Explains the decision in terms of impact and tradeoffs, not internal politics or vague capacity hand-waving. 3. Does not over-promise or invent a date I have not committed to. 4. Leaves them with a concrete next step. Tone: direct, warm, no corporate filler. Do not use em dashes or en dashes. Keep it under 200 words and give me a one-line subject if it is an email.
Draft a quarterly roadmap update for a leadership audience. Product / area: [NAME] Quarter and theme: [QUARTER + STRATEGIC THEME] Shipped this quarter: [ITEMS + ANY OUTCOMES OR METRICS] In flight / slipped: [ITEMS + WHY] Next quarter focus: [PLANNED BETS] Key metrics: [BEFORE / AFTER OR CURRENT VS TARGET] Decisions or tradeoffs I want them to notice: [ANYTHING THAT NEEDS BUY-IN OR AWARENESS] Write it framed around outcomes and the business goal, not a feature checklist. Structure: 1. Headline: the one thing leadership should remember (2 sentences). 2. What moved the needle and the metric behind it. 3. What slipped, the honest reason, and the new plan. No spin. 4. Next quarter bets and why these over the alternatives. 5. Where I need a decision or air cover. Keep it skimmable, lead with results, and cut anything an exec would not act on. Do not use em dashes or en dashes.
Create a launch readiness plan for the feature below for a B2B product. Feature: [NAME + ONE-LINE DESCRIPTION] Target users / segments: [WHO GETS IT] Launch type: [SILENT / BETA / GA / PHASED] Target date: [DATE] Key value props: [WHY USERS SHOULD CARE] Risks or sensitivities: [PRICING, MIGRATION, DEPRECATION, COMPLIANCE] Produce two things: 1. A cross-functional readiness checklist grouped by function (Product, Engineering, Design, Sales, CS, Marketing, Support, Legal/Security as relevant). Each item should be a concrete, checkable task with an owner placeholder. 2. A short internal GTM brief: positioning in one sentence, the 3 key messages, what Sales and CS each need to know, the rollout sequence, and the rollback/kill criteria if it goes wrong. Flag the 3 items most likely to be forgotten and the single biggest launch risk.
Help me read the post-launch results for a feature and decide what to do next. Feature and goal: [WHAT IT WAS MEANT TO ACHIEVE + TARGET METRIC] Launched: [DATE / HOW LONG LIVE] Data I have: - Adoption: [NUMBERS, e.g. % of eligible accounts activated] - Engagement / retention: [NUMBERS] - Target metric movement: [BEFORE VS AFTER] - Counter-metrics: [ANY NEGATIVE SIGNALS, SUPPORT TICKETS, CHURN] - Qualitative: [USER QUOTES, SALES/CS FEEDBACK] Do this: 1. Tell me whether we hit the goal, partially hit it, or missed, and how confident the data lets you be (watch for short windows, novelty effects, confounders). 2. Separate adoption problems from value problems: are people not trying it, or trying it and not getting value? 3. Surface the most important signal I might be under-weighting. 4. Recommend a next move: double down, iterate (and on what specifically), or sunset. Give the reasoning. 5. List what I should instrument or ask to close the biggest remaining unknown. Be honest if the data does not support a confident call yet.
Drop these into a Claude Project loaded with your team's context: your processes, your templates, your past work, and the standards you hold. With those inputs, the prompts above produce outputs far better than running them in a blank Claude chat.
See Claude for Product Management for the full picture, or have Treetop build the Product Management Project for your team.