ChatGPT Prompts for Product Managers

<context> I am a product manager planning discovery interviews for [PRODUCT]. The feature area under investigation is [FEATURE] and the target interviewee is [USER]. I want to validate the underlying problem before committing to a solution. </context> <task> 1. Write 12 open-ended, non-leading interview questions that uncover the [USER]'s current workflow, pain points, and workarounds around [FEATURE]. 2. Group the questions into three phases: warm-up/context, problem exploration, and current solutions. 3. For each question, add a one-line note on what signal it is meant to surface. 4. Flag any question that risks bias and rewrite it neutrally. 5. End with 3 follow-up probes I can use when an answer is vague. </task>

<context> I ran discovery interviews for [PRODUCT] about [FEATURE] with several [USER] participants. I will paste my raw notes below. I need to turn scattered observations into decision-ready insight. </context> <task> 1. Read the notes I paste and cluster observations into 4-6 themes, naming each theme in plain language. 2. For each theme, give a frequency estimate (how many participants raised it) and 1-2 representative quotes. 3. Separate stated needs from underlying jobs-to-be-done. 4. Rank themes by how strongly they justify investment in [FEATURE]. 5. List the top 3 open questions the interviews did NOT answer. </task>

<context> I want to validate demand for [FEATURE] in [PRODUCT] at scale before interviews. The audience is [USER]. The survey should take under 5 minutes. </context> <task> 1. Draft a 10-question survey mixing multiple-choice, Likert, and one open-text question. 2. Include a screening question to confirm the respondent matches [USER]. 3. Ensure at least one question measures current pain severity and one measures willingness to switch. 4. Avoid double-barreled and leading questions; flag any you had to fix. 5. Suggest the single metric I should track to decide go/no-go. </task>

<context> I am evaluating whether [PRODUCT] should build [FEATURE]. I need a quick competitive scan to understand how [USER] solves this today. </context> <task> 1. List the main categories of alternatives a [USER] currently uses to address the [FEATURE] problem, including non-software workarounds. 2. For each, summarize the typical approach, strengths, and gaps in 2-3 sentences. 3. Identify the white-space opportunity where [PRODUCT] could differentiate. 4. Note the assumptions in your answer that I should verify with primary research. 5. Recommend 3 competitor experiences I should personally test. </task>

<context> I have early discovery signal for [PRODUCT] suggesting [USER] struggles with something around [FEATURE]. I need a crisp problem statement to align the team before we ideate. </context> <task> 1. Draft a one-sentence problem statement using the format: [USER] needs a way to [job] because [motivation], but [obstacle]. 2. Provide two alternative framings at different scopes (narrow vs broad). 3. List the evidence that supports the problem and the evidence still missing. 4. State explicitly what is in and out of scope. 5. Add a falsifiable hypothesis we could test next. </task>

<context> I am writing a PRD for [FEATURE] in [PRODUCT]. The primary user is [USER]. I will provide the problem, goals, and any constraints. I need a complete, review-ready document. </context> <task> 1. Produce a PRD with these sections: Summary, Problem & Context, Goals & Non-Goals, Target [USER] & Use Cases, Requirements (must/should/could), Success Metrics, Risks & Open Questions. 2. Write requirements as testable statements, not vague intentions. 3. Explicitly list Non-Goals to prevent scope creep. 4. Flag any section where I have not given you enough input and ask for it. 5. Keep it skimmable with short paragraphs and bullets. </task>

<context> I have drafted a spec for [FEATURE] in [PRODUCT] for [USER]. Before I share it with engineering, I want it stress-tested for gaps. </context> <task> 1. Read the spec I paste and list every ambiguous or underspecified requirement. 2. Identify edge cases and error states the spec does not cover. 3. Call out hidden assumptions about [USER] behavior or technical constraints. 4. Flag any requirement that conflicts with another. 5. Output a prioritized list of clarifications I should resolve before handoff. </task>

<context> I need a thorough edge-case and error-handling section for [FEATURE] in [PRODUCT]. The user is [USER]. </context> <task> 1. Enumerate edge cases across categories: empty/null inputs, max/min limits, concurrency, permissions, offline/slow network, and unusual [USER] behavior. 2. For each, describe the expected system behavior in one line. 3. Highlight which edge cases are most likely to occur for [USER] in real use. 4. Note any cases that need a product decision rather than an engineering default. 5. Format as a table I can drop into the spec. </task>

<context> Leadership wants a one-pager on [FEATURE] for [PRODUCT] before approving a full spec. The user is [USER]. It must be persuasive but honest. </context> <task> 1. Write a one-page brief: the problem in one paragraph, the proposed solution, why now, expected impact, rough effort, and the ask. 2. Lead with the [USER] outcome, not the feature mechanics. 3. Quantify impact where possible and state assumptions behind any number. 4. Include a short risks section so it does not read as a sales pitch. 5. End with a clear, single decision request. </task>

<context> I am about to scope [FEATURE] for [PRODUCT] but several details are still fuzzy. I need to interrogate stakeholders before writing the spec. The end user is [USER]. </context> <task> 1. Generate the 10 most important clarifying questions I should ask stakeholders before specifying [FEATURE]. 2. Group them by stakeholder type (eng, design, sales, support, legal). 3. For each question, note the risk of NOT having the answer. 4. Mark which questions block writing the spec versus which can be resolved later. 5. Suggest a logical order to ask them in. </task>

<context> I am prioritizing the backlog for [PRODUCT] and need to apply RICE scoring. I will paste a list of candidate features, including [FEATURE]. The core user is [USER]. </context> <task> 1. For each feature I paste, propose Reach, Impact, Confidence, and Effort estimates with a one-line rationale each. 2. Calculate the RICE score and rank the features. 3. Flag any estimate that rests on a shaky assumption I should validate. 4. Note which features are quick wins versus big bets. 5. Output a ranked table plus a 2-sentence recommendation. </task>

<context> I need to turn a prioritized backlog for [PRODUCT] into a themed quarterly roadmap. The strategic goal this quarter is to better serve [USER], and [FEATURE] is a candidate. </context> <task> 1. Organize the work I paste into 3-4 outcome-based themes, not a list of features. 2. Map candidate items including [FEATURE] to the themes and a Now / Next / Later horizon. 3. For each theme, state the [USER] outcome and the metric that proves it worked. 4. Identify dependencies and sequencing risks. 5. Note what we are deliberately NOT doing this quarter and why. </task>

<context> The team disagrees on whether to build [FEATURE] now in [PRODUCT]. I need a neutral trade-off analysis to drive a decision for [USER]. </context> <task> 1. Lay out 3-4 realistic options (e.g. build now, build lite, defer, buy/integrate) for [FEATURE]. 2. Evaluate each against criteria: [USER] impact, effort, risk, strategic fit, and reversibility. 3. Present it as a scored matrix with brief justifications. 4. State which option you would recommend and the single biggest reason against it. 5. List the data point that would most change the recommendation. </task>

<context> I need to translate a high-level strategy for [PRODUCT] into quarterly OKRs for my product team. The strategic focus is delivering value to [USER] partly via [FEATURE]. </context> <task> 1. Propose 2-3 Objectives that are qualitative, inspiring, and tied to [USER] value. 2. Under each, write 3 measurable Key Results with baseline and target placeholders. 3. Ensure Key Results are outcomes, not feature-shipped checkboxes. 4. Flag any KR that is a vanity metric and suggest a better one. 5. Note which initiatives, including [FEATURE], support each Objective. </task>

<context> [FEATURE] in [PRODUCT] is at risk of missing its deadline. I need to identify the minimum lovable version for [USER] without shipping something broken. </context> <task> 1. Break [FEATURE] into its component capabilities from the description I paste. 2. Classify each as must-have for launch, fast-follow, or cut-entirely for [USER] value. 3. Define the minimum lovable version and what makes it lovable rather than merely minimal. 4. List the risks of each cut and how to communicate them. 5. Draft a 3-bullet message I can send to stakeholders explaining the scope change. </task>