Claude Prompts for Product Managers

You are a senior product manager building a quarterly roadmap for leadership review. <context> You have a backlog of candidate initiatives and need a Now, Next, Later roadmap that ties each item to a business goal. </context> <inputs> - Candidate initiatives with rough size (S/M/L): [INITIATIVE_LIST] - Company goal for the quarter: [QUARTER_GOAL] - Team capacity in engineer-weeks: [CAPACITY] </inputs> <task> Sort the initiatives into Now, Next, and Later based on size, goal alignment, and stated capacity. For each Now item, state which goal it serves and the size. Flag if Now items exceed stated capacity. </task> <constraints> - Now must not exceed the stated capacity in engineer-weeks; if it does, say so explicitly and recommend what to cut. - Every Now and Next item must state which company goal it serves. - Later items still need one line explaining why they were not prioritized. </constraints> <format> Return three tables (Now, Next, Later), each with columns: Initiative, Size, Goal Served, Notes. </format>

You are a product manager running quarterly prioritization for a growth team. <context> You need to compare initiatives objectively using RICE (Reach, Impact, Confidence, Effort) instead of whoever argues loudest in the room. </context> <inputs> - Initiatives with a one-line description each: [INITIATIVE_LIST] - Reach data available (e.g. monthly active users touched): [REACH_DATA] - Team effort estimates in person-weeks: [EFFORT_ESTIMATES] </inputs> <task> Score each initiative on Reach, Impact (1-3 scale), Confidence (as a percentage), and Effort (person-weeks), calculate the RICE score, and rank all initiatives from highest to lowest score. </task> <constraints> - Show the RICE formula result per row: (Reach x Impact x Confidence) / Effort. - State the assumption behind each Confidence percentage in one short phrase. - Do not assign a Confidence above 80% unless real data supports it in the inputs. </constraints> <format> Return a table: Initiative, Reach, Impact, Confidence, Effort, RICE Score, Confidence Assumption. Sort by RICE Score descending. </format>

You are a product manager explaining a roadmap tradeoff to a VP who wants a bigger scope on a tighter deadline. <context> Leadership wants to add scope without moving the deadline, and you need a memo that lays out the real tradeoff options instead of just agreeing. </context> <inputs> - Original scope and deadline: [ORIGINAL_SCOPE] - Requested addition: [REQUESTED_ADDITION] - Team capacity constraint: [CAPACITY_CONSTRAINT] </inputs> <task> Write a one-page memo presenting 3 concrete options: (1) add the scope and push the deadline by a stated amount, (2) keep the deadline and cut something specific to make room, (3) keep both by reducing quality bar in a stated way, each with a clear cost. </task> <constraints> - Every option must name what specifically gets cut, delayed, or reduced, not a vague "some tradeoffs". - End with a clear recommendation and the reasoning in 2 sentences. - Keep the memo under 350 words. </constraints> <format> Return a markdown memo with a short opening paragraph, an Options table (Option, What It Costs, What It Keeps), and a Recommendation section. </format>

You are a product manager cleaning up a backlog that has grown to hundreds of untouched tickets. <context> The backlog has accumulated old requests, duplicates, and stale ideas that need to be triaged before the next planning cycle. </context> <inputs> - Backlog items (title and one-line description each): [BACKLOG_ITEMS] - Current quarter's top 2 priorities: [TOP_PRIORITIES] </inputs> <task> Triage the backlog into 4 buckets: Do This Quarter, Reconsider Next Quarter, Merge or Duplicate, Close as Won't Do. For merges, name which items are duplicates of each other. For closes, give one reason each. </task> <constraints> - Every item must land in exactly one bucket. - Do This Quarter items must directly connect to one of the two stated top priorities. - Close as Won't Do items need a one-line reason someone could read without feeling dismissed. </constraints> <format> Return four tables, one per bucket, with columns: Item, Reason/Connection. </format>

You are a product manager evaluating whether to build a capability in-house, buy a vendor solution, or partner. <context> Leadership asked for a clear recommendation on a capability decision with the reasoning laid out, not just a gut call. </context> <inputs> - Capability needed: [CAPABILITY] - In-house build estimate: [BUILD_ESTIMATE, e.g. 3 engineers for 2 quarters] - Vendor options considered: [VENDOR_OPTIONS] - Strategic importance: [STRATEGIC_NOTE, e.g. core differentiator vs commodity] </inputs> <task> Build a decision matrix comparing Build, Buy, and Partner on cost, time to launch, control, and strategic fit. Recommend one option with the reasoning tied directly to the strategic importance stated in the inputs. </task> <constraints> - Score each option on a 1-5 scale for each criterion with a one-line justification per score. - The recommendation must explicitly reference whether this capability is a differentiator or a commodity. - Flag any vendor option with unclear long-term pricing as a risk. </constraints> <format> Return a table: Criterion, Build, Buy, Partner (scores and justifications), followed by a Recommendation paragraph. </format>

You are a product manager preparing an epic for sprint planning. <context> An epic is too large to estimate or build as one unit and needs to be broken into independently shippable user stories. </context> <inputs> - Epic description: [EPIC_DESCRIPTION] - Target user roles involved: [USER_ROLES] - Sprint length: [SPRINT_LENGTH, e.g. 2 weeks] </inputs> <task> Break the epic into 6 to 10 user stories, each independently shippable and testable, in the format "As a [role], I want [capability], so that [benefit]", ordered by build sequence (dependencies first). </task> <constraints> - Each story must be small enough to plausibly fit within one sprint on its own. - Mark dependencies explicitly (e.g. "depends on story 3"). - Do not create a story that can't be demoed or tested independently. </constraints> <format> Return a numbered list of stories, each with the story text, a one-line note on dependencies, and a rough size (S/M/L). </format>

You are a product manager writing acceptance criteria that QA and engineering can test against directly. <context> A user story needs clear, testable acceptance criteria before it can be pulled into a sprint. </context> <inputs> - User story: [USER_STORY] - Known constraints or business rules: [BUSINESS_RULES] - Platforms affected: [PLATFORMS] </inputs> <task> Write acceptance criteria in Given/When/Then format covering the happy path, at least 3 negative or edge cases, and any platform-specific behavior. </task> <constraints> - Every criterion must be testable as pass/fail by someone who didn't write the story. - Include at least one criterion for permission or access control if the story touches user data. - Do not restate the story, only write the criteria. </constraints> <format> Return a numbered list of Given/When/Then statements, grouped under Happy Path and Edge Cases headers. </format>

You are a product manager triaging a queue of newly reported bugs before the weekly bug review. <context> A batch of bug reports needs severity ratings and a recommended order to fix them in, based on user impact rather than who reported them. </context> <inputs> - Bug reports (title and description each): [BUG_LIST] - Affected user segment size for each, if known: [SEGMENT_SIZES] </inputs> <task> Rate each bug's severity (Critical, High, Medium, Low) based on user impact and workaround availability, and produce a fix order with justification. </task> <constraints> - Critical is reserved for data loss, security, or complete feature breakage with no workaround. - State whether a workaround exists for each bug. - Fix order must follow severity first, then affected segment size. </constraints> <format> Return a table: Bug, Severity, Workaround Exists?, Affected Segment, Fix Order. </format>

You are a product manager preparing tickets for an upcoming sprint planning session. <context> A set of prioritized backlog items needs to become concrete tickets with enough detail that engineers can estimate them without a follow-up question. </context> <inputs> - Prioritized backlog items for this sprint: [BACKLOG_ITEMS] - Team velocity (story points per sprint): [VELOCITY] - Any carryover work from last sprint: [CARRYOVER] </inputs> <task> Convert each backlog item into a ticket with a title, description, acceptance criteria, and a story point estimate, then check the total against stated velocity including carryover. </task> <constraints> - Flag if the total points exceed stated velocity once carryover is included, and suggest which item to defer. - Every ticket needs at least 2 acceptance criteria. - Story point estimates must follow Fibonacci-like values (1, 2, 3, 5, 8). </constraints> <format> Return a numbered list of tickets (Title, Description, Acceptance Criteria, Points), followed by a Capacity Check summary line. </format>

You are a product manager standardizing what "done" means across a cross-functional team. <context> The team ships inconsistent quality because "done" means different things to different people, and you need one checklist everyone agrees to. </context> <inputs> - Team type: [TEAM_TYPE, e.g. mobile feature team] - Compliance or QA requirements: [COMPLIANCE_NOTES] - Tools used for testing and deployment: [TOOLS] </inputs> <task> Write a Definition of Done checklist covering code review, testing (unit, QA, accessibility if relevant), documentation, analytics instrumentation, and release readiness. </task> <constraints> - Every checklist item must be a yes/no check, not a vague standard. - Include an analytics or instrumentation check so launches are measurable. - Tailor items to the tools listed in inputs rather than generic tool names. </constraints> <format> Return a markdown checklist grouped under headers: Code, Testing, Documentation, Analytics, Release. </format>

You are a product manager who sends a weekly update that busy stakeholders actually read. <context> Stakeholders need a short, scannable update on progress, risks, and what changed since last week. </context> <inputs> - Progress this week: [PROGRESS_NOTES] - Metrics snapshot: [METRICS] - Risks or blockers: [RISKS] - Decisions needed from stakeholders: [DECISIONS_NEEDED] </inputs> <task> Write a weekly update email with a 2-sentence TL;DR at the top, a progress section, a metrics snapshot, risks with owners, and a clearly flagged section for decisions needed. </task> <constraints> - The TL;DR must be readable in under 10 seconds and state the single most important fact. - Every risk needs a named owner, not "the team". - Keep the full email under 300 words excluding the metrics table. </constraints> <format> Return an email with a subject line, TL;DR, and sections: Progress, Metrics, Risks (table: Risk, Owner, Status), Decisions Needed. </format>

You are a product manager reporting project status to an executive audience using Red/Amber/Green status. <context> Executives need a one-glance status view across multiple workstreams without reading a full project plan. </context> <inputs> - Workstreams and their current state: [WORKSTREAM_LIST] - Overall deadline: [DEADLINE] - Biggest current risk: [BIGGEST_RISK] </inputs> <task> Assign each workstream a RAG status with a one-line justification, calculate an overall project RAG, and write a 3-sentence executive summary focused on the biggest risk and what's being done about it. </task> <constraints> - Red requires the deadline to be at risk or already missed; Amber requires a specific named risk; justify every rating in one line. - Overall RAG cannot be Green if any workstream is Red. - Executive summary must name a mitigation action, not just describe the risk. </constraints> <format> Return a table: Workstream, RAG Status, Justification, followed by Overall RAG and an Executive Summary paragraph. </format>

You are a product manager kicking off a new project with design, engineering, and marketing. <context> A kickoff meeting needs a one-page brief so every function walks in aligned on scope, timeline, and their specific role. </context> <inputs> - Project name and goal: [PROJECT_GOAL] - Functions involved: [FUNCTIONS, e.g. design, backend, marketing] - Target launch window: [LAUNCH_WINDOW] - Known dependencies on other teams: [DEPENDENCIES] </inputs> <task> Write a kickoff brief: project goal, scope summary, a RACI-style breakdown of what each function owns, key milestones with dates, and known dependencies with the team they depend on. </task> <constraints> - Every listed function must have at least one explicit responsibility, not just be named. - Milestones must total no more than 5 and map to the stated launch window. - Call out any dependency that isn't yet confirmed with the owning team. </constraints> <format> Return a markdown brief with sections: Goal, Scope, Ownership (table: Function, Owns), Milestones (table: Milestone, Date), Dependencies. </format>

You are a product manager writing release notes customers will actually read. <context> A batch of shipped changes needs to become release notes that highlight value, not just list technical changes. </context> <inputs> - Shipped changes (internal descriptions): [CHANGES_LIST] - Audience: [AUDIENCE, e.g. self-serve small business users] - Tone guide: [TONE_NOTE, e.g. plain, no jargon] </inputs> <task> Rewrite each internal change into a customer-facing note that leads with the benefit, group notes under New, Improved, and Fixed, and write a 1-sentence summary at the top. </task> <constraints> - Each note must lead with what the user can now do, not the internal implementation. - No internal jargon, ticket numbers, or team names in customer-facing text. - Fixed items should be phrased as the problem that no longer happens. </constraints> <format> Return a markdown release notes page with a summary line and sections: New, Improved, Fixed. </format>

You are a product manager who needs to escalate a slipping deadline before it becomes a surprise to leadership. <context> A project is going to miss its deadline and leadership needs to hear it early, with options, not just an apology. </context> <inputs> - Original deadline: [ORIGINAL_DEADLINE] - New realistic estimate: [NEW_ESTIMATE] - Root cause of the delay: [ROOT_CAUSE] - Options considered to recover time: [RECOVERY_OPTIONS] </inputs> <task> Write a short escalation memo: what's slipping and by how much, the root cause in plain language, 2 to 3 recovery options with tradeoffs, and a recommended path forward. </task> <constraints> - State the new date as a specific date, not "a few more weeks". - Root cause must be factual and not assign blame to a named individual. - Recommendation must pick one option and say why, not present all options as equal. </constraints> <format> Return a markdown memo: Summary (2 sentences), Root Cause, Recovery Options (table: Option, Tradeoff), Recommendation. </format>

You are a product manager coordinating a feature launch across product, marketing, and support. <context> A launch date is set and every function needs a clear list of what must be done before it, not a scramble the week of. </context> <inputs> - Feature and launch date: [FEATURE_AND_DATE] - Functions involved: [FUNCTIONS] - Launch tier: [TIER, e.g. minor update vs flagship launch] </inputs> <task> Build a launch checklist grouped by function (Product, Marketing, Support, Sales if relevant) with tasks and a due date relative to launch day (e.g. T-minus 5 days). </task> <constraints> - Every task needs an owner function and a T-minus deadline. - Support tasks must include an internal FAQ or macro update before launch day. - Scale the number of tasks to the launch tier: a minor update needs fewer than a flagship launch. </constraints> <format> Return a table: Task, Owner, Due (T-minus), grouped under function headers. </format>

You are a product manager writing the internal or external announcement for a feature launch. <context> A launch needs an announcement post that explains why the feature matters, not just what it does. </context> <inputs> - Feature name and what it does: [FEATURE_DESCRIPTION] - Audience: [AUDIENCE, e.g. existing customers, internal company] - Problem it solves: [PROBLEM_SOLVED] - Availability: [AVAILABILITY, e.g. all plans, beta only] </inputs> <task> Write an announcement post: a headline, an opening that states the problem before the solution, a description of how it works, availability details, and a clear call to action. </task> <constraints> - Opening paragraph must state the problem in the user's words before naming the feature. - Availability section must be unambiguous about who has access today. - Keep total length under 250 words. </constraints> <format> Return the post as markdown with a headline and body, plus a one-line call to action at the end. </format>

You are a product manager running a limited beta before a general release. <context> A beta needs a structured plan for who's in it, what you're testing for, and how feedback gets collected and acted on. </context> <inputs> - Feature being tested: [FEATURE_NAME] - Beta group size and profile: [BETA_GROUP] - Beta duration: [DURATION] - Key questions you need answered: [KEY_QUESTIONS] </inputs> <task> Write a beta test plan: goals, entry criteria for participants, a weekly check-in cadence, and a feedback form with 6 to 8 questions mixing rating scales and open text, mapped to the key questions provided. </task> <constraints> - Each feedback form question must map to one of the stated key questions. - Include at least 2 quantitative (rating scale) questions so results can be aggregated. - Exit criteria for graduating out of beta must be specific and measurable. </constraints> <format> Return a markdown plan (Goals, Entry Criteria, Cadence, Exit Criteria) followed by the feedback form as a numbered list of questions with response type noted. </format>

You are a product manager running a retrospective two weeks after a feature launch. <context> The team needs an honest look at what happened after launch, comparing actual results to the original goal, not just a vibes discussion. </context> <inputs> - Original success metric and target: [ORIGINAL_TARGET] - Actual result so far: [ACTUAL_RESULT] - Notable issues during launch: [LAUNCH_ISSUES] </inputs> <task> Write a retrospective doc: goal vs actual comparison, root cause analysis if the target was missed, what went well, what to change for the next launch, and 3 concrete action items with owners. </task> <constraints> - State the gap between target and actual as a specific number or percentage, not "close" or "about right". - If the target was missed, root cause analysis must go at least one level past the surface symptom. - Every action item needs an owner and is phrased as a specific change, not "communicate better". </constraints> <format> Return a markdown doc: Goal vs Actual, What Went Well, What To Change, Action Items (table: Action, Owner). </format>

You are a product manager arming the sales team to talk about a new feature in customer calls. <context> Sales needs a one-pager that translates a feature into value language and gives them answers to the objections they'll actually hear. </context> <inputs> - Feature and what it does: [FEATURE_DESCRIPTION] - Target customer segment: [SEGMENT] - Competitive angle, if any: [COMPETITIVE_NOTE] - Likely objections: [OBJECTIONS] </inputs> <task> Write a one-pager: a 2-sentence pitch in customer language, 3 key benefits with a proof point each, a competitive comparison line if relevant, and objection handling for each listed objection. </task> <constraints> - Benefits must be phrased as outcomes for the customer, not feature descriptions. - Each objection needs a direct, honest response, not a deflection. - Keep the whole doc to one page, under 350 words. </constraints> <format> Return a markdown one-pager: Pitch, Key Benefits (table: Benefit, Proof Point), Competitive Note, Objection Handling (table: Objection, Response). </format>

You are a product manager defining what a team's core dashboard should track. <context> A team needs a dashboard spec that ties day-to-day metrics up to one North Star metric, so engineers building it know what to instrument. </context> <inputs> - Proposed North Star metric: [NORTH_STAR_METRIC] - Product area: [PRODUCT_AREA] - Existing metrics already tracked: [EXISTING_METRICS] </inputs> <task> Define the North Star metric precisely (exact calculation), identify 4 to 6 supporting input metrics that drive it, and specify what each metric needs (data source, update frequency, and owner). </task> <constraints> - The North Star metric must have an unambiguous formula, not a vague description. - Each input metric must state how it causally connects to the North Star metric. - Flag any metric that isn't currently tracked in the existing metrics list as new instrumentation work. </constraints> <format> Return a markdown doc: North Star Definition (with formula), Input Metrics (table: Metric, Formula, Connection to North Star, Data Source, New Instrumentation?). </format>

You are a product manager analyzing a conversion funnel to find where users drop off. <context> A multi-step funnel has a known overall conversion rate and step-by-step numbers, and you need to find the biggest leak and explain it. </context> <inputs> - Funnel steps with counts at each: [FUNNEL_DATA, e.g. Visited 10000, Signed up 2200, Activated 800, Paid 150] - Time period: [TIME_PERIOD] - Any known context on the biggest drop: [CONTEXT_NOTE] </inputs> <task> Calculate the step-to-step conversion rate for each stage, identify the single biggest percentage-point drop, and propose 3 hypotheses for why that drop is happening plus one way to test each. </task> <constraints> - Show the conversion rate calculation for every step, not just the final summary. - Hypotheses must be specific to the step where the drop occurs, not generic "improve onboarding" advice. - Each hypothesis needs a concrete, low-cost way to test it (e.g. a specific A/B test or user interview question). </constraints> <format> Return a table of step conversions, then a Biggest Drop section with 3 hypotheses (table: Hypothesis, How to Test). </format>

You are a product manager writing up the results of an A/B test for the team. <context> An experiment has concluded and the team needs a clear readout on the result and what to do next, including if the result is inconclusive. </context> <inputs> - Test description and hypothesis: [TEST_HYPOTHESIS] - Control result: [CONTROL_RESULT] - Variant result: [VARIANT_RESULT] - Sample size and statistical significance, if known: [SIGNIFICANCE_DATA] </inputs> <task> Write a readout memo: the hypothesis, the results side by side, whether the result is statistically significant based on the data given, and a clear recommendation (ship, iterate, or kill). </task> <constraints> - If significance data isn't provided or is borderline, state that explicitly rather than declaring a winner. - Recommendation must be one of ship, iterate, or kill, with the reasoning in 2 sentences. - Note any risk of a false positive if the sample size looks small relative to the effect claimed. </constraints> <format> Return a markdown memo: Hypothesis, Results (table: Control, Variant, Delta), Significance Assessment, Recommendation. </format>

You are a product manager preparing a QBR presentation for senior leadership. <context> A quarterly business review needs a tight narrative arc, not a dump of every metric the team tracks. </context> <inputs> - Key results this quarter: [QUARTER_RESULTS] - Misses or challenges: [CHALLENGES] - Next quarter's top priorities: [NEXT_PRIORITIES] </inputs> <task> Outline a QBR deck slide by slide: title, key message, and supporting data point for each slide, covering summary, wins, misses with root cause, and next quarter's plan. </task> <constraints> - Limit to 8 slides maximum so it stays presentable in 20 minutes. - Every miss must be paired with a root cause and what's being done about it, not left unexplained. - The final slide must connect next quarter's priorities back to this quarter's misses or wins. </constraints> <format> Return a numbered list of slides, each with Slide Title, Key Message, Supporting Data Point. </format>

You are a product manager investigating why customers are churning. <context> Churn has ticked up and you need a structured diagnosis using the data available, rather than a single anecdote from one lost customer. </context> <inputs> - Churn rate this period vs prior period: [CHURN_RATES] - Common reasons cited in cancellation surveys: [CANCELLATION_REASONS] - Segment breakdown of churn, if available: [SEGMENT_BREAKDOWN] </inputs> <task> Analyze the churn data: identify the top 3 cited reasons ranked by frequency, flag which customer segment is churning fastest, and propose one retention experiment per top reason. </task> <constraints> - Rank reasons by frequency using the data given, not by which sounds most fixable. - Each retention experiment must target the specific reason, not be a generic "improve onboarding" fix. - State the churn rate change as a specific percentage point delta. </constraints> <format> Return a markdown report: Churn Rate Change, Top Reasons (table: Reason, Frequency, Fastest-Churning Segment), Retention Experiments (table: Reason, Proposed Experiment). </format>