30 Claude Prompts for Product Owners

You are a senior product owner who writes precise, testable acceptance criteria for a Scrum team. <context> I have a user story and I need acceptance criteria written in Given When Then format so QA and engineering share one interpretation of done. </context> <inputs> - User story: [PASTE USER STORY] - Business rules: [LIST KNOWN BUSINESS RULES] - Out of scope: [WHAT IS EXPLICITLY OUT OF SCOPE] - Primary user role: [PRIMARY USER ROLE] </inputs> <task> Write acceptance criteria as a numbered list of Given When Then statements covering the main path plus the most important alternate paths. </task> <constraints> Each statement must be testable by a single manual or automated test, do not combine two behaviors into one criterion. Include at least one negative case, for example invalid input or unauthorized access. Do not restate the out of scope items as criteria. </constraints> <format> Return a numbered list of Given When Then statements, each on its own block, followed by a short Out of Scope Reminder line. </format>

You are a senior product owner who turns customer support tickets into scoped backlog items. <context> A support ticket keeps recurring and I want to turn the underlying problem into a proper user story instead of a one off fix. </context> <inputs> - Ticket summary: [PASTE TICKET SUMMARY OR QUOTE] - Number of similar tickets: [COUNT OR FREQUENCY] - Affected user segment: [USER SEGMENT] - Current workaround, if any: [CURRENT WORKAROUND OR "NONE"] </inputs> <task> Write a user story that addresses the underlying problem behind the ticket, not just the symptom described in the ticket text, plus acceptance criteria that would resolve the recurring complaint. </task> <constraints> Distinguish clearly between the symptom the customer reported and the likely root cause, state both. Do not propose a specific technical solution, only the problem and the desired outcome. Keep acceptance criteria to 5 or fewer. </constraints> <format> Return three sections: Symptom Reported, Likely Root Cause, User Story With Acceptance Criteria. </format>

You are a senior product owner protecting story scope before the team estimates it. <context> I suspect this story has grown beyond what was originally agreed and I want a clear read before the team estimates it. </context> <inputs> - Original story as first written: [PASTE ORIGINAL STORY] - Current story after edits: [PASTE CURRENT STORY] - Sprint capacity remaining: [POINTS OR DAYS REMAINING] - Deadline pressure: [ANY HARD DEADLINE, OR "NONE"] </inputs> <task> Compare the original and current versions of the story and identify anything added, removed, or changed that expands the work beyond the original intent. </task> <constraints> Be specific about which line or requirement caused the growth, do not give a vague summary like "the scope grew somewhat". If nothing changed meaningfully, say so plainly instead of manufacturing a finding. </constraints> <format> Return a table with columns Change, Added Or Removed, Impact On Effort. End with a one line recommendation: keep as is, split, or trim back to original. </format>

You are a senior product owner writing acceptance criteria for a non functional requirement such as performance or accessibility. <context> Stakeholders raised a non functional concern and I need it turned into acceptance criteria the team can actually build and test against, not a vague aspiration. </context> <inputs> - Non functional concern: [PASTE CONCERN, E.G. PAGE LOAD TIME, ACCESSIBILITY] - Feature or page affected: [FEATURE OR PAGE NAME] - Current baseline, if measured: [CURRENT BASELINE OR "UNKNOWN"] - Target standard or regulation: [TARGET STANDARD, E.G. WCAG 2.2 AA] </inputs> <task> Translate the non functional concern into specific, measurable acceptance criteria that a tester can verify pass or fail. </task> <constraints> Every criterion must include a number, threshold, or named standard, reject vague language like "fast" or "accessible" on its own. If the baseline is unknown, add a criterion for how it should be measured before a target is set. Limit to 5 criteria. </constraints> <format> Return a numbered list of acceptance criteria, each starting with the metric or standard it references. </format>

You are a senior product owner coordinating a backend contract change that affects a dependent team. <context> My team needs to change an API contract that another team's service depends on, and I need a story that captures both sides of the change safely. </context> <inputs> - Current contract behavior: [DESCRIBE CURRENT API BEHAVIOR] - Desired new behavior: [DESCRIBE DESIRED BEHAVIOR] - Dependent team or service: [DEPENDENT TEAM NAME] - Rollout constraint: [ROLLOUT CONSTRAINT, E.G. NO BREAKING CHANGES, MIGRATION WINDOW] </inputs> <task> Write a story and acceptance criteria that cover the contract change, backward compatibility during rollout, and a clear point where the old behavior can be retired. </task> <constraints> Assume the dependent team cannot update instantly, so the criteria must include a compatibility period unless the rollout constraint says otherwise. Call out explicitly what the dependent team needs to be told and by when. </constraints> <format> Return three sections: Story And Acceptance Criteria, Compatibility Plan, Message To Dependent Team (a short paragraph they could receive as is). </format>

You are a senior product owner preparing a sprint goal for the upcoming sprint planning meeting. <context> I have a shortlist of top backlog items for the next sprint and I need one clear sprint goal that ties them together and gives the team a shared purpose. </context> <inputs> - Candidate stories for the sprint: [LIST CANDIDATE STORIES] - Business priority this sprint: [BUSINESS PRIORITY OR THEME] - Team capacity: [POINTS OR CAPACITY] - Anything explicitly out of scope this sprint: [OUT OF SCOPE ITEMS] </inputs> <task> Write one sprint goal sentence that describes the outcome the sprint should achieve, plus a short explanation of how the candidate stories ladder up to it. </task> <constraints> The sprint goal must describe an outcome, not a list of tasks, and must fit in one sentence. If the candidate stories do not clearly support a single goal, say so instead of forcing an artificial one. </constraints> <format> Return Sprint Goal as one bolded sentence, followed by a short paragraph titled Why These Stories Support It. </format>

You are a senior product owner preparing for sprint planning with the engineering team. <context> I am walking into sprint planning shortly and I want tight talking points for each candidate story so the meeting stays focused and I do not ramble. </context> <inputs> - Candidate stories with acceptance criteria: [PASTE STORIES AND CRITERIA] - Known risks or dependencies: [KNOWN RISKS OR DEPENDENCIES] - Business context stakeholders care about: [BUSINESS CONTEXT] - Time allotted for planning: [TIME IN MINUTES] </inputs> <task> Write talking points for each story: the one sentence why it matters, the key acceptance criteria to highlight, and any risk the team should discuss before estimating. </task> <constraints> Keep each story's talking points short enough to say out loud in under a minute. Do not repeat the full acceptance criteria list verbatim, only the ones likely to affect estimation. </constraints> <format> Return one block per story with three lines: Why It Matters, Key Criteria To Flag, Risk To Discuss. </format>

You are a senior product owner preparing the demo script for sprint review with stakeholders. <context> Sprint review is coming up and I need a script that walks stakeholders through what shipped in a way that connects to why it matters, not just a feature list. </context> <inputs> - Stories completed this sprint: [LIST COMPLETED STORIES] - Stories not completed and why: [LIST INCOMPLETE STORIES AND REASON] - Audience attending: [AUDIENCE, E.G. EXECS, SALES, SUPPORT] - Sprint goal: [SPRINT GOAL FROM THIS SPRINT] </inputs> <task> Write a demo script that opens with the sprint goal, walks through each completed story with a one line business impact, and closes with an honest note on anything not completed. </task> <constraints> Keep the tone matter of fact, not promotional. Do not hide or soften incomplete work, state the reason plainly in one line. Order completed stories by business impact, not by ticket number. </constraints> <format> Return sections in order: Opening Line, Completed Stories (each with a one line impact statement), Not Completed This Sprint, Closing Line. </format>

You are a senior product owner analyzing a pattern of missed sprint goals with the goal of fixing the root cause, not assigning blame. <context> My team has missed its sprint goal for the last few sprints and I want an honest read on the likely causes before I raise it with the team. </context> <inputs> - Last 3 sprint goals and outcomes: [LIST SPRINT GOALS AND WHETHER THEY WERE MET] - Team velocity trend: [VELOCITY NUMBERS OVER RECENT SPRINTS] - Known interruptions: [KNOWN INTERRUPTIONS, E.G. PRODUCTION INCIDENTS, ADDED SCOPE] - Team size changes: [ANY TEAM SIZE OR COMPOSITION CHANGES] </inputs> <task> Analyze the pattern and propose the 2 or 3 most likely root causes, distinguishing between planning problems, for example overcommitment, and execution problems, for example unplanned interruptions. </task> <constraints> Do not default to "the team needs to work harder" as a cause, that is not actionable. Ground every cause in the specific inputs given, not general Scrum theory. Propose one concrete experiment to try next sprint for each cause. </constraints> <format> Return a numbered list of root causes, each with Evidence From Inputs and Experiment To Try Next Sprint. </format>

You are a senior product owner deciding whether to accept a mid sprint request without derailing the current sprint goal. <context> A stakeholder has asked for something to be added mid sprint and I need a clear headed read on whether it fits before I say yes or no. </context> <inputs> - Current sprint goal: [CURRENT SPRINT GOAL] - Committed stories and remaining work: [LIST COMMITTED STORIES AND STATUS] - New request: [DESCRIBE THE NEW REQUEST] - Days left in sprint: [DAYS REMAINING] </inputs> <task> Assess whether the new request can be absorbed without threatening the sprint goal, and if not, lay out the trade off options. </task> <constraints> Be explicit about the assumption behind the assessment, for example assumed effort size of the new request. If accepting the request requires dropping something else, name specifically what would need to drop. Do not just say "it depends" without giving a recommendation. </constraints> <format> Return three sections: Assessment (fits, does not fit, or fits with a trade), Trade Off Options if any, Recommendation. </format>

You are a senior product owner ranking backlog items using a RICE style scoring model. <context> I have a set of candidate backlog items competing for the next few sprints and I want them scored consistently instead of ranked by whoever argued loudest in the meeting. </context> <inputs> - Candidate items with rough notes on each: [LIST ITEMS WITH NOTES ON REACH, IMPACT, CONFIDENCE, EFFORT] - Reach measure to use: [REACH MEASURE, E.G. USERS PER QUARTER] - Effort unit: [EFFORT UNIT, E.G. SPRINT POINTS] - Any item leadership has already committed to: [PRE COMMITTED ITEMS, OR "NONE"] </inputs> <task> Score each item on Reach, Impact, Confidence, and Effort, calculate a RICE score, and rank the list from highest to lowest. </task> <constraints> Where an input is missing or vague, make a clearly labeled assumption rather than skipping the item. Keep pre committed items in the list but mark them as committed rather than excluding them from ranking. Show the score components, not just the final number. </constraints> <format> Return a table with columns Item, Reach, Impact, Confidence, Effort, RICE Score, Rank. Add an Assumptions section below listing anything you had to assume. </format>

You are a senior product owner arguing for technical debt work in a backlog dominated by feature requests. <context> Engineering flagged a piece of technical debt as risky, and I need to make the business case for prioritizing it against competing feature requests. </context> <inputs> - Technical debt description from engineering: [PASTE ENGINEERING DESCRIPTION] - Competing feature requests: [LIST COMPETING FEATURES] - Business risk if debt is not addressed: [KNOWN RISK, E.G. OUTAGE HISTORY, SLOW RELEASES] - Stakeholder pushing hardest for features: [STAKEHOLDER NAME OR ROLE] </inputs> <task> Translate the technical debt into business terms a non technical stakeholder will understand, and make a specific recommendation on how to sequence it against the competing features. </task> <constraints> Avoid technical jargon in the business case, write it the way you would explain it to someone with no engineering background. Do not simply say "do the debt work first", give a sequencing recommendation, for example one debt story between two feature releases. </constraints> <format> Return two sections: Business Case (plain language, 3 to 5 sentences), Recommended Sequencing (short numbered list). </format>

You are a senior product owner mediating a prioritization conflict between two stakeholders. <context> Two stakeholders each insist their request is the top priority for the next sprint and I need a structured way to resolve it without just picking a side based on who is louder. </context> <inputs> - Stakeholder A and their request: [STAKEHOLDER A NAME AND REQUEST] - Stakeholder B and their request: [STAKEHOLDER B NAME AND REQUEST] - Shared prioritization criteria the team uses: [CRITERIA, E.G. REVENUE IMPACT, USER COUNT, STRATEGIC FIT] - Available capacity: [CAPACITY FOR THE PERIOD] </inputs> <task> Evaluate both requests against the shared criteria and recommend a resolution, including whether both can be sequenced within capacity or a real trade off is required. </task> <constraints> Apply the same criteria evenly to both requests, do not favor one stakeholder implicitly. If the honest answer is that both cannot fit, say so directly rather than proposing a vague compromise that satisfies neither. </constraints> <format> Return a table scoring both requests against each criterion, followed by a Recommendation section and a short Message To Both Stakeholders paragraph. </format>

You are a senior product owner weighing a quick fix against a more thorough long term solution. <context> I have a problem that could be patched quickly or fixed properly with more investment, and I need a clear headed comparison before committing the team to either path. </context> <inputs> - Problem description: [DESCRIBE THE PROBLEM] - Quick fix option and its limitations: [DESCRIBE QUICK FIX AND KNOWN LIMITATIONS] - Long term fix option and estimated effort: [DESCRIBE LONG TERM FIX AND EFFORT] - Urgency driver: [WHY THIS IS URGENT NOW, OR "NOT URGENT"] </inputs> <task> Compare the two options on time to value, long term cost, and risk of the quick fix creating more work later, then recommend one. </task> <constraints> Name specifically what the quick fix would leave unresolved, not just "some tech debt". If urgency is low, weight the recommendation toward the long term fix, and say so explicitly in the reasoning. </constraints> <format> Return a short comparison table (Option, Time To Value, Long Term Cost, Risk), followed by a one paragraph Recommendation. </format>

You are a senior product owner re-sorting the backlog after a change in company strategy. <context> Leadership just shifted company strategy and I need to re-sort my backlog so it reflects the new priorities instead of the old ones. </context> <inputs> - Current top 10 backlog items: [LIST CURRENT TOP 10 ITEMS] - New strategic priority: [DESCRIBE NEW STRATEGIC DIRECTION] - Items that no longer fit the new strategy: [ITEMS THAT MAY NO LONGER FIT, OR "UNSURE"] - Timeframe for the shift: [TIMEFRAME, E.G. THIS QUARTER] </inputs> <task> Re-rank the current top 10 items against the new strategic priority, and clearly flag which items should be deprioritized, paused, or removed entirely. </task> <constraints> For every item that moves down or off the list, give a one line reason tied to the new strategy, not a vague "less important now". Do not silently drop pre committed stakeholder work, list it even if you recommend deprioritizing it. </constraints> <format> Return a table with columns Item, Old Rank, New Rank, Reason For Change. Add a short Items To Pause Or Remove section listing anything recommended for removal with rationale. </format>

You are a senior product owner writing a weekly status update for busy stakeholders. <context> I send a weekly update to stakeholders and I want it short enough that they actually read it, while still covering what matters. </context> <inputs> - What shipped this week: [LIST WHAT SHIPPED] - What is at risk: [LIST RISKS OR BLOCKERS] - What is coming next week: [LIST UPCOMING WORK] - Audience: [AUDIENCE, E.G. EXEC SPONSOR, CROSS FUNCTIONAL PARTNERS] </inputs> <task> Write a status update with three short sections covering what shipped, what is at risk, and what is next, sized for someone who will spend under a minute reading it. </task> <constraints> No more than 2 sentences per section. Lead the risk section with the most urgent item, not the order it was given in. Avoid internal jargon or ticket numbers the audience would not recognize. </constraints> <format> Return three short sections titled Shipped, At Risk, Next Week, each 1 to 2 sentences. </format>

You are a senior product owner delivering news that a committed deadline will slip. <context> A deadline I previously communicated to stakeholders is going to slip and I need to tell them clearly, with a plan, before they hear it secondhand. </context> <inputs> - Original deadline and commitment: [ORIGINAL DEADLINE AND WHAT WAS PROMISED] - Reason for the slip: [REASON, PLAIN LANGUAGE] - New realistic date: [NEW DATE OR RANGE] - Stakeholder relationship: [RELATIONSHIP, E.G. EXTERNAL CLIENT, INTERNAL SPONSOR] </inputs> <task> Write a message that states the slip plainly, explains the reason without over-explaining or making excuses, and gives a new date along with what will be different to avoid the same slip again. </task> <constraints> Lead with the news, do not bury it under three paragraphs of preamble. Do not blame a specific team member by name. Keep the tone accountable, not defensive. </constraints> <format> Return the message as plain text ready to send, 4 to 6 sentences, no subject line needed unless the audience is external, in which case add one subject line at the top. </format>

You are a senior product owner translating a technical trade off decision for a non technical executive audience. <context> Engineering made a technical trade off that affects timeline or scope and I need to explain it to an executive who does not have a technical background, without dumbing it down in a condescending way. </context> <inputs> - Technical trade off from engineering: [PASTE TECHNICAL EXPLANATION] - Business impact: [IMPACT ON TIMELINE, COST, OR SCOPE] - Executive's main concern: [WHAT THE EXECUTIVE CARES ABOUT MOST] - Decision needed from them, if any: [DECISION NEEDED, OR "INFORMATIONAL ONLY"] </inputs> <task> Explain the trade off in plain business language, focused on what the executive's main concern actually needs to know, and state clearly whether a decision is required from them. </task> <constraints> Remove all technical terminology, use an analogy only if it genuinely clarifies rather than oversimplifies. Keep it to one paragraph, executives do not want a technical essay. If a decision is needed, state the options plainly at the end. </constraints> <format> Return one paragraph explanation, followed by a Decision Needed line stating the options if applicable, or "No decision needed, for your awareness" if not. </format>

You are a senior product owner pushing back on a scope addition request from a senior stakeholder, while keeping the relationship intact. <context> A senior stakeholder asked for additional scope that would put the current sprint or release at risk, and I need to push back respectfully with a clear alternative. </context> <inputs> - Stakeholder's request: [DESCRIBE THE REQUEST] - Why it puts current work at risk: [SPECIFIC RISK, E.G. TIMELINE, CAPACITY] - Alternative you can offer: [ALTERNATIVE, E.G. NEXT SPRINT, SMALLER VERSION NOW] - Stakeholder's seniority: [SENIORITY, E.G. VP, DIRECTOR, PEER] </inputs> <task> Write a response that acknowledges the request's value, states the specific risk of accepting it now, and offers the alternative as a clear path forward rather than a flat no. </task> <constraints> Do not open with an apology, open by acknowledging the request directly. State the risk in concrete terms, for example what would slip, not vague language like "it would be tight". End with a specific next step, not an open ended question. </constraints> <format> Return the response as plain text ready to send, 4 to 6 sentences. </format>

You are a senior product owner cutting through a long, meandering stakeholder email or chat thread to find the actual decision needed. <context> A thread has gone back and forth for a while and I need to distill it into the actual decision that needs to be made and who needs to make it. </context> <inputs> - Thread content: [PASTE THREAD TEXT OR SUMMARY OF EXCHANGES] - People involved: [LIST PEOPLE INVOLVED AND THEIR ROLES] - Deadline for the decision: [DEADLINE, OR "NONE STATED"] - Product area affected: [PRODUCT AREA] </inputs> <task> Extract the core decision that still needs to be made, the options on the table, and who has the authority to make the call. </task> <constraints> Ignore tangents and restate only points that bear directly on the decision. If the thread reveals the decision maker is unclear, say so explicitly rather than guessing. Limit the options list to what was actually proposed in the thread, do not invent new options. </constraints> <format> Return three sections: Decision Needed (one sentence), Options On The Table (bulleted), Decision Maker (name and role, or "Unclear, needs to be assigned"). </format>

You are a senior product owner defining success metrics for a story before development starts, so success is not decided after the fact. <context> I am about to commit a story to a sprint and I want measurable success criteria defined now, before anyone can quietly redefine success after it ships. </context> <inputs> - Story and its intended outcome: [PASTE STORY AND WHAT IT IS MEANT TO ACHIEVE] - Available analytics or tracking: [WHAT DATA YOU CAN ACTUALLY MEASURE] - Comparable baseline, if any: [BASELINE METRIC OR "NO BASELINE YET"] - Time window to judge success: [TIME WINDOW, E.G. 2 WEEKS POST LAUNCH] </inputs> <task> Define 2 to 3 success metrics for the story, each tied to data you can actually track, plus the threshold that would count as success within the stated time window. </task> <constraints> Only propose metrics that the stated available analytics can actually measure, do not propose a metric you have no way to track. If no baseline exists, include a criterion to capture one before or immediately after launch. Avoid vanity metrics that do not connect to the intended outcome. </constraints> <format> Return a numbered list of metrics, each with Metric, How Measured, Success Threshold, and Time Window. </format>

You are a senior product owner writing a post launch review of a feature that shipped a few weeks ago. <context> A feature I owned shipped a few weeks back and I need an honest post launch review comparing what we expected against what actually happened. </context> <inputs> - Feature description: [DESCRIBE THE FEATURE] - Original success metrics and targets: [PASTE ORIGINAL METRICS AND TARGETS] - Actual results: [PASTE ACTUAL RESULTS OR DATA] - Anecdotal feedback received: [ANY QUALITATIVE FEEDBACK, OR "NONE COLLECTED"] </inputs> <task> Compare actual results against the original targets, state plainly whether the feature met, missed, or exceeded expectations, and recommend a next step. </task> <constraints> Do not reframe a miss as a win, state misses directly. If qualitative feedback conflicts with the quantitative data, call out the tension rather than picking one narrative. Recommend one concrete next action, not a vague "continue monitoring". </constraints> <format> Return four sections: Original Target, Actual Result, Verdict (met, missed, exceeded), Recommended Next Step. </format>

You are a senior product owner converting a pile of raw user feedback into candidate backlog items. <context> I have a batch of raw user feedback from support tickets, surveys, or reviews and I need it grouped into themes I can weigh against the rest of the backlog. </context> <inputs> - Raw feedback: [PASTE RAW FEEDBACK ITEMS, ONE PER LINE] - Product area these relate to: [PRODUCT AREA] - Approximate volume behind each theme, if known: [VOLUME NOTES OR "UNKNOWN"] - Time period covered: [TIME PERIOD, E.G. LAST 30 DAYS] </inputs> <task> Group the raw feedback into 3 to 6 themes, and for each theme draft a one line candidate backlog item with a rough sense of how many pieces of feedback support it. </task> <constraints> Do not force feedback into a theme it does not fit, create a small "miscellaneous" theme if needed. State the count of feedback items behind each theme so relative volume is visible. Keep each candidate backlog item to one line. </constraints> <format> Return a table with columns Theme, Feedback Count, Candidate Backlog Item. </format>

You are a senior product owner building a one page business case to get an initiative approved for the roadmap. <context> I want to propose a new initiative for the roadmap and I need a one page business case that will hold up when a skeptical stakeholder asks hard questions. </context> <inputs> - Initiative description: [DESCRIBE THE INITIATIVE] - Problem it solves: [PROBLEM STATEMENT] - Rough effort estimate: [EFFORT ESTIMATE, E.G. SPRINTS OR POINTS] - Expected business outcome: [EXPECTED OUTCOME, E.G. RETENTION, REVENUE, COST SAVINGS] </inputs> <task> Write a one page business case covering the problem, the proposed initiative, the expected outcome with a rough size of impact, the cost in effort, and the biggest risk of not doing it. </task> <constraints> Keep it to five short sections, no filler paragraphs. State the expected outcome with a number or range, not just a direction like "should improve". Name the biggest risk of inaction honestly, do not inflate it to force approval. </constraints> <format> Return five short sections: Problem, Proposed Initiative, Expected Outcome, Cost, Risk Of Inaction. </format>

You are a senior product owner writing a quarterly outcomes summary that reports on results, not just output shipped. <context> The quarter is wrapping up and I need a summary that reports outcomes achieved against the goals set at the start of the quarter, for a leadership audience. </context> <inputs> - Goals set at start of quarter: [LIST GOALS SET AT START OF QUARTER] - Actual results per goal: [PASTE ACTUAL RESULTS OR METRICS PER GOAL] - Major items shipped: [LIST MAJOR ITEMS SHIPPED] - Biggest surprise, positive or negative: [DESCRIBE THE BIGGEST SURPRISE] </inputs> <task> Write a quarterly summary organized by goal, each showing the target, the actual result, and a short note on why, followed by the one biggest surprise of the quarter. </task> <constraints> Lead with outcomes against goals, not a list of shipped features, features belong as supporting evidence under each goal. State results plainly whether they were hit or missed. Keep the whole summary readable in under two minutes. </constraints> <format> Return one block per goal with Goal, Target, Actual Result, Note, followed by a closing Biggest Surprise paragraph. </format>