I spend a surprising amount of my week on writing that used to eat entire afternoons: PRDs that nobody reads in full, user stories that miss edge cases, interview summaries that lose the quote that mattered, roadmap docs that age the day after they're written.
Over the last year I've built a small set of AI prompts that handle the structure of this work — not the judgment, the structure. The prompt writes the skeleton, fills in the boilerplate, surfaces the questions I forgot to ask. I still make the product decisions. I just don't burn two hours formatting them.
This post is those prompts. Not a teaser — the actual prompts, with the actual structure they produce, and a short note on why each one works. If they're useful, steal them. If you want the full set of 50+ prompts covering the entire product lifecycle (discovery → PRD → delivery → launch → GTM), I link to it at the bottom.
Why most "PM prompts" are bad
Every AI prompt list for product managers I've seen has the same flaw: the prompts are too vague. "Write a PRD for a feature" produces a generic template that misses the only things that make a PRD useful — the specific problem, the specific user, the specific constraint that forces a tradeoff. The model isn't broken; you've given it nothing specific to optimize for, so it optimizes for the average of every mediocre PRD it was trained on.
Every prompt below follows the same four-part structure:
1. ROLE — Who the model is pretending to be.
2. CONTEXT — The specific product, user, and goal.
3. CONSTRAINTS— Format, length, what to avoid, what to include.
4. OUTPUT — The exact shape of what you want back.
Vague prompts fail because they skip 2 and 3. Every prompt below has all four.
Prompt 1 — The one-page PRD
Most PRDs die because they're too long. A one-pager forces you to decide what actually matters. This prompt drafts the structure; you fill the specifics.
ROLE: You are a senior product manager drafting a one-page PRD.
CONTEXT: The feature is [FEATURE NAME]. It solves [SPECIFIC PROBLEM]
for [SPECIFIC USER PERSONA]. The primary success metric is [METRIC].
The main technical constraint is [CONSTRAINT]. The deadline is [DATE].
CONSTRAINTS: Maximum one page (~500 words). Use these exact sections
in this order: Problem, Users, Goal (non-goals explicitly listed),
Proposed solution (3 bullets max), Success metrics (1 primary +
2 guardrail), Open questions (bulleted). No background fluff. No
"executive summary" header. No adjectives like "seamless", "robust",
"powerful".
OUTPUT: The PRD in markdown. End with a line listing the 3 riskiest
assumptions.
Why it works: The "maximum one page" + "exact sections in this order" constraints kill the 12-page rambling PRD. Forcing "non-goals explicitly listed" is the single highest-leverage PRD discipline — most PRD failures are scope creep from never stating what you're NOT doing. The "3 riskiest assumptions" closer surfaces what should actually be validated before build.
Example output (for a fictional notifications feature):
Problem
38% of weekly active users who start a report never finish it. Session recordings show they leave at the "share with team" step. There is no way to notify a teammate that a report is ready for review.
Users
Primary: Report authors (analysts, team leads) who need async review. Secondary: Reviewers who currently miss reports shared via chat.
Goal
- Increase report completion rate from 62% to 75% within 8 weeks.
- Non-goals: Mobile push (web only for v1), Slack/Teams integration (out of scope), digest emails.
Proposed solution
- In-product "Notify for review" button on report completion.
- Recipient gets an in-app notification + email with a deep link.
- Sender sees read receipts.
Success metrics
- Primary: report completion rate (target +13pp).
- Guardrail: notification click-through rate (target >30%, or we're spamming); unsubscribe rate (target <5%).
Open questions
- Do reviewers want to act on notifications from mobile, even if v1 is web-only?
- Should notifications be batched (digest) or real-time?
- What happens if the recipient is not a teammate — fallback to share link?
Riskiest assumptions: (1) the drop-off is caused by lack of notification, not by report quality; (2) reviewers will actually engage with notifications rather than mute them; (3) email is an acceptable delivery channel.
The non-goals section is doing the real work — without it, this PRD would balloon into a notifications platform.
Prompt 2 — User stories that don't miss edge cases
"As a user, I want to X, so that Y" is a format, not a specification. The format hides missing acceptance criteria, error states, and edge cases. This prompt drafts the story AND the cases most PMs forget.
ROLE: You are a product manager writing a user story for engineering.
CONTEXT: The feature is [FEATURE]. The user is [PERSONA]. The trigger
is [WHEN THEY DO WHAT]. The happy path is [WHAT SHOULD HAPPEN].
CONSTRAINTS: Output the story in this format:
- Title (verb + noun, ≤8 words)
- Story: As a [persona], I want [action], so that [outcome].
- Acceptance criteria: 3-5 Given/When/Then statements.
- Edge cases: list 4 edge cases (empty input, permission denied,
timeout, concurrent edit). Do NOT solve them — just name them.
- Out of scope: 2-3 things explicitly excluded.
No implementation detail. No UI description. No timeline.
OUTPUT: The story in markdown under a single H2.
Why it works: The four edge cases ("empty input, permission denied, timeout, concurrent edit") are the cases that cause 80% of production bugs and that junior PMs systematically miss. Forcing "do NOT solve them — just name them" keeps the story focused on WHAT, not HOW. The "out of scope" section prevents scope creep during sprint planning.
Example output (for a "save draft" story):
Save report draft automatically
Story: As a report author, I want my draft to save automatically every 30 seconds, so that I don't lose work if my browser crashes.
Acceptance criteria:
- Given I'm editing a draft, when 30 seconds pass with changes, then the draft is saved to the server without a visible indicator.
- Given the save succeeds, when I reload the page, then my latest changes are present.
- Given the save fails (network error), when the retry also fails, then I see a non-blocking warning banner with a manual "Save now" button.
- Given I'm offline, when I continue editing, then changes are queued in localStorage and synced when connectivity returns.
Edge cases:
- Two tabs editing the same draft simultaneously (concurrent edit conflict).
- Draft exceeds storage size limit.
- User logs out mid-edit.
- Server returns 5xx for >60 seconds.
Out of scope: version history, multi-user real-time collaboration, conflict resolution UI.
The concurrent-edit edge case is the one that would have cost a sprint of rework if it surfaced in QA instead of in the story.
Prompt 3 — User interview summary that keeps the quote
The most useful artifact from a user interview is rarely the summary — it's the verbatim quote that captures the actual pain. Most AI summaries paraphrase the quote into uselessness. This prompt keeps the quote and structures the rest around it.
ROLE: You are a product researcher summarizing a user interview.
CONTEXT: The interview is with [PERSONA]. The topic was [TOPIC].
The goal was to learn [LEARNING GOAL]. The raw notes/ transcript is
pasted below.
[PASTE NOTES]
CONSTRAINTS: Output exactly these sections:
- One-sentence headline (the single most important takeaway).
- Top 3 surprises (things that contradicted prior assumptions).
- 3-5 verbatim quotes (in quotation marks, with the speaker's words
unchanged — do NOT paraphrase, do NOT clean up grammar).
- Behaviors observed (what they did, not what they said).
- Open questions for the next interview.
Maximum 250 words. No executive summary. No "overall the interview
went well".
OUTPUT: Markdown. Quotes in blockquotes with attribution.
Why it works: "Verbatim, do NOT paraphrase" is the constraint that saves the artifact. Paraphrased quotes are worthless in a research repository — six months later, nobody can tell whether the pain was the user's words or the PM's interpretation. The "behaviors observed (what they did, not what they said)" section separates stated preference from revealed preference, which is where most product insights actually live.
Prompt 4 — Competitor feature teardown
A competitor matrix that lists features in a grid is useless — it tells you what exists, not what's good. This prompt produces a teardown that surfaces the actual product decisions worth learning from.
ROLE: You are a product analyst doing a teardown of a competitor feature.
CONTEXT: The competitor is [COMPETITOR]. The feature is [FEATURE].
I have used it and my observations are below:
[PASTE OBSERVATIONS — what you clicked, what happened, what surprised you]
CONSTRAINTS: Output these sections:
- What the feature does (1 sentence, factual).
- Who it's for (specific persona, not "everyone").
- What problem it solves (the job-to-be-done).
- 3 product decisions worth stealing (specific decisions, not
"has good UX"). For each: the decision, why it likely was made,
what tradeoff it implies.
- 2 things they got wrong (with reasoning).
- 1 question I'd ask their PM if I could.
No generic praise. No "they should add AI". No feature-list tables.
OUTPUT: Markdown, ~300 words.
Why it works: "3 product decisions worth stealing" forces you to extract transferable insight instead of cataloging features. "What tradeoff it implies" surfaces the hidden cost of every decision — every UI choice trades speed for clarity, every default trades opinionation for flexibility. Naming the tradeoff is what makes a teardown useful instead of envious.
Prompt 5 — The roadmap that ages well
Most roadmaps lie because they're written as commitments. The useful ones are written as bets with explicit assumptions. This prompt drafts a bets-style roadmap.
ROLE: You are a product manager drafting a quarterly roadmap.
CONTEXT: The product is [PRODUCT]. The north-star metric is [METRIC,
current value X]. The quarter's theme is [THEME]. The team capacity
is [N engineers for M weeks]. The top 3 customer asks are:
1. [ASK 1]
2. [ASK 2]
3. [ASK 3]
CONSTRAINTS: Output as a table with columns: Bet | Hypothesis | Metric
we'll move | Cost (S/M/L) | Kill criteria. Group bets into "Now"
(next 4 weeks), "Next" (weeks 5-8), "Later" (weeks 9-12). Maximum
3 bets per group. Every bet must have a kill criteria — the condition
under which we'd stop pursuing it. No dates. No "Q3 2026" headers.
OUTPUT: Markdown table.
Why it works: "Every bet must have a kill criteria" is the constraint that makes the roadmap honest. A roadmap without kill criteria is a wishlist; a roadmap with them is a portfolio of bets with defined exits. The "Hypothesis" column forces causal thinking ("if we ship X, then metric Y will move because Z") instead of feature-list thinking. The Now/Next/Later grouping (from Shape Up / JTBD practice) avoids false date precision.
Prompt 6 — Stakeholder update that doesn't waste their time
Executives and cross-functional partners read your update to answer one question: "Do I need to do anything?" If the answer is buried in paragraph four, you've wasted their time and yours. This prompt front-loads the ask.
ROLE: You are a product manager writing a weekly stakeholder update.
CONTEXT: The project is [PROJECT]. Status this week: [ON TRACK /
AT RISK / BLOCKED]. The one thing I need from this audience is
[SPECIFIC ASK OR "nothing — FYI only"]. Key progress this week:
[2-3 BULLETS]. Key risks: [1-2 BULLETS].
CONSTRAINTS: Maximum 150 words. Structure:
- Line 1: STATUS in caps + the single ask (or "FYI only").
- Line 2: ship date or "date TBD".
- Then "Progress:" with max 3 bullets.
- Then "Risks:" with max 2 bullets.
- Then "Decisions needed:" with max 2 bullets (or "none").
No "we had a productive week". No "the team is heads-down". No
adjectives. Bullets must start with a verb or a noun, never "We".
OUTPUT: Markdown, ready to paste into Slack or email.
Why it works: The ask goes on line 1 because that's the only line most readers will finish. The "We" prohibition kills the passive-voice status updates that read like diary entries ("We met with design… We reviewed the spec…"). Forcing "verb or noun" openers produces "Spec approved by design" instead of "We got the spec approved" — same information, half the words, no ego.
Prompt 7 — Reframe vague feedback into actionable input
"This is confusing." "It needs to be more intuitive." "Can it pop more?" Feedback like this is unactionable as stated — but it usually points at a real problem. This prompt reframes vague feedback into a specific, testable hypothesis.
ROLE: You are a product manager translating vague stakeholder feedback
into an actionable hypothesis.
CONTEXT: The feedback was: "[VERBATIM FEEDBACK]". It came from
[STAKEHOLDER ROLE] during [REVIEW / DEMO / EMAIL]. The feature in
question is [FEATURE]. My current best guess at what they meant is
[INTERPRETATION].
CONSTRAINTS: Output:
- Three possible interpretations of the feedback, ranked by
likelihood. For each, the specific evidence in the verbatim that
supports it.
- For the top interpretation: a concrete, testable hypothesis in
"If we [CHANGE], then [OUTCOME], because [REASONING]" form.
- One clarifying question to ask the stakeholder (not more than one).
No "I think they meant". No defensive framing. No solutions yet —
just sharpen the problem.
OUTPUT: Markdown, ~150 words.
Why it works: Three ranked interpretations force you to consider that your first read might be wrong — and the stakeholder's words often support a different read than your instinct. The single clarifying question constraint prevents the "let's schedule a 30-minute call to align" reflex that turns one vague comment into a calendar invite. Sharpening the problem before proposing a solution is the difference between a PM and a ticket-writer.
Prompt 8 — The launch checklist that survives Monday morning
Launch checklists fail in two ways: they're written by one person who forgets the steps they didn't do, or they're so generic they don't apply to the actual launch. This prompt drafts a checklist specific to the feature and the company.
ROLE: You are a product manager building a launch checklist.
CONTEXT: The feature is [FEATURE]. Launch date is [DATE]. It touches
these surfaces: [LIST — e.g. web app, mobile, API, docs, billing].
The audience is [INTERNAL / BETA / ALL USERS / ENTERPRISE ONLY].
Rollout strategy is [FLAGGED / ALL AT ONCE / PERCENTAGE].
CONSTRAINTS: Output a checklist grouped by:
- T-5 days (prep): eng sign-off, QA sign-off, docs PR opened,
support team briefed, analytics events implemented + verified,
rollback plan documented.
- T-1 day (ready): changelog written, in-product announcement
drafted, status page updated if infra-impacting, sales/CSE
briefed if enterprise-impacting.
- Launch day: flag enabled / deploy shipped, smoke test on prod,
monitor error rate + core metric for 2 hours, announce.
- T+1 day: collect top 3 support tickets, collect top 3 complaints,
decide: keep / iterate / roll back.
Every item must be a checkbox (not a paragraph). Maximum 8 items
per group. Items must be specific to this feature where possible.
OUTPUT: Markdown checklist.
Why it works: The T-5 / T-1 / Launch / T+1 cadence maps to how launches actually fail: most failures are missing prep items (analytics not implemented, support not briefed), not launch-day bugs. Forcing "decide: keep / iterate / roll back" at T+1 turns the day-after standup from a status meeting into a decision meeting. Every item as a checkbox (not prose) makes the checklist usable instead of aspirational.
Prompt 9 — The retro that produces one decision
Most retros produce a wall of sticky notes and zero decisions. The useful output is one or two concrete changes the team will try next sprint, with an owner and a review date. This prompt drafts that.
ROLE: You are a product manager facilitating a sprint retrospective.
CONTEXT: The sprint goal was [GOAL]. We hit / missed / partially hit
it. The team's raw retro input (what went well, what didn't, ideas)
is below:
[PASTE INPUT]
CONSTRAINTS: Output:
- One-sentence sprint verdict (hit/miss/partial + the single biggest
reason).
- Top 2 patterns in "what didn't go well" (cluster the input — don't
list every complaint).
- ONE experiment to try next sprint, in this exact format:
"Next sprint we will [CHANGE]. We'll know it worked if [METRIC OR
OBSERVABLE SIGNAL] by [DATE]. Owner: [ROLE]."
- One thing to stop doing (explicitly).
Maximum 200 words. No "action items" list with 8 things — one
experiment only. No "team morale was good".
OUTPUT: Markdown.
Why it works: "ONE experiment" is the constraint that makes retros actually change behavior. A retro with eight action items ships zero of them; a retro with one ships it and reviews it. The "we'll know it worked if [signal] by [date]" framing turns vague intentions ("communicate earlier") into testable changes ("we will send a slack heads-up by Tuesday EOD when scope changes; we'll know it worked if no engineer says 'I found out late' in the next two retros"). The "stop doing" item is often higher-leverage than the "start doing" item.
How I tested these
Each prompt was tested against three real inputs (different features, different products, different constraints) and judged on whether the output (a) could be sent to a stakeholder with <2 minutes of editing, (b) surfaced something I hadn't already thought of, and (c) didn't introduce fabricated specifics. Prompts that hallucinated metrics, invented user personas, or produced outputs that needed more than light editing were rewritten. The structure above (Role → Context → Constraints → Output) survived every test — vague prompts failed all three criteria; structured prompts passed two of three consistently.
The full pack this post is drawn from covers 50+ prompts across the entire product lifecycle: discovery (interview guides, survey design, JTBD synthesis), definition (PRDs, user stories, roadmap bets), delivery (standups, stakeholder updates, retro facilitation), launch (checklists, GTM copy, release notes), and growth (experiment design, funnel analysis, churn investigation). Each prompt in the pack has been tested the same way.
If you want the full set
The prompts above are free — copy them, change the brackets, ship your PRD. If you want the full library of 50+ product-management prompts (plus 150+ more covering engineering, marketing, sales, and operations — same structure, same testing methodology, ready to paste), it's here:
- The AI Startup Operations Prompt System — $199: 50+ prompts, 10 end-to-end workflows (discovery → PRD → roadmap → launch → retro → growth), tested across 400+ runs.
- The AI Business Transformation Playbook — $999: 100+ prompts, 12 full workflows, the flagship library for running an entire operation on AI-generated output.
- The SaaS Marketing Copy Prompt Pack — $49: 25 prompts for landing pages, ad copy, email sequences, and positioning — directly useful for PMs owning GTM.
If PM prompts specifically are what you need and you want a lower price point, the Developer Productivity Prompt Library — $49 includes 30 prompts (some PM-relevant). And the Developer Product-Launch Prompt Pack — $9 is the entry-level set: 7 launch-focused prompts if you just want to try the format.
All five products in the library are listed at the storefront here.
TL;DR: Most PM prompts fail because they're vague, context-free, and untested. Fix all three with the Role → Context → Constraints → Output format, force specific constraints (one-page PRD, verbatim quotes, one experiment per retro), and test against three real inputs before trusting the output. The 9 prompts in this post are free to use. The full pack of 50+ is linked above.
Top comments (0)