AI Prompts for Product Management

Write a discovery brief for [PROBLEM OR OPPORTUNITY AREA]. Include: the problem statement in one sentence, the user segment affected and their current behavior, the business hypothesis (if we solve this, we expect to see), the key questions we need to answer before deciding whether to build, the research methods we will use, and the success criteria for this discovery phase. The brief should be clear enough that anyone on the team can run the research.

Write a customer interview guide for discovery research on [PROBLEM AREA] targeting [USER SEGMENT]. My hypothesis is: [DESCRIBE YOUR ASSUMPTION ABOUT THE PROBLEM]. Write 8 to 10 questions that: explore their current behavior without leading them to confirm my hypothesis, uncover the emotional and practical drivers of their decisions, reveal what they have already tried, and help me understand how much this problem costs them in time, money, or frustration.

I have completed discovery research on [TOPIC] with [NUMBER] customers. Key observations: [DESCRIBE WHAT YOU HEARD AND SAW]. Synthesize these findings into: a clear problem statement, the user jobs-to-be-done this problem relates to, the current workarounds users are using, the size and urgency of the pain, and a recommended next step (build, run more research, or deprioritize). This will inform our roadmap prioritization.

Write an opportunity assessment for [PRODUCT AREA OR FEATURE]. Cover: the user problem and who has it, the size of the opportunity (users affected, frequency, severity), the current alternatives users rely on, the business case (how this connects to our key metrics), the rough effort estimate, and a recommendation on whether to pursue, deprioritize, or gather more information. Format for presentation to leadership.

I need to align my team around this problem before we jump to solutions: [DESCRIBE THE PROBLEM AREA]. Write a problem statement that: describes the user and their situation, states the problem specifically and with evidence, quantifies the impact where possible, explains why this is the right time to solve it, and is written in a way that opens the space for solutions rather than implying one.

Write a roadmap item for [FEATURE OR INITIATIVE]. Include: the problem it solves and the user segment affected, the business outcome it is expected to drive, the key metrics we will use to measure success, the rough scope and estimated effort, any dependencies or risks, and where this sits in the prioritization relative to other items. Format for a roadmap tool or stakeholder presentation.

Help me prioritize this product backlog using [FRAMEWORK: RICE, ICE, MOSCOW, VALUE VS. EFFORT]. My items are: [LIST BACKLOG ITEMS]. For each item, apply the framework: [DESCRIBE SCORING CRITERIA]. After scoring, recommend the top five items to focus on this quarter and explain why, noting any items that score well but have dependencies that block them.

Write a roadmap communication to share with [AUDIENCE: ENGINEERING, SALES, EXECUTIVES, THE WHOLE COMPANY] covering [TIMEFRAME: Q3, H2, THE NEXT SIX MONTHS]. The key themes or bets for this period are: [DESCRIBE]. The top three to five initiatives are: [LIST WITH ONE-LINE DESCRIPTIONS]. What is not on the roadmap and why: [DESCRIBE]. The communication should set clear expectations, explain the prioritization logic, and invite the right questions.

A stakeholder has requested that we add [DESCRIBE FEATURE OR PROJECT] to the roadmap. The reason they give is: [DESCRIBE]. Our current priorities are: [DESCRIBE]. Write a response that: takes their request seriously, acknowledges the business value they see in it, explains honestly where it sits in relation to current priorities, and proposes a path forward (evaluate it in the next planning cycle, trade it against something else, or escalate for leadership decision).

Write a roadmap retrospective for [TIME PERIOD]. We planned to build: [LIST PLANNED ITEMS]. What we actually shipped: [LIST]. What slipped and why: [DESCRIBE]. What the data says about the impact of what we shipped: [DESCRIBE METRICS]. The key lessons for the next planning cycle: [DESCRIBE]. Format this for a leadership review and team retrospective. Be honest about what did not go to plan.

Write a PRD for [FEATURE NAME]. Include: the problem statement and user need, the goals and success metrics, user stories organized by persona, the scope (in scope and explicitly out of scope), key user flows, edge cases and how they are handled, non-functional requirements (performance, accessibility, security if relevant), dependencies, and open questions. The audience is the engineering and design team.

Write user stories for [FEATURE NAME] for [USER TYPE]. The feature: [DESCRIBE]. For each user story, use the format: As a [USER TYPE], I want to [ACTION] so that [BENEFIT]. Then add: the acceptance criteria (given/when/then format), the edge cases to handle, and any technical notes relevant to implementation. Write stories at the right level of granularity for a two-week sprint.

Define the acceptance criteria for [FEATURE OR USER STORY]: [DESCRIBE THE FEATURE]. For each acceptance criterion, use the given/when/then format. Cover: the happy path, error states and how they are handled, edge cases with unusual input or behavior, performance requirements if relevant, and accessibility requirements. The criteria should be specific enough that QA can write test cases directly from them.

Write the technical requirements section of a spec for [FEATURE] to share with the engineering team. Include: the data model or schema changes needed, the API endpoints required (request and response structure), the performance requirements (load time, concurrency, data volume), security and privacy requirements, integration dependencies, and any technical constraints or preferences based on our existing architecture. Flag any areas where engineering input is needed before the spec is final.

Write a rollout plan for [FEATURE NAME]. Include: the rollout stages (internal, beta, gradual percentage rollout, full release), the success and rollback criteria at each stage, what metrics will be monitored during rollout, the feature flag configuration, who can access each stage and how, and the communication plan for each stage. The goal is to catch problems early without delaying the full release unnecessarily.

Write a sprint or weekly product update for [AUDIENCE: ENGINEERING, STAKEHOLDERS, LEADERSHIP]. This week: [DESCRIBE WHAT WAS COMPLETED]. In progress: [DESCRIBE ACTIVE WORK]. Blockers or risks: [DESCRIBE]. Next week: [DESCRIBE PLANNED WORK]. Key metrics update: [DESCRIBE]. Keep it under 300 words and in a format people will actually read. Lead with anything that requires attention or a decision.

Write a post-launch review for [FEATURE NAME], launched on [DATE]. The launch goals were: [DESCRIBE]. What happened: [DESCRIBE METRICS AND USER RESPONSE]. What went well: [DESCRIBE]. What did not go as planned: [DESCRIBE]. What we would do differently: [DESCRIBE]. Impact on our key product metrics: [DESCRIBE]. This will be shared with [AUDIENCE: THE TEAM, LEADERSHIP, THE WHOLE COMPANY].

Write a product principles document for [PRODUCT OR TEAM]. Our mission is: [DESCRIBE]. Our target user is: [DESCRIBE]. The key decisions we want these principles to guide are: [DESCRIBE TYPE OF DECISIONS]. Write five to seven product principles that are: specific enough to rule things out, memorable enough to be repeated, and grounded in our actual users and strategy. Include a brief explanation of why each principle matters.

I need to escalate a blocker affecting [TEAM OR PROJECT]. The blocker is: [DESCRIBE]. It has been unresolved for [DURATION]. The impact if unresolved by [DATE] is: [DESCRIBE]. What I have already tried: [DESCRIBE]. Write a clear escalation message to [RECIPIENT: ENGINEERING LEAD, ENGINEERING MANAGER, LEADERSHIP] that states the problem and its impact, what I need, and by when. Maintain a collaborative tone.

Write an A/B test hypothesis and design for [WHAT YOU WANT TO TEST]. The metric I want to move is: [DESCRIBE METRIC]. My hypothesis is: [DESCRIBE WHAT YOU BELIEVE AND WHY]. Test design: control (current state), variant (proposed change), success metric and minimum detectable effect, sample size needed based on [CURRENT BASELINE], and the risk of a false positive or false negative at the planned sample size. Also state what I will do if the test is inconclusive.