Product Management prompts

Role, context, task, format.

Act as a senior product manager. We are adding a notifications centre to a B2B analytics dashboard used by data teams. The goal is to cut missed alerts, the main constraint is that engineering has two sprints. Write a PRD draft with these sections: problem statement, goals and non-goals, target user, user stories with acceptance criteria, key flows, risks, and open questions. Flag anything you had to assume.

Non-leading, forty-five minutes.

Act as a senior product manager preparing discovery interviews with [target persona] about [problem area]. Draft a 45-minute discussion guide: a warm-up, five open questions that avoid leading the user, two follow-up probes each, and a closing question. Keep it non-leading and focused on their real behaviour, not our solution.

Ranked by felt intensity.

Here are my raw notes from a user interview: [paste]. Pull out the top pain points ranked by how strongly the user felt them, the jobs they were trying to do, any workarounds they mentioned, and three quotes worth keeping. Flag anything that contradicts what I expected to hear.

Five transcripts, one map.

I have five interview transcripts about [problem area]: [paste]. Synthesise them into themes: for each theme give a short name, how many of the five raised it, a representative quote, and what it implies for the product. List anything only one person said separately so I don't over-weight it.

Cheapest way to test.

Act as a product researcher. Turn this feature idea, [describe], into three testable assumptions and, for each, the cheapest way to validate it before we build anything. Rank them by how badly we'd be hurt if the assumption is wrong.

Five questions, no leading.

Write a five-question survey to test whether [target user] actually has the problem of [problem]. Use a mix of one screening question, two behaviour questions about what they do today, and two on willingness to change. Avoid questions that lead them toward yes.

Thirty minutes into three.

Act as a senior PM. Convert these messy notes from a brainstorm into a structured PRD: [paste]. Sections: problem statement, goals and non-goals, target user, user stories with acceptance criteria, key flows, dependencies, risks, and open questions. Where the notes are silent, add an open question rather than inventing an answer.

Skeptical engineer and designer.

Here is a draft PRD: [paste]. Review it like a skeptical staff engineer and a skeptical designer. List the parts that are ambiguous, the edge cases that are missing, the acceptance criteria that can't be tested, and any scope that looks bigger than the stated goal needs.

For an exec audience.

Write a one-page feature brief for [feature] aimed at an exec audience. Cover the problem, who it's for, the proposed solution in three sentences, the expected impact, and what we are explicitly not doing. Plain language, no jargon, under 300 words.

Grouped, owned, meeting-sized.

Turn this PRD into a set of open questions for a spec review: [paste]. Group them by area (scope, design, technical, data, launch) and, for each, note who most likely owns the answer. Keep the list short enough to get through in a 30-minute meeting.

Say what's out.

Draft the non-goals section for a PRD about [feature]. Given the goal is [goal] and the constraint is [constraint], list six things we are deliberately not doing in this version and one sentence on why each is out of scope, so nobody assumes it later.

As a user, I want.

Rewrite this requirement as user stories: [paste]. Use the format: As a [user], I want [goal], so that [benefit]. For each story add acceptance criteria as a short checklist, and flag any assumption you had to make to write it.

Happy path plus edges.

Write acceptance criteria for this user story in Given/When/Then form: [paste story]. Cover the happy path, at least two edge cases, and one error state. Keep each criterion independently testable.

Find the thinnest slice.

This story feels too big for one sprint: [paste]. Split it into smaller stories that each deliver something usable on their own, in a sensible build order, and tell me which one is the thinnest slice we could ship to learn the most.

Functional, edge, nasty real-world.

Act as a QA engineer. Given this feature, [describe], list the test cases you'd want before release: functional, edge, permissions, and one or two nasty real-world scenarios a user might actually hit. Group them and mark which are must-pass for launch.

Numbers, and the assumptions.

Here is a list of candidate features with rough notes: [paste]. Score each with RICE (reach, impact, confidence, effort), show the numbers you used and the assumptions behind them, and rank the list. Call out any score you're least confident in so I can sanity-check it.

Reasoned against the goal.

Act as a product manager. Sort these initiatives into a Now / Next / Later roadmap: [paste]. Base it on [our goal this quarter] and [our main constraint], explain the reasoning for anything you put in Now, and note what would have to change to promote something from Later.

The theme and the bets.

Help me build a quarterly roadmap narrative. Product: [name]. This quarter's goal: [goal]. Engineering capacity: [capacity]. Known initiatives: [paste]. Draft a one-paragraph theme for the quarter, the three or four bets that ladder up to it, and what we're saying no to.

No spin, real reasoning.

I need to defend a prioritisation decision. We chose [feature A] over [feature B] because [reason]. Write a short, honest rationale I can share, including the trade-off we accepted and what would make us revisit it. No spin, just the real reasoning.

Name the missed bet.

Act as a devil's advocate on this roadmap: [paste]. Argue the strongest case that we're focused on the wrong things, name the opportunity we might be missing, and point out any item that looks like it's there for internal reasons rather than user value.

Honest about slippage.

Write a monthly product update for stakeholders from these notes: [paste]. Structure: what shipped, what's in progress, what's next, and any risks or asks. Confident but honest about slippage, under 250 words, skimmable with short bullets.

Blocked first, then progress.

Turn these standup notes into a two-line async update for the team channel: [paste]. Lead with anything blocked or at risk, then progress, then what I need from anyone. Keep it plain and scannable, no filler.

Own the slip, honestly.

I need to tell stakeholders a launch is slipping by [time] because [reason]. Draft a short, straight message: what changed, the impact, the new date, and what we're doing about it. Own it without over-apologising, and end with the one thing I need from them.

Lead with business impact.

Rewrite this technical update for a non-technical exec: [paste]. Cut the jargon, lead with the business impact, and keep any detail only if it changes a decision. Three short paragraphs at most.

Anticipate the hardest questions.

Draft talking points for a roadmap review with leadership. Context: [paste]. Anticipate the three hardest questions they'll ask, and for each give me a straight answer and the one number or fact that backs it up.

Frequency and severity, separately.

Here is a batch of customer feedback from [source]: [paste]. Group it into themes, rank them by frequency and by severity separately, and for each theme suggest whether it points to a bug, a missing feature, or a UX problem. Keep the raw counts so I can check your grouping.

What's trending, what's urgent.

Summarise these support tickets into a weekly product signal: [paste]. What's trending up, what's new this week, and which one issue, if fixed, would remove the most tickets. Flag anything that looks urgent.

What the data supports.

I ran an experiment: [describe setup, variants, and results with numbers]. Help me interpret it. What does the data support, what does it not support, what could confound it, and what's the honest next step? Tell me if the sample looks too small to conclude anything.

Three theories, one check each.

Act as a data-literate PM. Given these metrics, [paste], write three plausible explanations for the change in [metric], and for each, the one query or check that would confirm or kill it. Don't pick a favourite until the checks are done.

Cluster, estimate, sort by strategy.

Turn this pile of feature requests into a decision-ready summary: [paste]. Cluster similar asks, estimate rough demand from how often each shows up, and separate the ones that fit our strategy from the ones that don't, with a one-line reason each.

Everything before you flip it.

Draft a go-to-market checklist for launching [feature] to [audience]. Cover positioning, the messaging in one line, docs and support prep, internal enablement, the rollout plan, and the success metric we'll watch in week one. Mark anything that must be done before we flip it on.

In-app note and changelog.

Write release notes for [feature] in two versions: a short in-app note for users and a longer changelog entry. Lead with the benefit, not the mechanism, keep the tone plain and friendly, and avoid overselling a small change.

Three pitches, one winner.

Act as a product marketer. Give me three positioning angles for [feature], each with the core benefit, who it lands best with, and the one-sentence pitch. Then tell me which angle is strongest for [our main audience] and why.

No surprises at launch.

Draft an internal launch brief so sales and support aren't surprised: [paste feature details]. Include what it does, who it's for, the top three questions customers will ask with answers, and what to say if someone asks for something it doesn't do yet.